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