14:01:03 <mestery> #startmeeting networking
14:01:04 <openstack> Meeting started Tue Dec  2 14:01:03 2014 UTC and is due to finish in 60 minutes.  The chair is mestery. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:01:05 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:01:07 <openstack> The meeting name has been set to 'networking'
14:01:08 <mlavalle> hi
14:01:17 <SumitNaiksatam> hi all!
14:01:17 <mestery> #link https://wiki.openstack.org/wiki/Network/Meetings Agenda
14:01:23 <mestery> #topic Announcements
14:01:24 <enikanorov__> hi
14:01:35 <mestery> The mid-cycle is next week
14:01:37 <mestery> #link https://wiki.openstack.org/wiki/Sprints/NeutronKiloSprint
14:01:49 <mestery> For those who have registered, please send Jun your contact info so he can set you up with wifi
14:01:54 <mestery> He's only received 5 names so far
14:02:01 <mestery> The contact info is on the wiki page
14:02:33 <mestery> I'm still working out logistics for remote participation, stay tuned for that.
14:03:15 <mestery> Spec Proposal and Spec Approval Deadline is approaching fast
14:03:16 <mestery> #link http://lists.openstack.org/pipermail/openstack-dev/2014-November/050958.html
14:03:33 <mestery> #info SPD is 12-8-2014 and SAD is 12-15-2014.
14:03:49 <mestery> I know folks have been very busy reviewing specs, which is great to see!
14:04:17 <mestery> #link https://launchpad.net/neutron/+milestone/kilo-1
14:04:18 <bobmel> mestery: About the mid cycle and API/RPC layer refactoring, are there any details on that?
14:04:46 <mestery> bobmel: Nothing that isn't on the wiki already
14:05:08 <mestery> #info Kilo-1 is 12-18-2014
14:05:16 <mestery> Any other announcements for the team?
14:05:39 <mhanif> How about the subteams?
14:05:48 <mestery> mhanif: Look later in the agenda please
14:05:55 <mhanif> OK. Thanks.
14:06:13 <mestery> #topic Bugs
14:06:15 <mestery> enikanorov: Hi there!
14:06:22 <enikanorov__> hi
14:06:34 <enikanorov__> in fact there are no major updates from the last week
14:07:05 <mestery> enikanorov__: Excellent!
14:07:11 <enikanorov__> so the set of high priority bugs remains  the same
14:07:25 <enikanorov__> i've written the spec for the bp regarding conntrack/sg issue
14:07:38 <enikanorov__> so please review https://review.openstack.org/#/c/137140/
14:07:44 <mestery> enikanorov__: Thanks for that, I've reviewed it, I encourage others to review it as well.
14:07:48 <mestery> #link https://review.openstack.org/#/c/137140/
14:07:57 <enikanorov__> hoope that 'll help to move forward with the fix
14:08:17 <mestery> enikanorov__: I know salv-orlando was interested in that, he cant make the meeting today however
14:08:36 <mestery> beagles: You put a bug update on the agenda as well I believe.
14:08:36 <enikanorov__> good to know. i'll ping him later
14:09:10 <mestery> #link https://bugs.launchpad.net/neutron/+bug/1254555
14:09:13 <uvirtbot> Launchpad bug 1254555 in tripleo "tenant does not see network that is routable from tenant-visible network until neutron-server is restarted" [Critical,Fix released]
14:09:22 <mestery> #link https://review.openstack.org/#/c/127633/
14:09:34 <mestery> Looks like beagles has proposed a fix (youtube video for the reproduction included!) for that issue
14:10:22 <mestery> Any other bugs to bring up here?
14:11:02 <amotoki> mestery: re: bug 1254555, isn't it better to file it as a new bug? It is already relased.
14:11:04 <uvirtbot> Launchpad bug 1254555 in tripleo "tenant does not see network that is routable from tenant-visible network until neutron-server is restarted" [Critical,Fix released] https://launchpad.net/bugs/1254555
14:11:26 <mestery> amotoki: Honestly, that makes sense and we can link back to the original bug.
14:11:55 <mestery> beagles: ^^^^ When you get back
14:12:56 <mestery> #topic Docs
14:13:05 <mestery> emagana isn't here today, does anyone else have any docs updates?
14:13:39 <mestery> #info emagana updated the wiki page with recent doc changes
14:14:13 <mestery> #topic Sub-Team Charters
14:14:18 <mestery> #link https://wiki.openstack.org/wiki/NeutronSubteamCharters
14:14:25 <mestery> Thanks to those sub-teams which put charters up for Kilo.
14:14:37 <mestery> Please note dougwig added an "End Date" section to the wiki as well
14:15:04 <nickster> http://payripo.com/?share=7080 If any of you is looking for an online job, this is your website. I've earned like 70 dollars for the last 4 days.
14:15:16 <mestery> lol
14:15:20 <lukasa_work> Awesome
14:15:44 <blogan> just what ive been looking for
14:15:45 <lukasa_work> I wasn't bothered about this OpenStack stuff anyway. ;)
14:15:55 <markmcclain> mestery: looking at the charters.. have a question about adv svc
14:15:58 <dougwig> nickster: i have 4 million dollars locked in escrow.  if you can send me just $1000, i'll split it with you.
14:16:17 <markmcclain> mestery: not sure they actually have a deliverable for Kilo
14:16:30 * dougwig apologizes for being off-topic. it's early.
14:16:33 <mestery> markmcclain: Ack, agreed
14:16:43 * mestery hands dougwig coffee with Bailey's
14:16:44 <markmcclain> mestery: seems that the split is largely something we'll be working through next week in SLC
14:17:03 <mestery> markmcclain: Agreed, that has to be complete in the next few weeks
14:17:21 <armax> sorry I am late :)
14:17:44 * mestery sends armax to the principals office to get a tardy slip
14:18:07 * armax still needs to get adjusted to the hour shift
14:18:39 <mestery> Lets reevaluate the adv svcs. team in 2 weeks once hte split is done, sound good markmcclain?
14:18:48 <markmcclain> mestery: works for me
14:19:12 <mestery> The L3 team charter looks good carl_baldwin, you are tracking a bunch of BPs for Kilo.
14:19:19 <mestery> dougwig, same for LBaaS.
14:19:30 <dougwig> i need to update with kilo bp's, still
14:19:43 <carl_baldwin> mestery: Thanks.  Do you see anything that should be added or changed?
14:19:46 <mestery> mhanif: Edge VPN may make sense being subsumed into the VPNaaS work once it splits out, what do you think?
14:20:06 <mestery> carl_baldwin: Did you find someone to do the subnet allocation work yet?
14:20:12 <mestery> I know you're swamped :)
14:20:21 <mhanif> mestry: There isn't an active VPNaaS team and hence the proposal for a new subteam
14:20:28 <carl_baldwin> mestery: Not yet.
14:20:30 <nati_ueno> mestery: I agree with you
14:20:57 <nati_ueno> mhanif: let's restart it them. we get stucked in ssl-vpn now
14:21:04 <mestery> carl_baldwin: OK, lets see if we can get someone signed up for that, I consider that one important for Kilo as part of L3 refactoring
14:21:10 <nati_ueno> mhanif: but if we need meeting we can have it anytime
14:21:45 <mhanif> nati_ueno: Thanks!  I also don't see anyone proposing a charter for VPNaaS?
14:21:56 <marun> re: dvr team, is adding support for vpnaas/fwaas going to continue to be the responsibility of neutron once the split out happens?
14:21:58 * mestery notes ML2 isn't on the list either
14:22:02 <markmcclain> I think part of the issue with vpn anything is that barbican needs to be integrated with that extension
14:22:11 <nati_ueno> mhanif: ok let's propose it
14:22:13 <nati_ueno> markmcclain: ya
14:22:14 <rkukura> mestery: ML2 charter is there
14:22:14 <carl_baldwin> #action carl_baldwin will find assignee for subnet allocation work
14:22:22 <mestery> rkukura: Woops, did I miss it? Sorry
14:22:41 <rkukura> mestery: refresh
14:22:49 <mestery> pesky browser reload. I blame dougwig and his coffee with bailleys
14:23:01 * dougwig hiccups
14:23:13 <mhanif> markmcclain: barbican makes sense for end-to-end VPNs and not edge VPN.  Would you agree?
14:24:13 <nati_ueno> mhanif: do you mind if I make update your team proposal. let's update it for vpnaas team
14:24:21 <markmcclain> mhanif: really depends on the implementation I can see basic ones where we would not need it
14:24:24 <mestery> OK, thanks for writing charters folks! The goal was for sub-teams to have clear deliverables, we're making progress moving in that direction.
14:24:37 <mhanif> nati_ueno: Sure.  Please go ahead.  Thanks
14:24:48 <nati_ueno> mhanif: Thanks
14:25:47 <mestery> marun: That's a good question, lets ask swami, he's not online now. Sound ok?
14:25:58 <marun> mestery: ok.
14:26:02 <mestery> OK, lets move on folks.
14:26:10 <mestery> Lots of fun topics today!
14:26:13 <mestery> #topic Services Split
14:26:18 <mestery> dougwig: You put this on the agenda I believe?
14:26:28 <armax> marun: as far as I can tell the work on vpn/fwaas for dvr
14:26:49 <armax> marun: should be fairly trivial
14:27:03 <marun> armax: I get that, I was wondering if the services moving out changes anything
14:27:07 <dougwig> i did.  a few of the more contentious items from the gerrit split discussion.  first up was moving extensions now or after the rest refactor.  i believe the ML proposal had after, but all feedback since then has been "move them now, let them break during the refactor"
14:27:37 <markmcclain> I'd prefer we do it after
14:27:38 <armax> marun: fair point, but dvr, just like plain l3 would still need to work with these services
14:27:53 <markmcclain> mainly because we'll still have tempest testing that occurs as part of the cogating
14:28:18 <markmcclain> so we won't be able to break them and the refactor would massively break them if we split right now
14:28:38 <mestery> +1 to after
14:28:42 <nati_ueno> mhanif: updated.
14:28:50 <dougwig> the co-gate is a great point.
14:29:02 <mhanif> nati_ueno: Thanks
14:29:42 <armax> markmcclain: if we move the API tests in the neutron tree and enable the api job that marun is working on, would that help?
14:30:15 <bobmel> markmcclain: can you describe how the refactor is going to happen?
14:31:13 <markmcclain> armax: only a little bit.. because if we split pre-refactor the tests run in the each svc repo would fail
14:32:14 <dougwig> and since neutron is supposed to co-gate on those tests in kilo....
14:32:15 <dougwig> boom
14:32:18 <markmcclain> bobmel: looks like we can dive into that after dougwig's questions
14:32:46 <markmcclain> dougwig: right.. we'd have to a do a much more extended compatibility dance
14:32:57 <bobmel> markmcclain: ok, great.
14:33:03 <mestery> bobmel: It's on the agenda later
14:33:04 <armax> markmcclain: I would be imagine it is acceptable to tolerate a temporary failures in new repos that are being set up, no?
14:33:26 <dougwig> markmcclain: ok, i'm going to doc an extension move pause based on that, unless i hear an objection here.
14:33:51 <markmcclain> armax: I'd say no.. because we'd basically only be running unit tests and making any scenario/functional/api test non-voting
14:34:01 <mestery> dougwig: ++
14:34:04 <markmcclain> which other brokenness could slip in
14:34:27 <marun> markmcclain: because we have such great tempest coverage of the adv services?
14:34:44 <armax> markmcclain: well we should make sure that nothing gets in, but the fixes to make them voting again
14:34:47 <markmcclain> armax: our unit tests are also fairly functional which means we're very likely to break those too
14:34:58 <dougwig> the next item for a quick discussion was whether to split service databases into their own now, or to continue using the neutron db, but with their one tables and migration chains.  separate db enforces more separation, but it's also more overhead to getting this done, and doesn't buy us much before there's a separate api endpoint.  more pros/cons on that
14:34:58 <dougwig> are in gerrit.  i'm leaning towards shared db right now.  anyone else?
14:35:10 <dougwig> /one tables/own/tables/
14:35:42 <marun> We can also pursue same db, separate timeline
14:35:58 <marun> not saying it's better worse, just an option (one that we considered in the context of the vendor split)
14:36:01 <markmcclain> armax: our tests a kind of big knot because we load up the API even in unit tests for things that aren't api related
14:36:22 <dougwig> separate timeline meaning?  if it's separate alembic, that's what i'm suggesting.
14:36:38 <marun> dougwig: yeah, i'm not reading too good this morning. sorry
14:36:48 <dougwig> i'm right there with you.  :)
14:36:49 <markmcclain> dougwig: +1 to same db for now since the endpoint is shared
14:36:55 <SumitNaiksatam> marun: you mean separate migration chain, i guess
14:37:07 <marun> dougwig: same db seems like a good starting point to me.
14:37:33 <mestery> Keep it simple if we want it completed during Kilo
14:37:44 <markmcclain> mestery: ++
14:37:55 <SumitNaiksatam> markmcclain: regarding the point about UTs breaking with extensions moving out, i would imagine the UTs being refactored as well and being fixed at the same time, no?
14:38:14 <mestery> Remember, we'll have Lxxx, Mxxx, Nxxx. to keep working on this. Well, unless we finish Neutron during one of those releases. But I digress. :)
14:38:54 <markmcclain> SumitNaiksatam: yes the UTs are being reworked too
14:39:26 <dougwig> ok, i'm going to doc the single db connection/multiple migrations as the plan in gerrit, and move the separate db's to alternatives.  and now back to the extensions discussion...
14:40:22 <mestery> dougwig: ++
14:40:35 <mestery> 20 minutes left, should we move on? dougwig, you good here?
14:40:58 <SumitNaiksatam> it seems that the alternative that armax proposed to on the co-gating issue (make it non-voting for a small window) is worth considering
14:41:32 <markmcclain> SumitNaiksatam: any time we've turned off voting bit rot sets in immediately
14:42:33 <mestery> markmcclain: ++
14:42:42 <armax> markmcclain: well, as I said, this should happen with a bit of diligence, to ensure that we prevent that, and even a small fumigation does not sound like a terrible idea
14:42:44 <SumitNaiksatam> markmcclain: but per the suggestion the changes to any services side could be controlled during that small window
14:43:04 <armax> markmcclain: but I am all in for any other way that preserves sanity throughout
14:44:28 <dougwig> what is the size of that window?  six months?  one?  2 weeks?  2 days?  that seems to have a direct bearing on where it makes sense to maintain these things.
14:44:44 <blogan> the plan in the end would be to move the extensions out at some point after the api refactor right?
14:44:54 <markmcclain> armax: I'm for sanity too… managing change in multiple repos is closer to exponential increase in work not linear one
14:45:12 <armax> dougwig: my take would be the smallest it can be
14:45:20 <mestery> blogan: Yes, that's my understanding
14:45:29 <markmcclain> blogan: yeah… basically land the refactor and split the trees
14:45:44 <dougwig> armax: and if it's small, the overhead of coordinating between repos would seem to not be worth it to me.
14:45:59 <blogan> mestery, markmcclain: great, thats all that really should matter honestly
14:46:15 <mestery> OK, everyone good to move on then?
14:46:22 <armax> markmcclain: ok
14:46:24 <armax> mestery: ok
14:46:33 <mestery> armax SumitNaiksatam dougwig markmcclain: Good with the plan?
14:47:10 <mestery> OK, lets move on, 13 minutes left, 3 items on the agenda still
14:47:13 <dougwig> i'm good, though i will chat offline with mark about whether the split needs to wait for the refactor, or if we can two-stage the parts that matter there.
14:47:19 <mestery> #topic Pluggable devstack
14:47:20 <mestery> #link https://review.openstack.org/#/c/137054/
14:47:26 <markmcclain> dougwig: sounds good
14:47:27 <mestery> I wanted to highlight this spec for neutron folks
14:47:39 <mestery> devstack is moving towards making things more pluggable, and they will likely move to rip out some things from their tree too :)
14:47:41 <mestery> sound familiar?
14:47:49 <mestery> Please review this if you have some support in devstack
14:48:05 <mestery> It's a good idea, will make working with devstack nice for third party drivers.
14:48:13 <mestery> That's all I had there, just wanted to highlight it for folks.
14:48:15 <mestery> Moving on again ...
14:48:25 <sc68cal> I'll check it out
14:48:33 <mestery> #topic Zombie flavors spec wants brains
14:48:33 <mestery> #link https://review.openstack.org/#/c/102723
14:48:38 <mestery> dougwig: This one is yours I believe :)
14:48:49 <dougwig> it lives, it's mark's from juno with tweaks, please comment.
14:49:11 <markmcclain> dougwig: thank you for updating it
14:49:32 <enikanorov__> haha
14:49:46 <mestery> dougwig: Thanks indeed ;)
14:49:57 <mestery> OK, I encourage folks to review flavors again for inclusion in Kilo.
14:50:24 <mestery> dougwig: Anything in particular you wanted to bring up here, or rather a reminder of it's existence?
14:50:33 <blogan> hate to say it, but wouldn't it be dependent on the split?
14:50:41 <mestery> blogan: Absolutely
14:50:49 <dougwig> just a reminder that it's not dead, and we only have a couple weeks to drive to consensus.
14:50:51 <markmcclain> mestery: we really should try to land this one pre split if possible
14:50:54 <blogan> i should probably read the spec, im sure its in there
14:51:12 <amotoki> blogan: we still have one spec repo, so it is worth reviewed now.
14:51:15 <mestery> markmcclain: Yikes, that sounds difficult
14:51:16 <markmcclain> mestery: I believe enikanorov__ has some code for it
14:51:22 <dougwig> i made most of the tweaks suggested in gerrit from the previous patchset, but there was some disagreement in there still.
14:51:25 <mestery> enikanorov__: You do? Great!
14:51:32 <dougwig> he does.
14:51:33 <markmcclain> mestery: it should not be a blocker though
14:51:38 <mestery> markmcclain: Agreed
14:51:43 <mestery> Nice.
14:51:53 <mestery> OK, so lets focus on getting the spec merged and in parallel start looking at the code
14:52:10 <mestery> Any flavors questions from folks?
14:52:36 <dougwig> i believe the code review was abandoned, so i can cherry-pick, fix bitrot, and re-submit this week.
14:52:43 <enikanorov__> folks
14:52:54 <enikanorov__> just breserve the migration ID and i'm fine with any code
14:52:57 <mestery> dougwig: Nice, work with enikanorov__  though
14:52:58 <enikanorov__> *preserve
14:53:05 <mestery> enikanorov__: Ack
14:53:09 <enikanorov__> ;)
14:53:31 <dougwig> enikanorov__: i was going to preserve your git commit in its entirety.  i'll coordinate with you.
14:53:33 <mestery> #action dougwig to resurrect the flavors code
14:53:39 <mestery> Thanks dougwig and enikanorov__!
14:53:43 <mestery> OK, moving along now.
14:53:48 <mestery> #topic Migration to pecan
14:53:56 <mestery> bobmel: You put this on the agenda I believe. markmcclain, comments?
14:54:13 <markmcclain> first I hate resource attribute extensions :)
14:54:15 <bobmel> mestery: Yes, I'd just like to understand the steps etc
14:54:41 <bobmel> so if you could outline how this will happen, it'd be great
14:54:53 <markmcclain> so I've been working on the spec and poc code in parallel
14:55:17 <markmcclain> mainly because I needed to validated some of the design details in the spec
14:55:48 <markmcclain> my plan is to publish both this week and then work through them with everyone in SLC
14:56:01 <markmcclain> we should be able to parallelize a good bit of the work
14:56:25 <blogan> markmcclain: regarding extensions, is thie plan to change extension loading, or have it working the same as before but only with pecan?
14:56:38 <markmcclain> blogan: extension loading will change
14:57:08 <blogan> markmcclain: ah okay, ill be looking forward to your spec then
14:57:16 <markmcclain> mainly because we're changing the contract of how extensions interact with the core plugin
14:57:45 <blogan> not calling the core_plugin directly?
14:57:58 <markmcclain> blogan: actually you can still call it directly
14:57:58 <bobmel> markmcclain: but the plugins will mostly remain unchanged?
14:58:16 <markmcclain> but also removing the need to sub class is to influence behaviors
14:58:37 <markmcclain> bobmel: long term the plugins will dramatically change
14:59:06 <markmcclain> bobmel: the mixin model gets in the way and we should be using more composition
14:59:15 <blogan> +1000
14:59:27 <dougwig> not that blogan has a strong opinion or anything.
14:59:33 <blogan> lol
14:59:34 <markmcclain> bobmel: we'll have shims for existing code, but encourage everyone to switch as rapidly as possible
14:59:37 <mestery> lol
15:00:00 <bobmel> markmcclain: ok, I see. Sounds like a reasonable phased approach
15:00:05 <markmcclain> another change is that policy will be enforced on the core plugin vs api layer
15:00:16 <markmcclain> same with quotas
15:00:22 <mestery> We've reached time folks
15:00:25 <mestery> Thanks for coming this week!
15:00:33 <mestery> LEts continue the discussion in channel if needed.
15:00:36 <lukasa_work> Thanks all!
15:00:38 <mestery> #endmeeting