13:59:22 <jorgem> #startmeeting neutron lbaas
13:59:23 <openstack> Meeting started Thu Aug 14 13:59:22 2014 UTC and is due to finish in 60 minutes.  The chair is jorgem. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:59:24 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
13:59:26 <openstack> The meeting name has been set to 'neutron_lbaas'
13:59:43 <jorgem> #link https://wiki.openstack.org/wiki/Network/LBaaS
13:59:44 <dougwig> this meeting feels earlier every week.  :)
13:59:53 <blogan> yes it does
14:00:23 <sballe> jorgem, Can we add a quick update on the incubator thing I have been readign about o the ML to the agenda? Maybe mestery ca summarize
14:00:24 <rm_work> yep :(
14:00:28 <johnsom> +1
14:00:30 <sbalukoff> Morning!
14:00:39 <jorgem> sure
14:00:44 <sballe> s/can summarize
14:00:55 <rm_work> poor sbalukoff / xgerman , 6am
14:01:03 <xgerman> 7 am
14:01:08 <jorgem> sballe: that's if mestery will be here
14:01:10 <rm_work> ah whoops
14:01:12 <xgerman> but still bad :-(
14:01:18 <sballe> jorgem, I was confused when I read about it and just want to make sure i understand the rationale behind it as well as if it applies to us
14:01:22 <rm_work> too early for math
14:01:32 <blogan> sballe: it applies to us for shizzle
14:01:44 <jorgem> why don't we start off with that then
14:02:02 <jorgem> #topic Incubator Issue
14:02:20 <dougwig> anyone have the wiki link handy?
14:02:25 <jorgem> I posted it
14:02:29 <jorgem> above ^^
14:02:43 <dougwig> sorry,i meant the incubator wiki link.
14:02:49 <dougwig> (not the etherpad)
14:02:50 <blogan> #link https://wiki.openstack.org/wiki/Network/Incubator
14:02:57 <dougwig> there it is.
14:02:59 <dougwig> thanks
14:03:42 <jorgem> the floor is yours sballe
14:03:54 <sbalukoff> Is mestery here?
14:04:03 <jorgem> sballe: I don't think so
14:04:06 <mestery> sbalukoff: o/
14:04:16 <sbalukoff> Oh, hey! Yay!
14:04:21 <mestery> sbalukoff: Howdy sir!
14:04:22 <xgerman> mestery o/
14:04:24 <jorgem> oh snap!
14:04:24 <sballe> jorgem, I need a recap on this.
14:04:41 <mestery> What can I do for you folks?
14:05:19 <sballe> mestery, I am a little confuse by the incubator thing. Can you summarize it for us?
14:05:29 <mestery> sballe: Yes!
14:05:33 <johnsom> It sounds like FWaaS tanked the neutron test for a couple of days and sparked this off
14:05:39 <sballe> Also will be grand-fathered in since we talked to yu earlier
14:05:54 <mestery> johnsom: There's more than that, it's also coming out of the GBP discussions.
14:06:05 <sballe> This looked to me like yet another process to slow down progress
14:06:16 <mestery> So, the idea is to take large changes which are proposing new APIs and give them a place to bake for a while.
14:06:22 <sballe> and we were trying to increase velocity of LBaaS
14:06:23 <mestery> The exit strategy for incubator is as follows:
14:06:41 <mestery> 1) Merge into neutron once ready. 2) Spin off into a separate project. 3) Die on the vine if developer interest wanes.
14:06:57 * mestery summarizes a large wiki page in 2 sentences there.
14:07:27 * blogan corrects mestery.  That was technically 3 sentences.
14:07:33 <sbalukoff> Haha
14:07:37 <mestery> blogan: ha! :)
14:07:55 <sballe> mestery, What about our LBaaS new APIs? Aren't they already in Neutron?
14:08:10 <blogan> sballe: no they aren't, they haven't been merged in
14:08:13 <sbalukoff> mestery: Can you also summarize the reason it's necessary?
14:08:17 <mestery> sballe: They are making their way in, yes.
14:08:32 <xgerman> so no incubatore for them?
14:08:37 <sbalukoff> mestery: In? Into incubator? Or into neutron core?
14:08:37 <mestery> sbalukoff: We'd like to be able to iterate fast on some new things, nad the current process isn't allowing that.
14:08:48 * blogan is confused
14:08:55 <sbalukoff> I'm really confused, too.
14:08:56 <sballe> *sballe confused too
14:09:00 <mestery> :)
14:09:05 * mestery is doing a poor job of explaining this.
14:09:14 <sballe> * sballe lol
14:09:16 <sbalukoff> Ok, take your time.
14:09:21 <blogan> im just confused by you saying the lbaas new api is on its way into neutron
14:09:32 <xgerman> +1
14:09:34 <mestery> blogan: I just meant the patches are proposed, I think I worded it wrong :)
14:09:43 <blogan> mestery: ah okay
14:09:44 <mestery> "on their way into neutron" == "patches proposed"
14:09:53 <sballe> mestery, but the new API should make it into Neutron. right?
14:09:56 <dougwig> sballe: the potential benefits are being separate but being covered both ways by neutron CI, presumably faster code review velocity,
14:09:56 <dougwig> and still being able to import neutron directly and call its goo and use its db.
14:09:56 <dougwig> sballe: the potential negatives are being neglected by neutron cores, or graduation hurdle being impossible in practice
14:10:24 <mestery> dougwig: Exactly, the graduation hurdle is my main concern, and we're discussing this aspect right now.
14:11:04 <sbalukoff> mestery: I've got more concerns than just the graduation hurdle. But I'd like to get clarification on what sballe is asking first.
14:11:09 <sballe> mestery, dougwig I am also worreid abotu neutron cores neglecting us. Sorry mestery
14:11:21 <mestery> sballe: That is also my concern, and I've brought this up in the discussions.
14:11:25 <sballe> From the website: The current core team for Neutron will initially be core team for the incubator. In the future, the team may decide to add incubator only cores if the need arises.
14:11:32 <rm_work> yeah, it switches us from incremental changes over several months to monolithic merges all at once, don't see how that's good <_<
14:11:33 <sballe> this is what worreis me.
14:11:35 <mestery> These are legitimate concerns for sure.
14:11:41 <sbalukoff> Are the patches presently propoposed going into neutron incubator, or are they "grandfathered in" to core?
14:11:46 <mestery> rm_work: ++, that was the issue I raised as we were coming up with this as well.
14:12:04 <mestery> sbalukoff: That's the part we're still working on.
14:12:27 <dougwig> rm_work: well, it's monolithic both ways.  we're just using gerrit chains as its own repo today.  :)
14:12:39 <sbalukoff> dougwig: +1
14:12:53 <rm_work> dougwig: heh, somewhat… though it's not QUITE as bad T_T
14:12:55 <dougwig> and the chains has not been a pleasant way to iterate.
14:13:09 <mestery> dougwig: I know, the DVR folks would also agree :)
14:13:09 <sballe> mestery, to me it is a mistery how you can have a new version of the LBaaS API in incubtor mode when Neutron LBaaS is not
14:13:09 <blogan> dougwig: +10^100000
14:13:21 * TrevorV is late, but present :D
14:13:58 <jorgem> mestery: In the mean time when will things be solidified (i.e date)?
14:14:15 <rm_work> it's got to be soon, right? code freeze is within a month
14:14:17 <mestery> jorgem: We're working to solidify the plan by next week.
14:14:24 <jorgem> mestery: I feel a nervous investor waiting for the monthly jobs report on WallStreet
14:14:34 <mestery> We spoke to packagers as well, and they seem keen on the idea of packaging this new git repository as well.
14:14:36 <sbalukoff> Heh!
14:14:40 <mestery> jorgem: hahahahahah
14:15:26 <jorgem> mestery: At this point we just want certainty
14:15:30 <sbalukoff> mestery: Where's the most appropriate place for us to talk about our concerns with incubator, and specifically how LBaaS is being affected by it?
14:15:58 <mestery> jorgem: I hear you.
14:16:03 <sbalukoff> (Hopefully prior to things being solidified.)
14:16:14 <mestery> sbalukoff: Lets go with the mailing list, and the weekly Neutron meeting next week as well perhaps.
14:16:23 <mestery> sbalukoff: Makes sense?
14:16:23 <dougwig> it might be useful to step back and view the larger problems that are being looked at:  1) neutron MUST be stable in parts and move fast in others, and one repo makes that harder.  2) there isn't enough core bandwidth.
14:16:23 <dougwig> obviously something has to change structurally.  whether this is it, i don't know.  maybe it's the same problems but with more process.  maybe it screws the L7 guys a bit but helps focus l2/l3.
14:16:48 <sballe> mestery, can we go over each alternative for the LBaaS Apis? If they go into Neutron core then we are ok. What would happen if they go inot an incubator project? When would thye become official openstack project?
14:17:16 <sballe> mestery, Was this the topic you suggested for the ML? I
14:17:40 <mestery> sballe: The nice thing about incubator is that we could incubate them there, and then the team can move them to neutron during Kilo, or even just spin LBaaS out into it's project, which was originally what the team wanted.
14:17:55 <rm_work> mestery: so spin-out is a real option for us from this?
14:18:05 <rm_work> i did perk up a bit when you mentioned that above
14:18:22 <xgerman> yeah, how does the "networking umbrella" relate to the incubator
14:18:24 <rm_work> but didn't want to presume it would actually be possibly for us :)
14:18:29 <mestery> rm_work: ++
14:19:02 <mestery> xgerman: The incubator is under the networking umbrella, the spin out could be also under the networking umbrella, separate git repo/cores, etc.
14:19:12 <blogan> rm_work: why would it be mentioned in the doc if it wasn't possible?
14:19:20 <sballe> mestery, and separate core reviwers? ;-)
14:19:21 <dougwig> sballe: if we force v2 into neutron today, to the community, it'll look like another half-done neutron api.  if we incubate, and the graduation hurdle is a good faith thing (big IF, sorry mestery), then when we promote into neutron is presumably in our hands as to when things harden up, but wouldn't happen before a scalable octavia was in place.  or in that
14:19:21 <dougwig> timeframe, our hidden neutron hooks are addressed (maybe even by us), and oslo has more structure, and we spin out entirely.
14:19:23 <rm_work> blogan: possible for US :P
14:19:26 <mestery> sballe: ++
14:19:55 * mestery thinks dougwig used to be a salesman
14:20:05 <mestery> But seriously, what dougwig is saying is spot on.
14:20:11 <tmc3inphilly> why don't we focus on a stand-alone API for LBaaS and cut to the chase?
14:20:19 <rm_work> tmc3inphilly ++
14:20:29 <dougwig> mestery: i am the worst salesman in the world, believe me.  :)
14:20:35 <rm_work> can we just re-focus on the spin-out from the beginning then?
14:20:45 <xgerman> tmc3inphilly - there are also vendors we need to consider
14:20:53 <blogan> tcm3inphilly: we shouldn't focus on a stand-alone just yet, just let this mature and the people involved in Octavia should focus on Octavia
14:20:57 <sballe> mestery, so are you sayign that the incubated project are "openstack" blessed project.
14:21:23 <mestery> sballe: Yes! We will release the incubator repository, and distros will package it (maybe as experimental or something)
14:21:26 <sballe> so instead of developing it in stackforge (non openstack) they are now part of the opesntack umbrella of projects?
14:21:27 <mestery> blogan: ++
14:21:33 <mestery> sballe: Yes, exactly.
14:21:41 <dougwig> tmc3inphilly: the biggest counter-argument is the hidden interfaces we rely on.  the incubator (or neutron) isn't a bad place to live until those are ironed out, and CI can keep us from getting broken.  i'm thinking fixing that adds one cycle, at least.
14:21:43 <mestery> It's not a stackforge thing, which I know you folks had some issues with in the past.
14:22:17 <mestery> The incubator allows for full CI to be worked on quickly as well (e.g. tempest), CLI, horizon, etc. All that can be done quickly and be ready for merge when the incubated projects are deemed ready.
14:22:25 <sballe> mestery, so who will be able to decide to move from incubation to the next step? is that the same process as other projects e.g. gant, designate, etc..
14:22:27 <mestery> It's what dougwig indicated earlier: Stability in the core, fast iterations on the edges.
14:22:49 <mestery> sballe: I think it's documented in there (at least what we have so far), but projects can propose their own "graduation" into neutron core or spin-out
14:23:07 <sballe> mestery, ok thanks.
14:23:20 <mestery> sballe: This is 100% a part of OpenStack releases, it's not a standalone stackforge thing
14:23:36 <blogan> mestery: will any advanced serviecs that are already in tree be pulled out into the incubator?
14:23:44 <sbalukoff> blogan: +1
14:23:49 <sballe> mestery, we are now running into the issues you and Mark pointed out when you didn;t want us to split from Neutron.
14:23:54 * mestery watches blogan open a can of worms.
14:23:58 <sbalukoff> I'd love to see Neutron LBaaS v1 pulled into incubator.
14:23:59 <mestery> blogan: It's under discussion.
14:24:11 <mestery> sbalukoff: ++
14:24:13 <rm_work> sbalukoff / blogan ++
14:24:14 <sballe> namely how do make sure Neutron doesn't change APIs from under us
14:24:15 <sbalukoff> Since I don't think, today, it would qualify for graduation. ;)
14:24:18 <mestery> sballe: :)
14:24:24 <mestery> sballe: The circle of life
14:24:44 <sballe> mestery, :) Remember that ad-hoc meeting in Atlanta :)
14:25:02 <mestery> sballe: I do, it had larger attendance than some design summit sessions :)
14:25:10 <xgerman> :-)
14:25:34 <juliancash> group hug
14:25:44 <dougwig> sballe; my read of the incubator CI is that it's shared with neutron's, and neutron jenkins will fail if neutron core yanks something that the incubators rely on.
14:25:45 <mestery> juliancash: Hey, great to see you man!
14:25:45 <sbalukoff> mestery and sballe: Yes, indeed. I suspect you're going to see a lot of enthusiasm switching over to Octavia in a hurry if LBaaS ends up in incubator.
14:25:51 <sbalukoff> Well, that might happen in any case. :/
14:26:08 <sballe> mestery, so getting back to my concern. By splitting the project we run the risk that APIs get changed from under us so we are no longer compatible or have to do fancy upgrade trategies
14:26:30 <mestery> sballe: The incubator will prevent that. We'll be running cross-tempest tests to ensure that won't happen.
14:26:45 <sballe> mestery, ok
14:26:53 <mestery> sballe: That will prevent these types of failures while things are there.
14:27:26 <mestery> So, I didn't mean to steal 30 minutes of your meeting today :)
14:27:30 <jorgem> mestery: Is there going to be one repository for all incubated projects or separate repos for each project?
14:27:37 * markmcclain has lots of reading to do
14:27:39 <mestery> jorgem: One repository
14:27:53 <sbalukoff> Hi Mark!
14:28:10 <markmcclain> sbalukoff: hi
14:28:10 <sbalukoff> mestery: So...  projects in incubation can easily step on each other's toed.
14:28:12 <sbalukoff> toes.
14:28:14 <sballe> mestery, why one for all projects
14:28:27 <blogan> sbalukoff: that can happen now with them being in tree
14:28:32 <mestery> blogan: ++
14:28:33 <sballe> mestery, it would make more sense with one per project
14:28:51 <sbalukoff> sballe: +1
14:28:55 <mestery> The logistics of one per project are higher, we're modeling this after oslo.incubator as well
14:29:02 <markmcclain> mestery: ++
14:29:35 * sballe has to do some catching up on oslo.incubator
14:29:55 <jorgem> i still don't know how higher velocity at the "edges" will happen if we don't add more +2ers to the incubated project.
14:29:58 <dougwig> sballe: neutron + incubator is, logically speaking, still just one repo.  that it's two git repos is a function of only part of it being in the mainline shipped package.
14:30:17 <rm_work> so how is neutron-incubator going to be kept in sync with neutron-main?
14:30:25 <sbalukoff> mestery and markmcclain: Realistically speaking, if it's up to neutron core devs to do code merges in incubator as well as the "core" neutron project: What is your strategy for taking on this additional load without starving one project or the other?
14:30:26 <mestery> jorgem: I hear you, and that was my other concern with incubator
14:30:27 <rm_work> i guess i should also look at the oslo-incubator model
14:30:53 <jorgem> mestery: I understand you hear me, but what's the plan?
14:30:54 <markmcclain> sbalukoff: good question… ideally the load will decrease
14:30:55 <sballe> sbalukoff, +1
14:30:56 <mestery> sbalukoff: One idea I had was to allow one "core" per incubated project for the incubator itself. This would only then require one non-incubator core per preojct.
14:31:15 <rm_work> markmcclain: how would load decrease with faster changes? >_>
14:31:21 <markmcclain> right now since we require large features to merge nearly in one unit the patch series gets really really long
14:31:37 <markmcclain> so the incubator will allow you to land partial implementations
14:31:41 <dougwig> the more non-core reviewers, the harder graduation.
14:31:47 <markmcclain> which should be smaller patches
14:31:53 <rm_work> yeah, but that means a higher review-count overall
14:32:02 <rm_work> and there's overhead there just for a review existing
14:32:27 <markmcclain> small reviews are much easier to get done.. lots of folks will avoid ones that more than 2 cups of coffee :)
14:32:40 <sballe> ok I am a little confused about this repo thing. Let's say I only want LBaaS and not some other incubated project. That doesn't sound possible
14:32:58 <dougwig> presumably, the reviews are easier, because there are a host of things that don't have to be worried about until graduation: is this thing fully working, is 3rd party CI fully in place, ...  it's more of just, "does this code look reasonable", as opposed to "does the entire big picture work, and is it perfect".  those are two very different review standards.
14:33:06 <dougwig> please correct me if i'm guessing wrong.
14:33:07 <mestery> dougwig: ++
14:33:13 <markmcclain> sballe:  so you install the library for the incubator and then activate the features you want
14:33:24 <sbalukoff> Also, with no set deadlines in incubator (which is generally good), this means that work with deadlines attached (eg. unified OpenStack release deadlines) is naturally going to get prioritized over that. So with a team with already too much work, I would expect incubator to get starved.
14:33:24 <markmcclain> dougwig: +1
14:33:45 <sballe> markmcclain, ok I am perfect world
14:33:54 <xgerman> sbalukoff +1
14:34:04 <dougwig> sballe: neutron today is one big repo, and you activate the parts you want.
14:34:08 <markmcclain> sbalukoff: actually you get more attention at points in teh cycle when the integrated release forces us to be quiet and not merge code
14:34:42 <mestery> And since it's an incubator, as dougwig says, the hope is we can merge thigns which are not 100% complete.
14:34:43 <blogan> sbalukoff: that also means that when code freezes happens the incubator is not subjeted to that and reviewers should have time
14:34:46 <sballe> dougwig, I understand.
14:34:47 <mestery> With the expectation they are on their way to completion
14:34:50 <mestery> Iterate fast
14:34:59 <mestery> blogan: ++
14:35:14 <ptoohill> I see a rush at the end having to ho back and re review everything's working since we let small syntactically correct commits in.
14:35:20 <tmc3inphilly> blogan: -1
14:35:22 <ptoohill> Go*
14:35:24 <sbalukoff> Are reviewers sitting on their thumbs when code freezes happens, right now?
14:35:35 <sbalukoff> I suspect there's plenty to occupy their time then, too. :/
14:36:04 <blogan> sbalukoff: could be, i'm just saying its possible this will work, and its possible it won't
14:36:24 <dougwig> ptoohill: i didn't mean to imply that crap reviews are let in.  just that blogan's first patch could've been approved in early july, e.g., and if it had minor issues that were discovered later, and second patch could been done and gone in, instead of everything waiting.  i hope.
14:36:27 <sbalukoff> I'm very skeptical that it's going to work. :/
14:36:30 <jorgem> blogan: That uncertainty is what worries me
14:36:39 <rm_work> also very skeptical <_<
14:36:39 <sbalukoff> Or result in increased velocity at all.
14:36:45 <jorgem> blogan: The ideas look good on paper, it's about executing  it right.
14:36:52 <sballe> I am wtill worried taht neutron core will take precedence over incubator projects and we won;t gain any velocity.
14:37:01 <xgerman> sballe +1
14:37:10 <sbalukoff> sballe: Or rather, lose what little velocity we have. :/
14:37:18 <markmcclain> I actually think you'll get more
14:37:18 <rm_work> it's just hard for me to see how "reducing the commit requirements up front" will save us time down the road
14:37:26 <xgerman> can we get on of us promoted to incubator core quickly?
14:37:34 <sballe> sbalukoff, +1
14:37:55 <xgerman> that might help with velocity
14:38:07 <sbalukoff> So.... let me be frank.
14:38:10 <dougwig> rm_work: it basically lets us assemble and iterate on the gerrit chains in one place.  right now, collaboration is much harder.
14:38:20 <sbalukoff> My mind keeps going back to that impromptu meeting in Atlanta.
14:38:24 <ptoohill> Dougwig, understood. But without cohesive units of code I don't see 'smaller' commits being that much more beneficial then sitting through a 'large' one
14:38:25 <rm_work> I guess I have just gotten used to the chains ;P
14:38:28 <TrevorV> There will be the potential for partial commits, granted, that's a good thing.  However, we still have only what, 2 windows of time in the year where we're expected Core Reviewer attention?  That doesn't seem like high velocity.
14:38:30 <mestery> At the end of the day, we're trying to maintain waht stability the team has worked hard to build up during the previous releases, while allow for new things to grow and find their way into neutron.
14:38:47 <mestery> It's a tough balance, and we may get somethings wrong, but we'll revisti what doesn't work and make adjustements as we go.
14:39:06 <sbalukoff> You know, the one where I told y'all that along with the trust you were looking for from us (to be able to write good code), that we didn't presently trust neutron core devs to be able to deliver...
14:39:32 <sballe> mestery, I undertsnad hwat you are saying we just have deliverables that need to amke it into our products and all this is not allowing us to make progress
14:39:39 <rm_work> dougwig: yeah, but then thing thing that's assembled still has to go through the more stringent review process at the end, since there's no guarantee it's full up-to-par, so we're back at the same place we were originally it seems, as far as reviewer bandwidth goes (maybe it does help with dev)
14:39:51 <sbalukoff> If the LBaaS changes presently under review end up in incubator (which it looks very likely they will be, since every time incubator is mentioned, LBaaS is mentioned as a "prime candidate" for inclusion there)...
14:40:17 <sbalukoff> That basically means I was right: That we couldn't trust y'all to help us get the LBaaS v2 stuff into Juno. :/
14:40:20 <mestery> rm_work: If that happens, then we've failed at this, I agree. I don't want to see that happen.
14:40:34 <sbalukoff> Which makes me, for one, less inclined to trust what you're saying about neutron incubator.
14:40:37 <sbalukoff> So...
14:40:48 <sbalukoff> To me that means we should push for spin-out earlier.
14:41:02 <sbalukoff> So that we can stop dealing with this nonsense. :P
14:41:07 <dougwig> rm_work: only if we lack core involvement throughout, in which case we're doomed to get into neutron anyway.
14:41:17 <rm_work> yeah, i think the possibility of just going straight from incubator to our own project is the most promising thing to come out of this from my perspective :P
14:41:36 <sballe> mestery, I agree with sbalukoff. You and Mark some promises  to help us increase velocity for LBaaS and we are now down in a rat hole
14:41:36 <xgerman> if we want to do that we can skip the incubator IHMO
14:41:37 <sbalukoff> Now, I think I understand why incubator is being invented.
14:41:50 <sbalukoff> And it's honestly probably the right way to go-- I wish it had been in place a yaer ago.
14:42:12 <tmc3inphilly> the best part is we have to tell our upper managment teams that v2 will not be in Juno as we had planned and that we have no idea of when/where it will land
14:42:13 <markmcclain> well sballe that rat hole is a function of requiring full features to merge in master
14:42:17 <sbalukoff> But, that doesn't change how things have gone for us over the last few months. :P
14:42:25 <mestery> sballe sbalukoff: I'm sorry you feel this way, and it's not our intention to do this at all.
14:42:30 <markmcclain> the 5k loc that blogan is carrying would have been merged in the incubator system
14:43:35 <xgerman> understood. We all think the incubator is a great idea we are just concerned about the timing
14:43:49 <xgerman> hence we like to be grandfathered to make our deadlines...
14:43:54 <sballe> xgerman, +1
14:44:14 <sbalukoff> And so that we can tell our bosses that the work we've been doing for months isn't completely wasted.
14:44:16 <TrevorV> markmcclain, the code would have been merged, sure, but our desire to have it all in Juno was moot since we'd be waiting for core reviewer attention until Juno code freeze.
14:44:20 <dougwig> xgerman: well, the incubator is a great idea if it's done in good faith, and trust is a little shaken right now, so that's a harder pill to swallow.
14:44:32 <sbalukoff> That sort of helps with being able to commit to more work on the project in the future.
14:45:40 <TrevorV> I'm gonna shoot myself in the foot here, and say the incubator doesn't need to exist.  It doesn't make sense.  Neutron as a code base is too saturated as it is today, and making a more massive code base, no matter how slowly, doesn't solve the problem of it being too fat to handle with its number of core reviewers.
14:46:04 <sbalukoff> Well...
14:46:08 * mestery notes his email about ripping 30k+ lines of code out of neutron by removing all plkugins and drivers
14:46:17 <johnsom> xgerman Agreed.  Maybe move the "experimental" projects first and let us land in Juno
14:46:21 <sbalukoff> Ultimately I feel like neutron should be one compoenent in a "networking" project.
14:46:23 <mestery> To me, that's the real root of the problem.
14:46:26 <mestery> But I digress.
14:46:29 <sbalukoff> A component that handles layer-2 and layer-3 stuff.
14:46:30 <markmcclain> TrevorV: that is a separate issue as mestery points out on the list to tackle
14:46:49 <sbalukoff> And that the advanced services stuff should just be other sub-projects of networking.
14:46:53 <xgerman> I juts got up for that meeting
14:46:59 <sbalukoff> Sort of on equal footing with Neutron in this case.
14:47:00 <xgerman> no list reading yet
14:47:13 <markmcclain> also remember the incubator makes it easier for us to spin out projects
14:47:15 <dougwig> mestery: did i miss that email?  when/where?
14:47:16 <sbalukoff> It also limits the scope of Neutron to something more manageable and well-defined.
14:47:25 <mestery> dougwig: This morning, at least I thought I sent it.
14:47:29 <markmcclain> oslo has a well established way of bootstrapping new projects
14:47:30 <mestery> dougwig: It was a reply to Salvatore
14:47:49 <xgerman> markmcclain spinning out != Open Stack project
14:47:54 <blogan> johnsom: i would actually argue that v2 is fairly experimental
14:47:59 <markmcclain> xgerman: actually it can
14:48:15 <xgerman> so you would spin into the OpoenStack incubator?
14:48:18 <dougwig> mestery: found it, thanks.  :)
14:48:18 <rm_work> xgerman: i thought he just meant spinning out of Neutron… so we could actually spin-out to Openstack-LBaaS
14:48:21 <sbalukoff> blogan: Agreed.
14:48:26 <markmcclain> oslo spins out projects frequently and those are part of OpenStack and participate in release
14:48:46 <sballe> xgerman that is what mestery said earlier spin out == incubator openstack project
14:48:47 <xgerman> so they don't have an OpenStack incubation requirement
14:48:52 <markmcclain> xgerman: yes we can move things into too (oslo has done so with several libs)
14:49:05 <dougwig> blogan: +1
14:49:41 <blogan> if we agree v2 is experiemental, and this incubator is godo for experiemental extensions/features, then this is the right place for it to go.  But there is that trust factor that got shaken
14:50:11 <dougwig> +1 again.  don't make a habit of this.
14:50:22 <sballe> blogan, +1
14:50:34 <TrevorV> markmcclain, I'm sorry but I fail to see the disconnect in the issues.  The problem we're having here is a direct extension of a bloated code base and lack of core reviewers.  Why not fix the root of the problem?
14:50:37 <mestery> I'm sorry people feel like their trust has been misused, that was never anyone's intention here.
14:50:37 <sbalukoff> blogan is far too nice.
14:50:46 <sbalukoff> And I'm far too much of an asshole
14:50:52 <markmcclain> TrevorV: these things take time
14:50:52 <mestery> sbalukoff: Balance in the force.
14:50:57 <sbalukoff> Haha
14:51:13 <dougwig> sbalukoff: +1 on both!  :)
14:51:41 <dougwig> 9 minutes
14:51:46 <sbalukoff> blogan is right that incubator is probably the way to go.
14:52:12 <sbalukoff> But I do feel like LBaaS has been held up as a human shield in the battle between neutron core devs and the people behind GBP. :P
14:52:29 <blogan> good thing I'm a good human shield, ill stand in front
14:52:35 <sbalukoff> Haha!
14:52:38 <blogan> ive got lots of mass
14:52:41 <sbalukoff> Yeah, I'm pretty meaty.
14:52:49 <blogan> meat shield!
14:52:50 <mestery> sbalukoff: Don't forget FWaaS, root wrap, tap as a service, etc.
14:53:00 * mestery has a long list of these things
14:53:10 <sbalukoff> mestery: So, there are lots of casualties.
14:53:11 <xgerman> lot's of shields...
14:53:16 <sbalukoff> I don't think that helps your case. ;)
14:53:40 <mestery> many shields
14:53:40 <sbalukoff> *sigh*
14:53:41 <mestery> :)
14:53:53 * mestery has taken many bullets this cycle.
14:54:08 <mestery> I've run out of asbestos suits to be honest.
14:54:10 <sbalukoff> Yeah, it's been a tough cycle.
14:54:16 <sballe> ok how do we move forward here?
14:54:31 <jorgem> we work on Octavia until the dust settles
14:54:33 <rm_work> BTW, do we actually have any other agenda items? or is this basically it for us, for this meeting? (since we lose all of our velocity at this point)
14:54:38 <tmc3inphilly> mestery: isn't that in the job description? :-)
14:54:39 <markmcclain> I'm likely to have to patches ready for incubator ready today
14:54:41 <mestery> I believe markmcclain has patches almost ready for incubator
14:54:44 <sballe> mestery, when will you know more about the incubator project?
14:54:48 <mestery> markmcclain: perfect timing
14:54:53 <sbalukoff> jorgem: +1
14:54:58 <dougwig> jorgem: +1
14:55:03 <markmcclain> and we can work to get code merge there fairly quickly
14:55:07 <dougwig> let's not lose focus on process and glue crap.  that can all wait.
14:55:13 <blogan> rm_work: if it gets into the incubator, i dont' see how we lost velocity
14:55:13 <sballe> jorgem, =1
14:55:28 <rm_work> blogan: we've lost velocity for this week, since there is no incubator yet :P
14:55:32 <blogan> hell if this dependency chain goes away bc it got into the incubator, and no more accidental rebases happen, that'd be great
14:55:34 <crc32> jorgem >=1
14:55:37 <jorgem> one thing I'd like to ask, can we not be the test subjects for this???
14:55:39 <rm_work> so basically we work on other stuff until incubator happens
14:56:01 <jorgem> I'd like to focus on Octavia while the intricacies are figured out
14:56:02 <mestery> jorgem: Sure, I think GBP is a meatier candidate for being the test subject.
14:56:10 <jorgem> mestery: good
14:56:18 <blogan> rm_work: that wast he plan all along anwyay, work on Octavia after it gets into Juno.  Juno is now just the incubator
14:56:22 * mestery pulls on his kevlar.
14:56:36 * dougwig reloads.
14:56:48 <dougwig> jk
14:56:49 <sballe> mestery, +1 Go GBP :)
14:57:10 <rm_work> blogan: yeah, just saying we're blocked for this week at least, until incubator gets figured out
14:57:19 * TrevorV carries the extra ammo for dougwig
14:57:25 <mestery> Incubator will be up by tomorrow I think.
14:57:28 * TrevorV is also jk
14:57:30 <rm_work> so i guess we don't have anything else for the meeting
14:57:33 <jorgem> mestery: Thanks, due to deadlines we all thought we had any more distractions would look bad on our part when we bering this up to our upper management
14:57:37 <blogan> rm_work: code can still be created, reviews too, they'll just be moved to the incubator
14:57:50 <sballe> jorgem, +1
14:58:15 <dougwig> 1 minute.
14:58:37 * mestery thinks dougwig is a stopwatch automaton.
14:58:45 <sbalukoff> He's totally a bot.
14:58:47 * TrevorV thinks mestery is right
14:58:56 <rm_work> mestery: if the incubator is up by tomorrow, that implies the time for discussion about it was actually over before now, btw… wish that had been mentioned :P
14:59:08 * dougwig seg faults.
14:59:10 <mestery> rm_work: Valid and fair point.
14:59:15 * mestery reboots dougwig.
14:59:18 <rm_work> could probably have saved some breath, lol
14:59:23 <rm_work> ah wel
14:59:24 <sbalukoff> Heh
14:59:26 <vjay> +1
14:59:41 <sbalukoff> Well, at least we got to voice our grievances here. :P
14:59:50 <sbalukoff> Even if there's nothing that can be done about them now.
15:00:01 <rm_work> yay whining! :)
15:00:05 <TrevorV> sbalukoff, venting session complete?
15:00:05 <sbalukoff> Haha
15:00:10 <sballe> lol
15:00:14 * rm_work finishes eating his cheese
15:00:25 <mestery> rm_work: Cheese for breakfast?
15:00:27 * dougwig comes back online.
15:00:28 <sbalukoff> Well, thanks y'all!
15:00:29 <jorgem> okay meetings over. See you guys on the other channel.
15:00:29 <TrevorV> rm_work, you ARE cheese.
15:00:30 <rm_work> always enjoy some cheese with a good whine
15:00:31 <jorgem> thanks!
15:00:33 * mestery goes to get some coffee
15:00:34 <vjay> thanks!
15:00:36 <xgerman> thanks
15:00:37 <sballe> bye :-)
15:00:38 <jorgem> #endmeeting