21:02:16 #startmeeting Networking 21:02:17 Meeting started Mon Feb 24 21:02:16 2014 UTC and is due to finish in 60 minutes. The chair is markmcclain. Information about MeetBot at http://wiki.debian.org/MeetBot. 21:02:18 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 21:02:20 The meeting name has been set to 'networking' 21:02:27 #link https://wiki.openstack.org/wiki/Network/Meetings Agenda 21:02:34 markmcclain: last minute changes 21:02:53 Mostly the standard agenda with one special item this week 21:03:03 #topic Announcements 21:03:24 #info Icehouse-3 merge window closes at the end of the day on March 4th 21:04:43 We have lots of in progress reviews and many will need to several iterations to ready for merging 21:04:59 it is important both the proposers and reviewers be responsive this week 21:05:11 #link https://launchpad.net/neutron/+milestone/icehouse-3 21:05:55 Review for blueprints not in Icehouse-3 are being deferred to Juno 21:06:54 #topic Bugs 21:07:08 #link https://bugs.launchpad.net/neutron/+bugs?search=Search&field.importance=Critical&field.status=New&field.status=Confirmed&field.status=Triaged&field.status=In+Progress 21:07:25 We have 4 open critical bugs. Most of these we have been carrying for some time 21:07:48 The incident rate of https://bugs.launchpad.net/neutron/+bug/1253896 21:08:29 markmcclain: I think we should reduce its criticality to high. 21:09:03 salv-orlando: that's my thinking as weel 21:09:08 well 21:09:21 same for bug 1273386 (not sure what to with it since the bug is actually still there) 21:09:40 but now we know it's not critical at least 21:09:58 yeah… for 1273386 reducing makes sense too 21:10:06 Sorry for keeping posting on this topic, but also 1112912 an 1230407 should be retriaged 21:10:22 I think the first can be closed, and the latter perhaps is not anymore valid now 21:10:42 I'm planning on including in the release notes that running an network node and nova-compute on same host when key injection is enabled should be avoided on 12.04 21:10:51 on the other hand, I would like to raise to critical the two top offenders for the full neutron tempest job 21:11:00 plus one bug which was filed by lifeless 21:11:30 I missed the merge on #1112912 21:11:33 I've updated the status 21:11:50 The bug I am talking about are: 21:11:50 1 21:11:58 1) bug 1283522 21:12:08 https://bugs.launchpad.net/neutron/+bug/1283522 21:12:20 2) https://bugs.launchpad.net/neutron/+bug/1265495 21:12:50 can't find the one lifeless filed now... 21:12:56 Hiya sorry running late. 21:13:15 salv-orlando: is it in this list - https://bugs.launchpad.net/tripleo/ ? 21:13:16 ok looks like enikanorov_ is looking into 1283522 21:13:43 lifeless… the one about "queue pool limit x of y"... 21:14:27 bug 1282482 I think 21:14:37 I pushed https://bugs.launchpad.net/neutron/+bug/1265495 back to critical 21:14:43 bug #1282421 might need attention too as it may add instability to the gate 21:14:53 I have a fix, but I am working on UT's 21:15:31 armax: great 21:15:53 http://bugs.launchpad.net/neutron/+bug/1282421 21:16:04 looks line the bot is not working today? 21:16:10 s/line/like 21:16:17 the bot appears to not be running. Hey openstack are you there? 21:16:39 looks like it's not 21:17:35 yeah not sure what is going on with linking bugs 21:18:15 re 1273386 looks like we still have don't have full crash dump for the kernel team to use 21:18:48 but I agree that moving high makes sense now that we have reasonable workaround for the upstream issue 21:18:52 yeah I got pinged for providing a repro 21:19:09 Any other bugs to discuss? 21:19:13 but I had other things to tend to last week unfortunately 21:19:28 I don't think there is any other bugs which deserves the team's attention here. 21:19:46 For a full list of bugs to fix for having the full jobs working decently, see the mailing listy 21:21:00 yeah.. I include a full tempest further down the agenda 21:21:12 #topic Docs 21:21:15 emagana_: hi 21:21:22 markmcclain: Hi there! 21:21:55 Basically, want to share with the team the work that some folks are doing for improving and cleaning the Installation Guide 21:22:10 cool 21:22:48 now that we're getting close to the feature freeze have we begun make sure any changes with DocImpact have a corresponding doc bug? 21:22:56 There was some feedback (complains) about Installation Guide, therefore some work is in progress to make it very EASY to follow 21:23:15 markmcclain: let me take that in a minute 21:23:44 So, for the new installation guide: https://wiki.openstack.org/wiki/Documentation/InstallGuideChanges we have decided to only post information for OpenSource components 21:24:02 Any vendor specific will be move to the Apendix section! 21:24:30 ok.. makes sense 21:24:33 There are some tickets opened agains the installation guide to add vendor-specific info, please do not work on this ticket becasue installation guide will change 21:25:08 I would encourage all vendors to have their own documentation in a public place that we can include in the guide 21:25:41 ok 21:26:05 markmcclain: about your previous question. Yes, this is the time were we start mapping features with Docs.. WIll be sure we are covering anything new! 21:26:28 emagana_: I think it might be better to mark them as invalid. Many people working on vendor specific docs are not in this room 21:26:41 salv-orlando: good point 21:26:46 and I would for sure forget to pass on the information to the rest of my team ;) 21:26:57 emagana_: will you provide some guidelines for the vendors to follow? 21:27:09 salv-orlando: good point, thanks! 21:27:46 Sukhdev: The wiki above will be the main point of reference 21:28:07 It hasn't been decided how the communication with the vendor will be done! 21:28:14 I will bring it to the docs meeting 21:28:39 markmcclain: I am done! 21:29:21 emagana_: so, if I want to add anything vendor specific, can I go and update this wiki? will that be OK? 21:30:13 emagana_: I think you'll probably want to send out a message tagged for Neutron to the ML since many have strict filtering in place 21:30:15 Sukhdev: Installation Guide should not contain vendor specific information in main section but the Apendix will be available for that. Yes, please add in the Wiki anything that you want to be covered 21:30:26 emagana_: thanks for the update 21:30:38 markmcclain: Good idea, I will do that! 21:30:52 #topic Nova Parity 21:31:14 beagles updated the agenda 21:31:48 he had a conflict and could not make the meeting today 21:31:53 #topic Tempest 21:32:07 #link http://lists.openstack.org/pipermail/openstack-dev/2014-February/027797.html 21:32:27 sdague started a thread on making the final push for full tempest testing by Icehouse-3 21:32:46 salv-orlando dug further into the gap 21:32:58 #link http://lists.openstack.org/pipermail/openstack-dev/2014-February/027862.html 21:33:11 salv-orlando: want to share more on what you found? 21:33:31 basically the two bugs I want to be moved to critical are the ones we *must* fix 21:33:53 then there are a plethora of minor bugs both in tempest and/or neutron, which appear to have less frequency 21:34:06 but I think we have enough people on the team and we should be able to fix all of them 21:34:40 in particular I think the one enikanorov assigned to himself might be due to agents reporting while api requests are being processed 21:34:56 yeah I was wondering the same thing myself 21:34:57 so I was wondering if we should still think about separating API and RPC server 21:35:19 I'm leaning that direction 21:35:35 arosen and carl_baldwin have both done work to make this easier 21:35:46 carl_baldwin has a patch that will give us that capability: https://review.openstack.org/#/c/72565/ 21:36:17 right this will enable multiple processes 21:36:22 Doesn't totally separate RPC and API yet. 21:36:37 if it's running in a different process, how is it now separating it? 21:36:42 but there is still one process that is potentially doing both 21:36:47 that patch will allow to have some processes which only process APIs and others which only process RPC requests from the message bug? 21:36:48 They are still run under the same parent process. 21:36:52 bug/bus 21:36:52 uh 21:36:58 what does that have to do with ti? 21:37:25 in the case of the api_workers = 1, that would mean the only task of the parent process would be making sure there is a live process handling api requests. 21:37:46 other than that, it would be handling rpc 21:38:14 ok, let's move that to review then. No need to keep using the meeting's time 21:38:41 yeah.. let's see what implementing this will do to address the testing issue 21:39:04 might get a win by running more than one RPC process in the gate… other services do this 21:39:15 salv-orlando: Anything else on the full run? 21:39:33 nothing which is not already on the mailing list. 21:40:25 salv-orlando: Thanks for looking into the final gaps and id'ing the bugs 21:40:29 mlavalle: hi 21:40:35 hi 21:40:52 we have continue making steady progress with api testing 21:40:58 great 21:41:20 after the message I sent to the ML last week, Tempest core are doing more reviews of api patches 21:41:42 in fact, 4 were merged over the pat 7 days 21:41:49 good news 21:41:56 Great news mlavalle! 21:42:04 I updated the agenda with the pointers 21:42:30 so I still feel condindent that by the end of icehouse, we will be done 21:42:43 yeah same here 21:42:49 thanks for updating the agenda 21:43:00 that's all I have, unless there are questions 21:43:16 mestery: thanks :-) 21:43:23 mlavalle: thanks for the report 21:43:33 #topic L3 21:43:35 carl_baldwin: hi 21:44:56 Looks like he's no longer around… moving on since we're running short on time 21:45:01 #topic IPv6 21:45:03 sc68cal: hi 21:45:08 hello 21:45:19 I'd like to thank salv-orlando for his comments on some of the IPv6 reviews 21:45:26 very helpful 21:45:43 bear with me - i have prepared remarks 21:45:46 We might use another core reviewer there. The patches are fairly mature and I think once the comments are addressed they should be good to go. 21:45:48 hi 21:46:03 i can wait if we want to go back to l3 21:46:14 let's continue with v6 21:46:17 k 21:46:23 We have one high priority fix that I'd like to see get merged by the merge window, IPv6 allow RAs from certain routers https://review.openstack.org/#/c/72252/ . My concern is that one reviewer has identified a larger issue with how neutron creates routers for IPv6 subnets, that is not addressed by the aforementioned review. I've attempted to get him to clear his -1 on the patch and file a bug for the issue he has identified, because it is 21:47:35 The hairpin bug is looking pretty good - thanks to mestery for +1'ing the review 21:47:45 just need one more nova core to sign off 21:47:48 I'll look at 72252 21:47:57 https://review.openstack.org/#/c/56381/ 21:47:57 sc68cal: No worries :) 21:48:00 yeah we're close on the hairpin review 21:48:25 yes- we've been here before though, so I will have toes and fingers crossed for the verify step 21:48:35 find a couple rabbits feet too 21:48:55 otherwise I have a new patch that addresses the suggestions that salv-orlando made - https://review.openstack.org/#/c/52983/ - I will probably post tomorrow 21:49:24 again - thanks to salv-orlando for looking closely at the attributes - catching the allow_put = false 21:49:43 and the alembic rebaes. 21:49:47 *rebase 21:49:58 that's it - I yield the rest of my time 21:50:07 yeah.. alembic rebases are not so fun this time of year 21:50:41 I'll do the same thing I did during Havana and make sure they get sequenced correctly after approval 21:50:47 sc68cal: thanks for the udpate 21:50:51 #topic L3 21:50:56 markmcclain: hi 21:51:00 hi 21:51:06 First meeting this Thursday at 1500. 21:51:13 #link https://wiki.openstack.org/wiki/Meetings/Neutron-L3-Subteam 21:51:23 great 21:51:26 DVR: Documentation on agent design for changes to L2 (ML2) and L3 is forthcoming 21:51:32 Watch for that from Swami 21:51:40 HA Routers: patches in review 21:51:48 #link https://review.openstack.org/#/q/status:open+project:openstack/neutron+branch:master+topic:bp/l3-high-availability,n,z 21:51:58 Will send an update to ML when the docs are ready 21:52:09 markmcclain: That is all I have. 21:52:24 Swami: will be on the lookout for them 21:52:28 carl_baldwin: thanks for the update 21:52:31 #topic ML2 21:52:38 mestery and rkukura: hi 21:52:42 hi! 21:52:46 markmcclain: Sure will be there 21:53:02 hi (I'll let mestery go 1st) 21:53:05 So, a high priority item is the DB migration work addressed here: https://blueprints.launchpad.net/neutron/+spec/ml2-deprecated-plugin-migration 21:53:19 marun is active on that one 21:53:22 marun and rkukura started looking into this today and marun is going to drive this one 21:53:22 Yes 21:53:37 That's our highest priority item given it lets us deprecate LB and OVS plugins 21:53:50 Outside of that, 2 of our SR-IOV patches merged, we have one left: https://blueprints.launchpad.net/neutron/+spec/ml2-binding-profile 21:54:13 We have two port binding bugs being worked as well: https://bugs.launchpad.net/neutron/+bug/1276395 https://bugs.launchpad.net/neutron/+bug/1276391 21:54:30 rkukura has proposed a detailed summary of the issues which those address here: http://lists.openstack.org/pipermail/openstack-dev/2014-February/026344.html 21:54:38 are they bugs that would block I-3 or something that would block the final release? 21:54:44 Other than that, we're focused on getting new MDs upstream as well. 21:55:04 markmcclain: I'm not sure, let me ponder that. 21:55:12 That's all for ML2 given the time left here. 21:55:28 markmcclain: They are needed by many of the existing and new MDs 21:55:29 ok we can figure out that out over the next day or so 21:56:03 rkukura: good to know 21:56:06 thanks rkukura 21:56:16 hope to have a patch for 1276395 toay or tomorrow, and the other soon after 21:56:29 perfect 21:56:32 mestery, rkukura: thanks for the update 21:56:40 #topic SSL related blueprints 21:56:53 So this is the special topic that was added to agenda 21:56:53 Including VPN? 21:56:59 nati_ueno: yes 21:57:10 woo the bonus track! 21:57:19 in three minutes or less :) 21:57:35 Can we do discussion in the #openstack-neutron? 21:57:48 In general I've got significant security concerns on the current SSL work 21:58:06 sensitive pieces of data are either transmitted or stored in the clear 21:58:17 same as for lbaas i guess 21:58:18 nati_ueno: I think the ML is better forum 21:58:27 markmcclain: gotcha 21:58:39 So I wanted to give a heads up that I'll be starting a thread about delaying both to Juno 21:58:50 both teams have done a lot of work on design and code 21:59:10 but I'd rather delay and ensure we're secure over releasing something even marked experimental 22:00:14 enikanorov_: yes this applies to both subteams 22:00:32 Let's discuss on ML about this. If current design is issue, let's delay it to the Juno 22:01:11 nati_ueno: that seems to be the issue with the lack of security store and secure messaging 22:01:22 Same discussion will be applied to the IPsec because we are saving password on the db 22:01:29 I thought db is a kind of secure storeage 22:01:41 but if this assumption is wrong, we should if the ipsec too 22:01:54 nati_ueno: that's part of the discussion 22:02:02 markmcclain: gotcha 22:02:16 I wrote discussion paper https://docs.google.com/presentation/d/1HVA6XJss2tiHu0Z1v9IpehLsTg6VdbAKUTNJCHFeAz8/edit#slide=id.p 22:02:22 I'll send this for the openstack-dev 22:02:26 so let's discussion on the thread 22:03:01 yeah.. I'll kick if off with a big explanation on what I'm thinking and then we can go from there 22:03:11 We've hit the time limit for this week 22:03:33 Thanks to everyone for stopping in.. talk to everyone on IRC or the mailing list 22:03:33 I ok for the sake of the meeting… any decision related to SSL blueprint is then deferred to the Mailing list? 22:03:51 salv-orlando: yes 22:04:08 #endmeeting