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