17:05:34 #startmeeting Networking Advanced Services 17:05:34 maybe add a second chair, in case you drop again 17:05:35 Meeting started Tue Nov 25 17:05:34 2014 UTC and is due to finish in 60 minutes. The chair is SumitNaiksatam. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:05:36 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:05:38 The meeting name has been set to 'networking_advanced_services' 17:06:07 #chair blogan dougwig s3wong sbalukoff sballe 17:06:08 Current chairs: SumitNaiksatam blogan dougwig s3wong sballe sbalukoff 17:06:17 welcome to the party! 17:06:35 #info https://wiki.openstack.org/wiki/Meetings/AdvancedServices#Agenda 17:06:39 <_sunil> hello! I am here representing Embrane! First timer here...:) 17:06:49 _sunil: hi there sunil! 17:07:03 #topic Neutron subteams' charter 17:07:15 _sunil: marcodb too busy? :-) 17:07:28 not sure if we are subteam or a full fledged team 17:07:38 We're the A-Team. 17:07:43 +1 17:07:45 sbalukoff: +1 17:07:50 +1 17:07:54 sbalukoff: yay that! :-) 17:07:57 <_sunil> yeah...:) 17:07:58 +1 17:08:07 but at least prior to the split i think we need to have a charter 17:08:17 i put the most obvious things there 17:08:42 so feel free to edit update as seems relevant (perhaps send an email to the team if in doubt) 17:08:53 anything to discuss on that front? 17:08:58 i noted a distinct lack of unicorns. 17:09:05 lol 17:09:13 * dougwig makes a note in Sumit's permanent file. 17:09:15 dougwig: all the unicorns and rainbows are taken 17:09:27 dougwig: i figured we would do real work :-P 17:09:59 I thought Adv. services had sub-teams in it? Will LBaaS, VPNaaS be part of it or separate sub-teams? 17:10:18 mhanif: we would treat those as subteam as well 17:10:21 Those are included in the purview of advanced services. 17:10:25 sorry, should have posted: 17:10:33 #link https://wiki.openstack.org/wiki/NeutronSubteamCharters#Advanced_Services_Team 17:10:42 unless mestery informs us otherwise 17:11:07 mhanif: this should be clear from the stated adv services charter 17:11:29 SumitNaisatam: Yes, it is. Thanks! 17:11:44 any other thoughts on this? 17:12:25 I have suggested a brand new sub-team Edge-VPN 17:12:44 mhanif: sure 17:13:06 mhanif: perhaps check with mestery as well if there is enough to go around for this 17:13:12 All, please let me your comments or if you have anything to add, please feel free, 17:13:20 mhanif: also would that not be a part of the VPNaaS team? 17:13:55 Will do. 17:14:00 No, since VPNaaS deals with end-2-end VPNs and we are talking about VON's from edge of the data center 17:14:36 mhanif: okay, perhaps best to discuss with the folks currently involved with VPNaaS as well, if there is a way to join efforts 17:14:37 VPNaaS talks about IPSec and L2TP VPNs while edge VPN deals with MPLS VPNs 17:15:07 just a suggestion, since, from a process perspective, i think Neutron is discouraging too many subteams 17:15:15 mhanif: i agree with the technical differences 17:15:19 ok moving on 17:15:31 Sure, open for any discussion there is 17:15:36 mhanif: thanks for chiming in 17:15:43 #topic Project spin out logistics 17:15:58 much anticipated! :-) 17:16:08 dougwig: thanks for taking the initiative to post this spec 17:16:26 #link https://review.openstack.org/#/c/136835 17:16:41 thanks ^^^ 17:16:45 Lots of comments to catch up on there. 17:16:47 i believe there have been a good number of comments and responses already 17:16:53 current hot points are: client? governance? extensions? core vs service plugins? dependencies and upgrades 17:17:04 sbalukoff: looking forward to yours ;-) 17:17:19 dougwig: that pretty much covers most of the spec ;-) 17:17:40 we agree to that we need the split! 17:18:09 i think the governance parts are beyond this spec's scope 17:18:18 i think we can spend good time here to discuss 17:18:21 i hadn't intended to have a governance debate in that spec. i need technical feedback quickly. 17:18:24 ok 17:18:39 yeah, governance is hard to put in a spec 17:18:54 dougwig, blogan: agreed --- difficult for a technical spec to determine governance 17:18:56 blogan: dougwig: xgerman_: well, everything in openstack is a gerrit spec 17:19:09 Heh! 17:19:18 the current governance plan: 17:19:19 We need somewhere to start on the governance question. 17:19:20 #link http://lists.openstack.org/pipermail/openstack-dev/2014-November/050961.html 17:19:24 Yay! 17:19:29 SumitNaiksatam: and maybe there should be a governance spec, but this is just teh technical details on how to do the code split 17:19:29 all governance issues are also being tracked and debated in gerrit specs, not saying good or bad 17:19:45 well, you cna infer my opinion :-) 17:19:52 SumitNaiksatam: +1 17:20:08 blogan: i agree, the counter point is that these are tied at the hip 17:20:15 dougwig: i think one of the reasons for a spec was to capture all aspects of discussion in a focussed manner 17:20:35 well, we practically had crickets on the ML thread. and then we pounce on a semi-related gerrit spec. if y'all want gerrit, make a spec for it. :) 17:20:41 Well... "focused" ;) 17:20:43 of course, personally i definitely favor the pragmatic approach of making progress wherever we can 17:20:49 SridarK: i respect that, but i'm not sure we can swallow that large a rodent in one go. 17:20:50 +1 17:21:04 mmm rodents 17:21:15 yeah, also we are not really self governed so we are discussing things we can't change 17:21:16 dougwig: i agree that this can "rathole" but ... 17:21:17 SridarK: the downside would be that we would be suck into an endless loop of debate on governance issue but never do the actual work since the spec wasn't approved 17:21:34 s3wong +1 17:21:35 s3wong: +100 17:21:42 s3wong: +1 17:21:58 maybe we take a few minutes now and just discuss governance, instead of discussing discussing governance. 17:22:06 Haha 17:22:20 dougwig: Why you gotta be like that, man? ;) 17:22:32 Seriously though, +1 17:22:44 yeah no one likes ratholes! 17:22:47 anyone seen office space, with the whiteboard titled "Planning to Plan" in the background? :) 17:22:57 yes 17:22:57 dougwig: lol 17:23:06 dougwig: what? we don't want to discuss about the merit of discussing governance? :-) 17:23:13 mike judge was a software engineer 17:23:50 we should discuss the plan to discuss about governance then... 17:24:03 on the technical issues, i didn’t see why the extension definition could not be part of the initial split 17:24:15 so i'll throw in my $0.02, which is that it's unlikely we'll see "consensus" on the governance topic, and what Mark proposed can be a workable step forward, so let's take it. 17:24:39 I like to see more self governance 17:24:52 SumitNaiksatam: +1 17:24:54 dougwig: like you said (or may be someone else), sometimes you need let every vent ;-) 17:25:07 *everyone 17:25:27 i'm trying to trigger the venting. :) 17:25:31 dougwig: so now the proposal is (a) API/DB models in "services-tron", (b) different core team with overlap, and (c) spec still driven by neutron-drivers 17:26:02 and extensions remain in neutron tree until kilo-3 17:26:05 s3wong: the API part is fuzzy 17:26:06 (a) API/DB/extensions/plugins/tests in MEGAtron, then yes. 17:26:24 well, control of API. i care not who is listening on port 443. 17:26:30 dougwig: +1000 for megatron if we get it! ;-) 17:26:43 SumitNaiksatam: I think the API part is the one we will have to clearly state in the spec (which dougwig did) 17:26:46 dougwig: yes, API endpoint is not as important 17:26:59 the place for the API definition is 17:27:05 dougwig: +1 --- everything service related (except service_base.py stuff) 17:27:20 blogan: i think kilo-3 is too late 17:27:20 SumitNaiksatam: the issue to me is one of whether to have a breaking change across repos. will leaving the extensions in neutron for and extra month or two slow us down on something? 17:27:58 SumitNaiksatam: well, that was the manager in me making a hedge, in case the refactor takes longer than expected. if don't in kilo-1, then the extensions will move much sooner. 17:27:58 dougwig: even if this is in the main repo, it will be stacked as several patches 17:28:04 dougwig: yes. I think that's harder to keep the extensions there 17:28:15 well i can see a reason why the extensions should stay in neutron in the beginning, and that is because neutron's extension loader will need to have an idea as to wehre to load extensions from an external path 17:28:17 SumitNaiksatam: yes, kilo-3 is practically late for almost everything substantial 17:28:20 ivar-lazzaro: we're talking about a month or two. 17:28:20 if the extensiosn are split out 17:28:25 dougwig: so there will always be a window no matter which way we go 17:28:49 dougwig: and a month can easily stretch out to much longer 17:28:52 no, there's zero window if we wait. how is there a window in that case? 17:28:59 neutron will have to add logic in their extension loaded to load extensions from an external path no? 17:29:07 it already has that. 17:29:11 blogan: that logic already exists 17:29:15 dougwig: I see but we need a good reason to do so. By moving the extension we can work together so that the REST refactor on Neutron's side goes smoothly 17:29:15 well nvm 17:29:17 our path just has to go into the conf file as a default. 17:29:18 ignore me 17:29:55 ivar-lazzaro: i'm not sure that parallelism makes anything faster. the refactor is mechanical work to fit the new framework. by separating, we make that harder, not easier. 17:30:02 dougwig: If we wait instead, we are not guaranteed to catch all the possible issues with the refactor 17:30:04 dougwig: the path part can also be easily sorted (even before it goes into the config file) 17:30:22 ivar-lazzaro: +1 my concern here too 17:30:23 blogan: even Neutron can load extension from different path / package, the hairy part that we try to avoid is the API refactoring gating this 17:30:25 dougwig: i dont necessarily agree with that last statement 17:30:29 i'm not concerned with the loading path. just the refactor overlap. 17:30:49 s3wong+1 17:30:58 s3wong: yeah ive been corrected and punished 17:31:09 I am worried if we have gating things the spin off won't happen 17:31:12 blogan: Neutron can already do that 17:31:30 blogan: I figure I should pour it on you while I have an opportunity to do so :-) 17:31:34 so rather sign up for more work then to gate the spinoff 17:31:58 dougwig: Is refactor overlap bad? Do we really want to hit all the issues once the refactor is completed already? 17:32:09 the impression that i've gotten from folks outside this conversation is that if we put extensions on the MUST list, we will gate the split on the refactor. i don't want that, and i can see at least one technical reason justifying that. 17:32:12 s3wong: I take every opportunity, too. 17:32:17 well if the neutron core thinks that keeping extensions in neutron for the refactor will make it easier, i don't see how they will give that up 17:32:22 xgerman_: +1, hence one of the views is that the split should happen with the extensions, and once the refactor happens in neutron, the same can be done in the services’ repo 17:32:27 blogan: Neutron can already do that! (Just kidding!) 17:32:30 What details about the API refactor do we have? Seems to be a number of unknowns there... 17:32:38 banix: lol 17:32:54 dougwig: so I figure you have been in contact with markmcclain --- do you get a sense that he wants to postpone spinning off the extensions until API refactoring is done? 17:33:10 dougwig: I don't see why this should happen. Sounds like a threat :) 17:33:27 consensus can be a threat. :) 17:33:47 dougwig: blogan: in that sense its not a technical discussion then, its a function of what you are hearing outside this converation? 17:33:53 SumitNaiksatam, all, what concerns me is that other principals, that is non “advanced services” crowd don’t seem to be here 17:34:09 i don't think viewing these things as threat is a constructive path to working well with neutron cores 17:34:17 banix: good point 17:34:19 there are a million reasons to delay, and i am trying to thread a very tiny needle that doesn't gate us on anyone else. personally, i want to be really cautious on where we put our stakes in the ground. 17:34:37 banix: how can we ensure everyone attends? 17:34:56 have the conversation in the neutron meeting would be my first suggestion. 17:34:57 to be fair, its difficult to keep up with so many meetings 17:34:58 dougwig +1 increased velocity is the main reason for splitting 17:35:01 "threat" is strong word, we are showing our goodwill on our willingness to work neutron core/drivers 17:35:11 * work with 17:35:12 we seem to have a vested interest in this, hence we are making the time 17:35:27 i took "threat" as a light-hearted joke up above. 17:35:28 xgerman_: Increased velocity through self-governance? 17:35:39 but yes, the point has been raised before that we should not be discussing in a vacuum 17:35:40 dougwig: it totally was actually 17:36:00 hence we try to figure out during the last meeting whether we needed this meeting 17:36:01 dougwig: I agree, let's put that on the next Neutron meeting agenda 17:36:04 dougwig: my point was that I don't see the reason to wait for the split in order to have the APIs from day one 17:36:14 and the general consensus seemed to be that we did 17:36:21 dougwig: split/refactor 17:36:32 perhaps this meeting is not as effective to get the buy in from people outside the adv services’ team 17:36:32 i think we might be in vi/emacs land on the extensions point. i don't seem much point in pulling over something that will just get broken. 17:36:42 so we should probably push that discussion to the main neutron meeting? 17:36:48 SumitNaiksatam: +1 17:37:06 SumitNaiksatam: I thought this meeting was mostly about trying to drive consensus among the adv.. services team. :) 17:37:21 SumitNaiksatam: yeah i really don’t know…. just raising the concern from past experience. yes may be neutron call may be the place to discuss 17:37:29 If we have a game plan, then we go to the Neutron meeting? 17:37:37 when i roll a new version of the spec with some language around extensions alternatives, and we can chat about it in that meeting, sure. 17:37:38 sbalukoff: and we just have a consensus to punt the decision to the Neutron meeting :-) 17:37:38 yeah, what's the game plan? 17:37:49 man, that was bad grammar. 17:37:52 on my part. 17:38:08 dougwig -- again we split things out. They brake - we fix it... 17:38:11 well we still have disagreement here on the extensions 17:38:13 not a consensus 17:38:23 blogan: Exactly. 17:38:31 blogan: we have a consensus to talk about it during the Neutron meeting :-) 17:38:39 lol 17:38:39 What's the point in taking this to the Neutron meeting prematurely, when we don't even know what we want? 17:38:46 and SumitNaiksatam is so angry that he quitted 17:38:48 sbalukoff +1 17:38:58 s3wong: ha. 17:39:09 sbalukoff: one reason is to get more details 17:39:14 Woot! I'm totally taking credit for that ragequit. 17:39:38 sbalukoff: because we've crossed the threshold of new debate and are cycling. it's either get more voices, or just let someone pick a direction. 17:39:50 guys, I think we all would LOVE to get the extension split off also as step 1 if the Neutron cores are OK with it. Right? 17:40:03 dougwig: Are you saying we need a fearless dicta.... er... leader? 17:40:04 s3wong +1 17:40:04 s3wong: yes 17:40:08 sbalukoff: Neutron core may have other ideas that will influence our plan…. waiting for a complete plan and then taking it to them will not work 17:40:10 ;) 17:40:12 sorry guys, my client acted up again 17:40:12 sbalukoff -100 17:40:13 s3wong: I think it makes a lot of sense 17:40:14 s3wong: no, i'd rather wait for the rest refactor, but it still be in kilo. 17:40:16 so I'm all for whatever gets the split done ASAP. sounds to be like the extension debate would hinder that process 17:40:21 <_sunil> so, lets propose that nd let them nack it...:) 17:40:28 i typed in a bunch of stuff and went into /dev/null 17:40:33 s3wong: +1 17:40:42 SumitNaiksatam: automatic rage filter. 17:40:48 lol 17:40:49 dougwig: ahah 17:40:57 dougwig: ;-) 17:40:57 :-) 17:41:08 Heh! 17:41:32 is everyone afraid that if the extensions stayed in neutron tree then neutron will never give them up? 17:41:54 blogan: i dont think afraid is the right characterization 17:41:59 banix: I'm not saying make a plan and then present it to Neutron core to take it or leave it. They'll leave it, of course. What I'm saying is, we don't seem very unified here, so how are they supposed to work with that? 17:42:01 my fear is that they won't get merged 17:42:15 blogan: I think the fear is that by suggesting extensions in advanced service repo, we can't do split until API refactor is done 17:42:31 blogan: personally, I'm concerned that we may not see issues in the refactor that we would see by having the extensions in the new repo from day one 17:42:37 s3wong: but we can do the split without extensions 17:42:41 ivar-lazzaro: +1 17:42:57 I think it is silly to think that Neutron cores would mandate the extensions to stay in Neutron repo once all DB/API/plugin/....etc are all split 17:42:58 ivar-lazzaro: issues seen on day one are irrelevant, though. 17:43:39 sbalukoff: all I am suggesting that we should bring in those people from right now; if the meeting is not the right place we have to think of other ways to reach them. 17:43:46 blogan: hence I am all for that IF the Neutron core team thinks that "it is best to wait for API refactoring" 17:43:52 dougwig: That's not true, if we feel we need some capabilities from Neutron that it has missing now, then we can make the proposal at refactoring time 17:43:53 dougwig: but day one has to happen sooner, otherwise day one gets pushed to the new cycle 17:44:04 dougwig: instead of finding it out later 17:44:09 s3wong you are on that core them use your jedi minbdtricks 17:44:32 issues with extensions found on day 1 are quite literally code that won't exist in another few weeks. 17:44:33 xgerman_: I am NOT on the core team --- nachi_uno and SumitNaiksatam are :-) 17:44:44 I always get confused 17:44:55 banix: yes i was responding earlier to your comment when i got dc'ed 17:45:09 s3wong: me too, i just want it done and I don't see why neutron would benefit from having the extensions in neutron for a long time after the split, so I trust that they will move the extensions over in a reasonable time 17:45:13 banix: i think we need to have the larger neutron to be a part of this discussion 17:45:14 but i am optimistic 17:45:14 SumitNaiksatam: actually, i think that insisting on extensions from day one is what's going to push the split date. 17:45:21 dougwig: yes, and if those issues persist even after the refactor you lost a cycle :) 17:45:45 ivar-lazzaro: neutron has other external extensions already. this is not new ground. 17:45:51 +1 17:46:12 dougwig: if you really think so --- then there is no point insisting on having extensions from day one. The delay is the #1 thing we want to avoid 17:46:45 dougwig: i havent seen a good argument why extensions should not be a part of split from day one (techincally thats the right thing to do) 17:46:46 Agreed. 17:46:56 +1 17:47:01 dougwig: what i am hearing is that folks ouside this discussion would not agree to it 17:47:07 s3wong: I actually don't see why it should hurt to make the proposal, we don't even know if this will really hold the split back 17:47:07 so we ask for it and if they make us wait we take it off the table 17:47:10 SumitNaiksatam: +1 17:47:29 ivar-lazzaro: yes, so we want a consensus from the team: 17:47:37 <_sunil> SumitNaiksatam: +1 17:47:39 then (a) bring this issue to Neutron meeting 17:47:39 i believe i brought up the fact that breaking refactor changes can happen inside one repo if they stay temporarily. i consider that a good reason. 17:48:01 and (b) if the Neutron core team thinks it is OK. We as a team would be happy to split extension also from day one 17:48:16 s3wong: ok, let's do it. 17:48:30 Yay! 17:48:35 dougwig: it seems like the benefit of splitting out weighs the small window of downtime for that breaking 17:48:36 <_sunil> what;s the worse that could happen?...:) 17:48:52 if splitting extensions out on day 1 does not delay the process I am all for it as well 17:49:04 and (c) otherwise (if Neutron core team thinks it is best to delay until refactoring), we as a team agree to split WITHOUT extension from day one 17:49:09 ok, who decides if it delays? 17:49:10 dougwig: and lets find out sooner what else is broken than wait to K -3 17:49:10 SumitNaiksatam: could you enumerate the benefits? 17:49:13 ask that perosn 17:49:31 xgerman_: I think that's a community decision :) 17:49:33 xgerman: Being told "wait for the refactor" is a delay. 17:50:22 blogan: i think ivar pointed out earlier - but splitting on day one gets us (technically) closer to where we eventually want to be 17:50:36 Yep. 17:50:42 blogan: so if there are issue they are weeded out early in the cycle as opposed to later (or never) 17:50:51 SumitNaiksatam: +1 17:50:53 I am just trying to be pragmatic -- and ivar-lazzaro obviously the community hathered here doesn't make the call 17:51:13 There's a lot of stuff we can do by having the extensions in from day one (approving new APIs without being a burden on Neutron's core) 17:51:27 (assuming we have responsive cores) 17:51:35 ivar-lazzaro: true that is the other big point here 17:51:37 well those features are going to have to be approved by the drivers team anyway 17:51:38 This will gain us enough time to justify the extra effort of fixing the refactor 17:51:56 xgerman_: agreed, hence we bring it up in Neutron meeting. For those who are passionate about splitting extension from day one, please attend the next Neutron meeting to voice your opinions 17:51:58 ivar-lazzaro: now that is another unchartered territory. :-) 17:52:14 okay time check - 9 mins :-) 17:52:23 is pcm here? 17:52:29 also Neutron meeting is oin the middle of thenight for me 17:52:34 SumitNaiksatam: PTO 17:52:37 so then another question, if neutron cores are determined to keep extensions in neutron for now and it will delay the split, do yall still want to hold out for the extensions? 17:52:38 xgerman_: :-) 17:52:39 SumitNaiksatam: pcm pto 17:52:46 xgerman_: but you don't have an opinion :-) 17:53:00 I feel like being banned from the polling place 17:53:37 blogan: I think (hope) the consensus is that if we can't get Neutron cores to OK; then we split without extension on day one 17:53:45 blogan: i believe the opinion being expressed here is to put the extensions split on the table 17:53:45 +1 17:53:51 s3wong: me too 17:54:06 +1 17:54:11 blogan: and udnerstand why it cannot be done, if so 17:54:35 blogan: I think it only makes sense --- I mean, dougwig already compromised :-) 17:54:54 it it cannot be done on day one, we try to understand what would be the alternate (and it be clearly mentioned in the spec in terms of timelines) 17:55:01 SumitNaiksatam: playing devil's advocate here, what if they don't give any "good" reason but still want to keep the extensions in? what is our recourse? 17:55:03 *if 17:55:11 mutany 17:55:12 blogan: :-) 17:55:34 i thought we were having a debate on a “technical” spec, silly me! ;-) 17:55:38 blogan: That's kind of a awkward scenario :D 17:56:00 okay time check again - 5 mins 17:56:03 SumitNaiksatam: so I am good with that. We need to get the reasons from the opposing Neutron cores; and state that in spec; but if the Neutron community / cores/drivers think we should wait for API refactoring, we should NOT gate the split to wait for extension 17:56:40 I'm pretty sure there's a lot of good will between the 2 teams about the split, so the discussion will be held technically 17:56:45 s3wong: i would suggest that we make a call based on the discussion in the spec 17:57:01 shall we transition to the “open discussion” 17:57:09 ivar-lazzaro: very awkard indeed, but i just dont want us going down a path of creating a lot of friction with the neutron cores over this 17:57:15 and continue this discussion, in case nothing else is on anyone’s mind? 17:57:24 blogan: +100 17:57:39 blogan: +1 17:58:00 i am not sure i have the chair any more, someone want to change the topic to “Open Discussion”? 17:58:10 #topic Open Discussion 17:58:15 blogan: thanks 17:58:18 np 17:58:46 anyone has any update on the flavors discussion (dougwig?) 17:59:24 SumitNaiksatam: too ambitious to do flavor in 2 minutes :-) 17:59:27 is dougwig re-proposing it? 17:59:39 yeah, we like flavors 17:59:41 s3wong: yeah silly me again! 17:59:55 blogan: dougwig mentioned he is re-proposing in Kilo 18:00:01 blogan: i believe yes 18:00:03 (during the last meeting) 18:00:10 ok i thought so 18:00:11 yep, that's what he said 18:00:22 he gets to drag that boulder around now 18:00:32 okay we are at the hour 18:00:41 yep, some #chair close the meeting 18:00:54 #endmeeting