14:02:34 <markmcclain> #startmeeting Networking
14:02:35 <openstack> Meeting started Tue Sep 23 14:02:34 2014 UTC and is due to finish in 60 minutes.  The chair is markmcclain. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:02:36 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:02:39 <openstack> The meeting name has been set to 'networking'
14:03:06 <markmcclain> mestery is returning from a school event so will join us in a few minutes
14:03:10 <markmcclain> #chair mestery
14:03:11 <openstack> Current chairs: markmcclain mestery
14:03:19 <markmcclain> #link https://wiki.openstack.org/wiki/Network/Meetings Agenda
14:03:35 <markmcclain> #topic Announcements
14:03:56 <markmcclain> #info RC-1 will be cut soon
14:04:21 <markmcclain> At this point we are in a string, feature and requirements freeze
14:05:00 <markmcclain> #topic Bugs
14:05:03 <markmcclain> enikanorov: hi
14:05:28 <obondarev> enikanorov is on business trip, not sure he can join..
14:05:40 <markmcclain> obondarev: ok.. thanks for letting me know
14:06:07 <markmcclain> Anyone have bugs the team should be made aware of?
14:06:17 <jschwarz> I have a bug Ihar wanted to talk about
14:06:22 <jschwarz> Please look at https://bugs.launchpad.net/neutron/+bug/1372438
14:06:24 <uvirtbot> Launchpad bug 1372438 in neutron "Race condition in l2pop drops tunnels" [Undecided,In progress]
14:06:49 <jschwarz> There was a regression done a while back (explained in the launchpad) and a fix has already been proposed
14:07:08 <jschwarz> Ihar asked me to see if you could bump it up to RC1 and change the importance
14:07:40 <markmcclain> I can look into it further after the meeting
14:07:44 <obondarev> new critical bug was reported recently by garyk
14:07:46 <obondarev> https://bugs.launchpad.net/neutron/+bug/1372570
14:07:47 <uvirtbot> Launchpad bug 1372570 in neutron "Booting multiple instances causes race with port security groups" [Critical,In progress]
14:07:56 <markmcclain> jschwarz: also seems that there is a related bug
14:07:58 <armax> jschwarz, markmcclain I have been looking at that one too
14:08:02 <armax> I’ll keep an eye on it
14:08:13 <markmcclain> armax: if you want to take the lead that would be great
14:08:20 <jschwarz> thank you armax and markmcclain, I'll let Ihar know :)
14:08:20 * mestery catches up
14:08:22 <obondarev> the patch is on review: https://review.openstack.org/#/c/123187/
14:08:51 <amotoki> am looking it
14:08:57 <salv-orlando> obondarev: could you confirm the bug? It is so blatant I wonder how comes we figured it out now only
14:09:25 <jschwarz> ihrachyshka, ^
14:09:29 <salv-orlando> according to this bug deployers should have ended up with hundreds of thousands of security groups in the admin profile
14:09:29 * ihrachyshka is finally joining
14:09:30 <obondarev> salv-orlando: didn't have a chance to triage it yet
14:10:04 <armax> markmcclain: there is also #link https://bugs.launchpad.net/neutron/+bug/1371732 that carl_baldwin is addressing
14:10:05 <uvirtbot> Launchpad bug 1371732 in neutron "create_port failure resulting in Lock wait timeout" [Critical,In progress]
14:10:17 <mestery> Also, salv-orlando, any updates on this one: https://bugs.launchpad.net/neutron/+bug/1323658
14:10:19 <uvirtbot> Launchpad bug 1323658 in nova "Nova resize/restart results in guest ending up in inconsistent state with Neutron" [Critical,Confirmed]
14:10:27 <carl_baldwin> armax:  Thanks for bringing that up.  I was about to mention it.
14:10:42 <salv-orlando> mestery: we have arosen working on dansmith for bug 1323658
14:10:43 <uvirtbot> Launchpad bug 1323658 in nova "Nova resize/restart results in guest ending up in inconsistent state with Neutron" [Critical,Confirmed] https://launchpad.net/bugs/1323658
14:10:51 <salv-orlando> * working with
14:10:58 <dansmith> salv-orlando: thanks for that correction :)
14:10:58 <mestery> salv-orlando: Ack, thanks!
14:12:04 <mestery> Any other bugs the team should be aware of as we near RC1?
14:12:46 <mestery> OK, moving on then.
14:12:49 <mestery> #topic Incubator Update
14:12:50 <mestery> markmcclain: Hi!
14:13:22 <markmcclain> so we've tabled the incubator for this cycle
14:13:47 <markmcclain> after discussions with the -infra team and the principals in LBaaS
14:13:56 <markmcclain> we've created a feature branch to unblock that team
14:14:04 <mestery> #info Incubator tabled for Juno cycle,
14:14:06 <markmcclain> #link http://git.openstack.org/cgit/openstack/neutron/tree/?h=feature%2Flbaasv2
14:14:13 <mestery> #info Feature branch created to unlock LBaaS team and move that work forward
14:14:18 <mestery> markmcclain: Nice work!
14:14:32 <markmcclain> we've started to merge some of the backlog of lbaasv2 patches
14:14:51 <mestery> blogan sbalukoff sballe rm_work: ^^^^
14:14:52 <markmcclain> and I'll be working with the proposers to finish retargeting the patches for the new branch
14:15:10 <markmcclain> mestery: you forgot dougwig
14:15:12 <mestery> markmcclain: I guess some of these may need rebases perhaps.
14:15:21 * mestery never forgets dougwig :)
14:15:27 <dougwig> :)
14:15:30 <markmcclain> haha.. yes a few will need rebasing
14:15:35 <rkukura> markmcclain: Is there a wiki or anything on how feature branches are used in neutron? In particular, are the neutron cores in the loop?
14:15:39 <amotoki> how does the branch work? it might be discussed last week.... how is it reviewed?
14:16:00 <markmcclain> and some will need reviews because it would be good to get some eyeballs on them since they it looks like they got ignored due to the blockage
14:16:23 <markmcclain> rkukura: so feature branches work just like a normal review cycle for now
14:16:26 <mestery> markmcclain: I think we merged the initial LBaaS API patch from blogan into the feature branch last night though, which is ag ood start.
14:16:35 <markmcclain> but the branch is not frozen
14:16:56 <markmcclain> because the earliest it would merge is kilo
14:16:56 <amotoki> I see.
14:17:09 <salv-orlando> markmcclain: do we have a custom core team for each feature branch?
14:17:26 <markmcclain> salv-orlando: at this time the groups that have +2/A is the core team
14:17:51 <markmcclain> I wanted to unblock first and then discuss if we wanted the set of approvers to be different
14:17:58 <ihrachyshka> informal interest groups should be enough
14:18:07 <salv-orlando> markmcclain: I would consider the idea of giving at least +2 (not sure about +A) to subject matter experts of each particular branch. Is that being considered?
14:18:19 <salv-orlando> markmcclain: ok sorry I did not read your last post
14:18:39 <markmcclain> salv-orlando: yes… I think there are few people on the short list but I think that requires a discussion
14:18:46 <markmcclain> and I was hoping to unblock first
14:18:58 <markmcclain> since many cores have avoided reviewing due to the block
14:19:01 <mestery> +1 to the unblocking first, thanks for taking care of this with infra markmcclain.
14:19:08 <markmcclain> happy to help
14:19:15 <amotoki> sounds very reasonable :-)
14:19:21 <dougwig> +1
14:19:27 <banix> are there plans for other feature branches?
14:19:41 <markmcclain> banix: at this time no, but I do want to discuss this in paris :)
14:20:09 <mestery> dougwig: Can you help coordinate reviews of the remaining LBaaS patches for the feature branch?
14:20:21 <rkukura> markmcclain, mestery: Where is the feature branch process documented. This is the first I’ve heard that its possible to have separate cores for feature branches.
14:20:43 <markmcclain> rkukura: it is something that Swift has used before
14:20:46 <dougwig> mestery: yes, I'll get them rolling today
14:20:52 <mestery> dougwig: Thanks!
14:21:00 <markmcclain> I don't want to go crazy with branches yet because they don't solve all problems
14:21:03 <rkukura> markmcclain: That is not very helpful tome
14:21:12 <salv-orlando> rkukura: I made this statement just because I was thinking that in a way is similar to stable branches and gerrit could handle it in the same way
14:21:15 <markmcclain> rkukura: it distros are not likely to release from them
14:21:35 <salv-orlando> but there is no decision, proposal, or even whatsoever thing being discussed atm
14:21:58 <markmcclain> salv-orlando: right… stay tuned on that side of it
14:22:01 <mestery> Like markmcclain said, this was done to unblock the LBaaS folks so they can continue working.
14:22:29 <mestery> And I think there will be some discussions on this in Paris as well.
14:22:38 <amotoki> and we can discuss when we merge feature branches to master in Paris..
14:22:44 <mestery> amotoki: ++
14:23:18 <markmcclain> amotoki: yes.. it is a must for us to discuss
14:23:47 <salv-orlando> feature branches are rather useful whenever you have an effort which will require several commits from several developers, but should not go in the main repo until all of them are complete. in a way, it gives you “all or none”
14:24:11 <dougwig> And less than a cycle from usefulness
14:24:12 <mestery> salv-orlando: In addition, it allows for the retention of the git history in an easy manner, which infra is happy about.
14:24:23 <marun> My understanding is that feature branches should be short-lived.
14:24:31 <mestery> marun: Yes
14:24:34 <marun> I think a full cycle is too long, frankly.
14:24:42 <marun> But yes, let's discuss in paris.
14:25:26 <mestery> Thanks for the updates markmcclain, moving on then.
14:25:32 <mestery> #topic Kilo Design Summit
14:25:42 <banix> by tabling the incubator for this cycle, it means, it won’t be done in this cycle? is it being considered for next cycle? out of question for now?
14:25:47 <mestery> #undo
14:25:48 <openstack> Removing item from minutes: <ircmeeting.items.Topic object at 0x1e84f10>
14:26:01 <markmcclain> banix: I think that it is one the table for kilo
14:26:15 <banix> ok thanks
14:26:46 <mestery> Anymore questions on the incubator or feature branches before we move on?
14:26:47 <salv-orlando> markmcclain: do you mean that the incubator will be ready by the end of kilo? or that contributors will be able to commit in it during kilo?
14:26:57 <salv-orlando> just for the sake of pedantry
14:27:06 <salv-orlando> because we all love being pedant
14:27:18 * mestery gets out his yak shaver
14:27:33 <markmcclain> salv-orlando: it is something we want as a team we can discuss what goes in and also weighing the pros/cons vs using feature branches or separate project all three options have tradeoffs
14:27:59 <mestery> It really depends on what is being proposed salv-orlando, to be even more pedant.
14:28:26 <salv-orlando> I think you answered the question - and the answer is that no committment can yet be made
14:28:49 <salv-orlando> mostly because we don’t exactly know yet what we will be committing too
14:29:03 <mestery> salv-orlando: Precisely.
14:29:19 <mestery> It depends on what we commit to as a team for Kilo to some extent.
14:29:43 <salv-orlando> mestery: thanks I had my fix of pedantry for today. Now I can be constructive again.
14:30:02 * mestery waits for a bit to let anymore pedantry fall out before moving on.
14:30:43 <mestery> #topic Kilo Design Summit
14:30:59 <mestery> So, a reminder from last week, session proposals are now different for the Kilo Summit this time.
14:31:00 <mestery> #link https://etherpad.openstack.org/p/kilo-neutron-summit-topics
14:31:08 <mestery> We as a team are collecting ideas on the etherpad ^^^
14:31:23 <mestery> And we will collectively setup time for discussions during our 2 allotted days.
14:31:36 <mestery> We already have enough work on that page to last us for probably 6 cycles or so.
14:31:47 <dougwig> what is the deadline for giving input there?
14:31:49 <mestery> Which is to say, there is a lot to do.
14:32:06 <mestery> dougwig: No known deadline yet, but we'll be firming this up over the next 3 weeks or so.
14:32:34 * salv-orlando wishes there will be work in there for about 60 cycles. This way I’d know what to do until retirement.
14:32:40 <mestery> I'm hoping that with the change in format we can get people signed up for the big items here.
14:32:56 <mestery> And we can utilize the mid-cycle meeting to drill down on things.
14:33:46 <mestery> Any other questions on the Kilo Design Summit?
14:34:22 <mestery> One more item here then:
14:34:23 <mestery> #link http://lists.openstack.org/pipermail/openstack-dev/2014-September/046793.html
14:34:31 <mestery> ttx sent out an email with a proposed schedule for Kilo.
14:34:36 <mestery> I encourage folks to have a look at it.
14:34:50 <mestery> We'll have to fit our work items into that schedule in a realistic fashion to ensure success for Neutron in Kilo.
14:36:00 <mestery> #topic Parity
14:36:07 <markmcclain> hi
14:36:11 <mestery> Hi markmcclain!
14:36:20 <mestery> Do we haev any loose ends here to wrap at the end of Juno now?
14:36:26 <markmcclain> so grenade work is on my schedule for today
14:36:34 <mestery> markmcclain: awesome!
14:37:43 <markmcclain> other than that I think we'll be finalizing parity work for Kilo
14:38:03 <markmcclain> also I've chatted with a few folks who've tested obondarev transition work
14:38:13 <markmcclain> hoping to get them to doc their results
14:38:20 <mestery> markmcclain: Excellent!
14:38:33 <mestery> markmcclain: We need to chat with mikal around the official wording of nova-network deprecation for Juno.
14:38:41 <mestery> I'm hoping we can say that and have it in the rlease notes now.
14:38:42 <mestery> *release
14:39:13 <mestery> markmcclain: Do you think we can now try to merge this patch: https://review.openstack.org/#/c/105785/
14:39:17 <mestery> This defaults devstack to neutron.
14:39:21 <mestery> Or do you want grenade to land first?
14:39:30 <markmcclain> let's land grenade
14:39:34 <mestery> Ack
14:39:39 <mestery> OK, thanks for the updates markmcclain!
14:39:42 <markmcclain> and then when kilo opens flip the switch
14:39:59 <mestery> markmcclain: Sounds good.
14:40:07 <mestery> #info Looking to merge parity work around grenade this week.
14:40:17 <mestery> #info Will merge patch to default devstack to neutron at the start of Kilo.
14:40:27 * mestery doesn't see emagana around so will skip docs update this week.
14:40:37 <mestery> #topic Tempest
14:40:43 <mestery> mlavalle: Hi there! Do you have a Tempest update this week?
14:41:13 <mlavalle> mestery: quick update: I've been helping to migrate networking tests to tempest clients (scenario)
14:41:46 <mlavalle> mestery: I also started a conversation with the ml2 group about some specialized testing  in case of mechnism failures
14:42:00 <mestery> mlavalle: Excellent!
14:42:17 <mlavalle> mestery: I have some homework to do for tomowrro's ML2 meeting
14:42:39 <mlavalle> and that's all I have for today
14:42:41 <mestery> mlavalle: Make sure to dot your 'i's and cross your 't's, rkukura doesn't grade on a curve. ;)
14:42:43 <mestery> Thanks mlavalle!
14:42:53 <mestery> #topic L3
14:42:55 <mestery> carl_baldwin: Hi there!
14:43:01 <carl_baldwin> mestery: hi
14:43:09 <mlavalle> mestery: I know, I really fear rkukura 's grading :-)
14:43:18 <carl_baldwin> #link https://wiki.openstack.org/wiki/Network/Meetings#L3_.28carl_baldwin.29
14:43:43 <carl_baldwin> The team wiki is up to date.  I wanted to point out that we’re actively working the failure rate in the dvr job.
14:43:56 <carl_baldwin> The first bug was mentioned earlier.
14:44:02 <mestery> carl_baldwin: Cool!
14:44:19 <carl_baldwin> We’re working on a second race that should get the failure rate back down to nearly 0.
14:44:45 <carl_baldwin> mestery: That is all I wanted to highlight.
14:45:12 <mestery> carl_baldwin: Thanks!
14:45:26 <mestery> carl_baldwin: Can you do me a favor offline and highlight which bugs around DVR are release critical?
14:45:32 <mestery> I expect ttx to ask me that today in our 1:1.
14:46:01 <carl_baldwin> mestery: yes
14:46:16 <mestery> carl_baldwin: Thank you sir!
14:46:34 <mestery> #topic IPV6
14:46:38 <mestery> sc68cal: Hi!
14:47:18 <mestery> In lieu of Sean, does any other IPV6 team member have any updates or release critical bugs they wanted to highlight for Juno here?
14:47:47 <xuhanp> mestery, I have one to get more attentions one
14:47:56 <mestery> xuhanp: Thanks!
14:48:11 <xuhanp> https://review.openstack.org/#/c/101433/
14:48:22 <mestery> #link https://review.openstack.org/#/c/101433/
14:48:33 <xuhanp> it has been rebased several times so could be great if more cores can check it :-)
14:48:52 <mestery> xuhanp: I have marked it RC1 for now.
14:49:07 <xuhanp> mestery, thanks
14:49:10 <mestery> #link https://bugs.launchpad.net/neutron/+bug/1330826
14:49:12 <uvirtbot> Launchpad bug 1330826 in neutron "Neutron network:dhcp port is not assigned EUI64 IPv6 address for SLAAC subnet" [High,In progress]
14:49:28 <xuhanp> that's all I have. Not sure if other members have other things to bring up
14:49:36 <mestery> xuhanp: Thank you!
14:49:45 <mestery> #topic ML2
14:49:51 <mestery> rkukura: Hi!
14:50:01 <rkukura> hi
14:50:40 <rkukura> main ML2 activity has been around banix’s work to fix bulk creates to work properly with transactions
14:51:15 <rkukura> mestery: Is that still OK to merge for Juno?
14:51:20 <mestery> #link https://bugs.launchpad.net/bugs/1193861
14:51:22 <uvirtbot> Launchpad bug 1193861 in neutron "ML2 plugin needs to override bulk operations" [Medium,In progress]
14:51:26 <mestery> rkukura: That bug ^^^^
14:51:38 <rkukura> mestery: right
14:52:01 <mestery> rkukura: I think so, though it has a -1 from kevinbenton at the moment I see.
14:52:13 <mestery> banix: Are you planning to iterate that patch today yet?
14:52:22 <banix> mestery: yes will do
14:52:36 <rkukura> It has seemed very close to merging, but then there was some suggestion of different approaches, etc.
14:52:36 <mestery> banix: OK, thanks,.
14:52:48 <rkukura> banix: Are you sticking with the current approach?
14:52:50 <amotoki> it seems we already have a consensus on the direction
14:53:07 <mestery> amotoki rkukura: Can you guys work together to try and merge this assuming the approach looks ok?
14:53:15 <rkukura> mestery: yes
14:53:22 <amotoki> mestery: sure
14:53:23 <banix> The only issue seems to be refactoring the code to use bulk for non bulk creates as well
14:53:23 <mestery> Cool, thanks!
14:53:40 <rkukura> anything else on ML2?
14:53:41 <mestery> #info amotoki and rkukura to work together to merge the bulk operations patch from banix before RC1
14:53:47 <banix> i was thinking we may want to leave that out for now and not touch the non bulk ops
14:53:51 <banix> ok thanks
14:54:06 <mestery> #topic Horizon
14:54:10 <mestery> amotoki: I see you added a note here.
14:54:53 <amotoki> almost all work are merged and i will request to review L3-HA support in the horizon meeting two hours after.
14:55:02 <mestery> amotoki: Awesome!
14:55:29 <mestery> #topic Open Discussion
14:55:38 <kevinbenton> #link https://bugs.launchpad.net/neutron/+bug/1255142
14:55:40 <uvirtbot> Launchpad bug 1255142 in neutron "unable to get router's external IP when non admin (blocker for VPNaaS)" [Medium,In progress]
14:55:48 <kevinbenton> do we care to get a fix for that into Juno?
14:56:24 <kevinbenton> salv-orlando had concerns about another API attribute for router that it required
14:57:00 <mestery> kevinbenton: I haven't reviewed this one yet, so I'll defer to salv-orlando's comments until I have.
14:57:04 <salv-orlando> kevinbenton: It’s been a long time now, I don’t remember. I must view the patch again
14:57:49 <kevinbenton> salv-orlando: so the patch i had is overkill because it allows R/W to address other use cases, but VPNaaS only requires read
14:58:11 <kevinbenton> I can propose a read-only one to fix this use case
14:58:42 <amotoki> another topic on VPNaas, I today put -2 on VPNaaS peer_id validation change https://review.openstack.org/#/c/116835/  Input from VPNaaS team would be appreicated.
14:59:02 <salv-orlando> kevinbenton: sounds good to me.
14:59:07 <mestery> #info Need VPNaaS team to provide input on this review: https://review.openstack.org/#/c/116835/
14:59:13 <amotoki> I think no discussion is needed here.
14:59:14 <mestery> OK, we're at time now.
14:59:17 <beagles> I have something. Neutron/nova interaction is on the neutron/kilo ether pad
14:59:18 <jschwarz> amotoki++
14:59:32 <mestery> beagles: Yes
14:59:39 <mestery> We would ideally have this in a cross-project timeslot.
14:59:48 <mestery> And have the right people there to really make progress on that. Make sense?
14:59:49 <markmcclain> beagles: I've chatted some nova cores about it too
14:59:50 <beagles> I want to look into this. I was discussing refactoring pre juno
15:00:05 <mestery> beagles: Can we add an item for Monday's Neutron meeting agenda perhaps?
15:00:13 <beagles> yes
15:00:28 <mestery> beagles: Tahnks! Please add it in "Team Discussion Topics" area and we'll allocate time. Thank you!
15:00:34 <mestery> OK, thanks for attending this week everyone!
15:00:46 <mestery> Juno is almost here, only a little bit of time left.
15:00:52 <mestery> We'll see you all on the ML and in-channel!
15:00:56 <mestery> #endmeeting