21:02:14 #startmeeting networking 21:02:14 hi 21:02:15 Meeting started Mon Jul 7 21:02:14 2014 UTC and is due to finish in 60 minutes. The chair is mestery. Information about MeetBot at http://wiki.debian.org/MeetBot. 21:02:16 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 21:02:18 The meeting name has been set to 'networking' 21:02:29 #link https://wiki.openstack.org/wiki/Network/Meetings Agenda 21:02:34 hi 21:02:39 #topic Announcements 21:03:16 #info Spec Proposal Deadline is 7-10-2014, and Spec Approval Deadline is 7-20-2014 for Juno. 21:03:32 I sent an email on that last week, but wanted it noted in the meeting minutes. 21:03:41 #info Juno-2 is July 24. 21:03:50 Also a note about the Juno-2 deadline which is fast approaching. 21:04:15 #info Neutron Mid-Cycle Sprint is this week: 7-9 through 7-11. 21:04:30 I think we'll have somewhere around 20-25 people or so showing up. 21:04:55 I expect a busy week, looking forward to seeing those who can make it in person! 21:05:13 OK, lets move on past announcements now. 21:05:18 #topic Bugs 21:05:20 enikanorov_: Hi! 21:05:26 hi 21:05:39 nothing major or critical on bugs side 21:05:46 lock wait timeouts are hit here and there 21:05:52 waiting for patch to merge: 21:06:03 #link https://review.openstack.org/#/c/100934/ 21:06:38 i believe it should fix a good bunch of timeouts 21:06:50 enikanorov_: Excellent! 21:07:08 so cores please review 21:07:38 what do you reckon of switching to mysql-connector? 21:08:05 is there a patch we can test? 21:08:31 I'm working on a bunch of changes to oslo.db that are required first 21:08:36 i think it could be a good way to move forward 21:08:55 although i think we still need to fix the issue with existing code 21:09:03 You won't be able to in all cases. 21:09:11 gus: why? 21:09:24 eg: if two user requests come in at once to mutate the same DB row, then you'll deadlock. 21:09:51 no, why? 21:10:06 one is making change, another one is waiting 21:10:06 I see a BP registered in LP for this already: https://blueprints.launchpad.net/neutron/+spec/switch-to-mysql-connector with spec here: https://review.openstack.org/#/c/104905/ 21:10:13 no 21:10:23 deadlock means one thing in db-land, another in code land. 21:10:24 one eventlet opens a transaction, starts doing stuff. 21:10:43 yields at any point. 21:11:03 new thread comes in and also opens a transaction that the DB thinks needs to block on the first. 21:11:41 that's not exactly a deadlock. we have a bunch of deadlock too, and that's a different condition 21:11:47 I think any discussion of moving to mysql-connector needs to happen at a higher level than just Neutron, perhaps we should move this discussion to the ML. 21:11:50 (it's actually a lock order issue) 21:12:03 mestery: agree. and thanks for the pointer 21:12:11 mestery: it’s already there 21:12:17 this is why I brought it here 21:12:29 salv-orlando: Just bringing everyone up to speed. :) 21:12:34 you'll never give cpu back to the first. 21:12:59 mestery: link here if you want to add to meeting minutes -> http://lists.openstack.org/pipermail/openstack-dev/2014-July/039530.html 21:13:12 #link http://lists.openstack.org/pipermail/openstack-dev/2014-July/039530.html 21:13:15 Thanks salv-orlando! 21:14:03 enikanorov_: Any other bugs we should be aware of or need discussing here? 21:14:32 no, unless salv-orlando wants to say something about the bug he has filed 21:14:42 about vif plugging notifications 21:14:43 I filed lots of them which one? 21:15:13 #link https://bugs.launchpad.net/neutron/+bug/1338679 21:15:18 Launchpad bug 1338679 in nova "Some Neutron plugins might miss network-vif-* events" [Undecided,New] 21:15:44 that does not affect any plugin running the ovs agent. Therefore I don’t think it needs meeting attention. 21:15:52 ok 21:15:57 OK, thanks salv-orlando. 21:15:57 that's it then with bugs 21:16:01 enikanorov_: Thank you! 21:16:10 #topic Team Discussion Topics 21:16:25 I wanted to quickly highlight one thing about the mid-cycle this week: 21:16:38 On Wednesday, it would be great if folks could delay arrival until 9:30 or so. 21:16:50 The reason being, the large training room I have is mine at that time. :) 21:17:06 I have a smaller room before that, but 20+ people would be cramped there. The rest of the week people can come much earlier. 21:17:11 mestery: glad to sleep another 30 minutes :-) 21:17:12 Any questions on the sprint this week from anyone? 21:17:16 mlavalle: ;) 21:18:20 OK, one other thing I'd like to bring up is the core reviewer assignment email I sent out today. 21:18:22 #link http://lists.openstack.org/pipermail/openstack-dev/2014-July/039529.html 21:18:25 mestery: works just fine for me - 21:18:51 In a nutshell, I'm hoping that for the 10 community BPs identified here we can spread the load of working these out in the final weeks of Juno-2. 21:19:18 In no way am I discouraging anyone from reviewing additional BPs, but I'm hoping this will provide submitters with core contacts for the community BPs I've highlighted here. 21:19:29 Lets see how this works and evaluate things post Juno-2. 21:19:37 mestery: +1 21:19:40 Any questions or comments on this? 21:19:47 Thanks emagana :) 21:20:22 Also, I should highlight I'm not ignoring additional BPs here, but I thought starting with a smaller set to gather some data as to how this works would be worth trying. 21:20:27 * mestery listens to the crickets. 21:21:04 OK, lets move on then. 21:21:07 #topic Nova Parity 21:21:09 markmcclain: Hi! 21:21:22 hi 21:21:48 not to much movement with the holidays last week looking forward to getting everyone in teh same room 21:22:05 markmcclain: +1! 21:22:54 #link https://etherpad.openstack.org/p/lOiqsLmizl Mid-Cycle Sprint parity work items 21:24:12 mestery is chatting with someone else! 21:24:22 OK, lets see how much we can get done this week on the parity front! 21:24:24 :P 21:24:39 emagana: how did you know that ? 21:24:47 mea culpa! 21:24:48 #topic Tempest 21:24:51 mlavalle: Hi! 21:24:55 hi 21:25:53 we merged the last two api tests of the list we planned originally in January: VPN (by me) and LbaaS quotas by Evgeny Fedoruk 21:26:28 mlavalle: That's great! 21:26:39 sc68cal also merged ipv6 test that wssn't in the irginal list 21:27:00 we have another two tests for porvider networks in the works 21:27:16 so in this front we have execellent covergare 21:28:02 I spent some time pinging salv-orlando and markmcclain for tempest tests that might need development for the nuetron full job and nova parity 21:28:11 nothin is really needed there 21:28:33 mlavalle: One thing I hope we can discuss this week is multi-node testing for DVR via a 3rd party. 21:28:38 I confirm the problem of the full job is not it being full 21:28:39 so for the sprint this week, I listed the api tests in review: to make sure they get reviewed and merged asap 21:28:42 but rather being parallel 21:28:47 salv-orlando: Heh 21:29:35 mestery: I was speaking with marun the other day and he said we might be able to do multi-node upstream 21:29:41 also keeping an eye in the missing api calls for nova-parity. even though they are not new calls for the neutron api, we need to make sure the corresponding nova tests pass 21:29:43 not sure if it’s just speculation at the moment :) 21:29:50 we’ll need to dig into this 21:29:51 armaxm armax: That would be most excellent! 21:29:56 it's not speculation 21:30:05 mestery: and yes, we can discuss DVR this week 21:30:07 marun: thanks for keeping me honest 21:30:14 I heard in the last qa meeting that’s technically already possible 21:30:25 it was confirmed by sdague in last week's qa meeting that multi-node should be possible with as little as a week of concerted effort 21:30:38 I also saw that you liested the new LBaaS api for the juno-2 reviews 21:30:41 marun: Excellent! That's really good news for testing DVR multi-node in the gate! 21:30:41 see? marun confirms I’m not a liar too 21:30:45 this means tempest accepting multi-node testing, the kind we require to validate many of the parity work items, is not far off 21:30:54 mestery: for now I have been worrying at getting dvr to work on a single-node :) 21:31:01 armax: ;) 21:31:04 so I can spend time this week completing the tempest tests for that api 21:31:09 marun, mestery, salv-orlando: baby steps 21:31:10 mlavalle: Yes, new LBaaS API tests for Tempest will be needed. 21:31:18 mlavalle: Cool! 21:31:30 * salv-orlando mehs thinking about why we would need multi-node to validate parity with nova-network if nova network is not running multi node either so far? 21:31:41 hehe 21:31:41 I am half way with the new LBaaS tests. So it's just a mteer of devoting time to them 21:31:42 * armax agrees 21:31:48 * mestery agress too 21:31:50 neutron should be better! 21:32:00 mlavalle: Awesome! 21:32:08 that's all I have 21:32:12 but I think that multi-node should be done for both nova and dvr 21:32:13 Lots of activity in the Tempest report this week mlavalle! 21:32:15 not just dvr 21:32:18 armax: +1 21:32:22 we need nova network ha testing as much as we need dvr testing in the gate 21:32:28 armax: +1 21:32:31 marun: +1 21:32:34 marun: +100 21:32:42 * mlavalle lloking forward to see the team this week in Minneapolis 21:32:50 :-) 21:32:59 mlavalle: Indeed, should be nice! 21:33:02 OK, lets move on, thanks mlavalle! 21:33:04 #topic L3 21:33:06 carl_baldwin: Hi there! 21:33:09 hi 21:33:26 Mostly DVR work. Still progressing. 21:33:29 mestery: I forgot to mention. I developed a 4 slides presentation to train tempest developers if it is needed during the sprint 21:33:43 mlavalle: That's awesome, thanks for that, and I hope we can make use of it. 21:33:56 mlavalle: that would be great 21:34:04 I look forward to working on it in Minn. this week. 21:34:18 carl_baldwin: Great, as does everyone! 21:34:38 carl_baldwin: Anything else this week? 21:34:56 mestery: Not really. We still have the same goals as last week. 21:35:05 carl_baldwin: OK, thanks for the updates here! 21:35:18 #topic Advanced Services 21:35:20 SumitNaiksatam: Hi there! 21:35:30 mestery: hi 21:35:48 so we are still pretty much at the same point as the last week 21:35:58 still discussing flavors 21:36:09 mestery: you mentioned you wanted to spend some more time here? 21:36:24 enikanorov, markmcclain: do you guys think we are converging? 21:36:31 Per email last week, I hope we're close on closing on flavors. :) 21:36:41 I thought we were 21:36:46 SumitNaiksatam: mostly, i think 21:36:57 enikanorov: wants to hold off on items I thought we had agreed on 21:37:03 markmcclain, enikanorov_: thats great 21:37:20 markmcclain: i though we had agreed to hold them off :) 21:37:29 markmcclain: i've replied to your reply btw 21:37:36 extensions should have API support 21:37:36 so from a process perspective, which blueprint spec are reviewing? 21:37:42 or still both? 21:37:44 SumitNaiksatam: markmcclain's 21:37:51 enikanorov_: ok good 21:38:13 #link https://review.openstack.org/102723 21:38:28 markmcclain: let's continue on ML about the extensions, i think it's doable, but not necessarily with user-facing API part 21:38:34 enikanorov_: you mentioned you had started implementation? 21:38:44 SumitNaiksatam: right 21:39:04 enikanorov_: okay just wanted to make sure that everyeone is aware of that, thanks! 21:39:36 other than flavors, as a team we are also reviewing the service base/insertion, chaining and traffic steering blueprints 21:39:59 i am also happy to state that neutron is soon going to have a “tapaas” menu! ;-) 21:40:26 the Tap As A Service spec is also coming along: https://review.openstack.org/#/c/96149/ 21:40:46 any questions for the sub-team? 21:41:31 mestery: then thats it from me 21:41:36 SumitNaiksatam: Thank you! 21:41:43 #topic IPv6 21:41:44 We should discuss implication of multiple driver instances introduced by flavor 21:41:45 sc68cal: Hi! 21:41:51 #undo 21:41:52 Removing item from minutes: 21:42:02 gduan: Got in at the last minute there ;) 21:42:06 sorry 21:42:09 gduan: Is this something you want to dsicuss now or in the review? 21:42:12 gduan: No worries :) 21:42:36 gduan: i think we can manage single driver instance still 21:42:36 mestery: hello 21:42:39 I think enikanorov has a plan to furthur discuss it in team meeting 21:42:47 sc68cal: Hold one second ;) 21:42:58 gduan: In the services meeting this week? 21:43:07 gduan: yes, please comment on the review and lets bring it to the meeting this week 21:43:08 gduan: even in case of dynamic loading it's not too difficult to maintain single instance of the driver 21:43:32 gduan, enikanorov_ we should discuss on ML vs in meetings where everyone must be present 21:43:36 sure. 21:43:47 sure 21:43:54 markmcclain: thats for logs are for 21:44:30 OK, lets move on now. 21:44:33 #topic IPv6 21:44:36 sc68cal: REady now! 21:44:53 SumitNaiksatam: logs do not enable participation in the process for those that are away from this meeting 21:44:55 Promise I'll be short - for the most part it's just the radvd spec & patch 21:45:22 So basically just the review now 21:45:44 #link https://review.openstack.org/#/c/102648/ radvd support review 21:45:51 That's about it from me 21:46:03 thanks… we know you’re busy with the doc sprint this week 21:46:23 Thanks sc68cal, enjoy the doc sprint! 21:46:30 #topic ML2 21:46:31 thanks :) 21:46:32 markmcclain: i do agree that there needs to be email follow up on the decisions made, however it helps to converge on design when multiple people are present at the same time in the meeting 21:46:42 Sukhdev rkukura: Hi! 21:46:50 mestery: Hi 21:47:04 This was a short and fun week 21:47:09 Sukhdev: Go ahead - I’ve been on vacation and am not caught up yet 21:47:33 We have bunch of spec ready in the final stages - 21:47:54 thanks to Edgar and Akihiro for jumping in and providing core coverage 21:47:58 * mestery hopes rkukura had some fruity cocktails on vacation. :) 21:48:25 I see lots of activity and hope to have few specs merged this week 21:48:46 Other than that everything is on the meeting wiki 21:48:55 that is it - unless there are questions 21:49:05 Thanks Sukhdev! 21:49:18 #topic Group Based Policy 21:49:22 SumitNaiksatam: Hi again 21:49:26 mestery: hi 21:49:43 we do have the datapatch patch is now for the first series 21:50:12 SumitNaiksatam: Great! 21:50:17 we have also completed the model series with patches in for all the resources 21:50:31 rkukura: can talk to the datapath patch 21:51:37 SumitNaiksatam: yes, the resource_mapping driver is the last in the first series and implements the (allow everything) datapath. Its still WIP, but allows the rest to be tested/understood hopefully. 21:51:41 SumitNaiksatam: so does this means everything is ready for end-to-end testing? 21:52:06 Sorry late 21:52:16 nati_ueno: :D 21:52:27 enikanorov_: i believe so, since the CLI patch is also in (this is with reference to the first series of patches comprising EP, EPG, L2/3_policy) 21:52:37 ok, good 21:52:49 happy to take questions, but other than that review comments have been addressed on the model in the first series 21:53:05 mestery: thanks for the time to provide the update here 21:53:18 SumitNaiksatam: Thanks to you for the update. 21:53:33 SumitNaiksatam: But stay right here because ... 21:53:36 #topic FWaaS 21:53:39 SumitNaiksatam: See what I mean? ;) 21:53:41 mestery: sure 21:53:57 i wanted to highlight the issue with supporting FWaaS on DVR 21:54:12 this has been in discussion for some time now, however no clear solution has emerged 21:54:24 SumitNaiksatam: Yes, I've seen the ML thread on the same. 21:54:29 i suspect this issue exisits for any services which requires connection tracking 21:54:58 the fwaas team has stepped up interaction with the DVR team on this front 21:55:08 lets see what we can achieve for juno 21:55:15 at this point its up in the air though 21:55:56 I don’t think anybody will be hanged if we just put in the documentation that DVR does not work with firewall for juno. 21:56:14 I was thinking the documentation thing is the likely answer for Juno as well. 21:56:16 salv-orlando: that is true 21:56:19 perhaps somebody will be tortured, but nobody should be hanged 21:56:22 salv-orlando: sure, however we would need to have path for the future 21:56:27 given the timelines and where we're at, but lets see what the team comes up with. 21:56:56 salv-orlando: as long as we know what the technical solution is, we can figure out how we can make progress towards that in terms of milestones/releases 21:57:04 right now we dont have one 21:57:09 SumitNaiksatam: if this is something that might have impact on DVR before we merge the work currently under review, then that’s important juno-wise 21:57:44 salv-orlando: its a tough one, because i am not sure we want to delay the merging of DVR for this reason alone 21:58:22 salv-orlando: that is partly the reason why we did not push back before, although we had noted that this issue exists 21:58:25 on my side, I’m 99% sure I don’t want to delay it because of this… 21:58:32 salv-orlando: i agree 21:58:37 carl_baldwin: +1 21:58:42 +1 21:58:45 +1 21:58:46 but I don’t think this discussion is relecant for the meeting 21:58:47 the hope was that we would have evolved a solution by this time 21:58:50 If it comes to it, we'll document this. 21:59:07 And with 2 minutes left ... 21:59:10 #topic Open Discussion 21:59:19 mestery: thanks! 21:59:26 Looking forward to seeing those of you who make the trek to the upper midwest of the USA. 21:59:30 neutron full jobs - patches under review. 1 for nova, 1 for neutron 21:59:33 * mestery notes we may have heat and humidity to share with you. 21:59:38 salv-orlando: Awesome! 22:00:14 nova patch is blocked with a -2, looking with reviewers how they would like the issue to be addressed. The fix changes rest API behaviour so it’s understandable 22:00:34 neutron patch is an easy one. I don’t know how we missed that beforE: https://review.openstack.org/#/c/105239/ 22:00:51 that’s all. Once this two patches go in, the full job will be made voting 22:01:03 salv-orlando: Yikes, that does seem obvious now, thanks for fixing that! 22:01:07 And with that, thanks eveyrone! 22:01:10 #endmeeting