15:31:39 <mestery> #startmeeting neutron-drivers
15:31:40 <openstack> Meeting started Wed Dec  3 15:31:39 2014 UTC and is due to finish in 60 minutes.  The chair is mestery. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:31:41 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:31:44 <openstack> The meeting name has been set to 'neutron_drivers'
15:31:53 <mestery> #link https://wiki.openstack.org/wiki/Meetings/NeutronDrivers Agenda
15:32:02 <mestery> Mostly today I wanted to highlight a few specs, and then more generally look at where we're at for approving specs.
15:32:05 <mestery> Sound good?
15:32:19 <mestery> #topic Subnet API specs for Kilo
15:32:23 <mestery> #link https://review.openstack.org/#/c/135771/
15:32:33 <mestery> salv-orlando: I think you've looked at this one a bit, along with myself.
15:32:46 <salv-orlando> mestery: I did.
15:32:51 <armax> mestery: that’s next on my list
15:32:58 <mestery> carl_baldwin indicated he has an assignee for htis now, which is great!
15:33:23 <mestery> I think we should work to get this into Kilo, salv-orlando, what do you think?
15:33:44 <salv-orlando> mestery: we can but the priorities are a bit subtle
15:33:56 <salv-orlando> we need this partially implemented for doing pluggable IPAM
15:34:11 <salv-orlando> so it’s partially a requirement - at least according to the plan currentl laid out
15:34:30 <mestery> salv-orlando: Yes, I think it's a straightforward change as well, though it is an API change
15:34:31 <salv-orlando> The full support for subnet pools, exposed through the API can then come after pluggable IPAM is introduced
15:34:51 <salv-orlando> no API change is every straigthforward ;)
15:34:53 <mestery> Makes sense to me
15:34:56 <mestery> lol
15:35:15 <salv-orlando> but the point is that for kilo we absolutely need that bit that allows us to do pluggable IPAM
15:35:18 <markmcclain> hi… sorry call ran long
15:35:19 <salv-orlando> so I think it’s ok to approve.
15:35:29 <mestery> Right
15:35:31 <mestery> Good
15:35:32 <salv-orlando> once of course we do all the nitpicking as usual
15:35:37 <mestery> :)
15:35:39 <salv-orlando> we love to nitpick after all, don’t we?
15:35:44 <armax> salv-orlando: give me the chance to review
15:35:53 <mestery> armax: Of course
15:35:56 <mestery> Next one
15:35:57 <mestery> #link https://review.openstack.org/#/c/135453/
15:36:08 <mestery> Paul Ward asked me to have us look at this one too
15:36:11 <mestery> Along with carl_baldwin
15:36:20 <wpward> Thanks for adding it, Kyle
15:36:38 <mestery> wpward: Sure, happy to highlight it!
15:36:53 <mestery> wpward: I have not reviewed this one yet, but will do so today
15:37:13 <mestery> Looks like salv-orlando has already reviewed
15:37:27 <mestery> wpward: We'll look at this one and go forward from there.
15:37:29 <salv-orlando> I have reviewed the spec this morning. Carl did it as well. I have nothing against it, but on the other hand I am still wary of seeing new attributes popping up in core resources.
15:37:52 <salv-orlando> I will talk about this with carl_baldwin because it seems he had already plans for introducing a feature like this
15:37:58 <wpward> salv-orlando: an understandable concern.... is there a different way to accomplish it?
15:38:18 <wpward> Yes, Carl mentions a few BPs that are related.  This one is a smaller subset but would be a good start to get his going as well.
15:38:29 <salv-orlando> wpward: subnet-level dhcp options, or we’ll talk to carl to see how it fits in the changes proposed for spec #135771
15:39:16 <salv-orlando> anyway, this is something we can keep discussing on the gerrit review page (also becase Carl is not here). So mestery, if you want to move to the next one I’m ok with it
15:39:17 <wpward> salv-orlando: Ok.  I think one thing we want to maintain is the ability to do this for static networks as well, where dhcp is not in the picture.
15:39:28 <mestery> salv-orlando: Ack
15:39:38 <mestery> #topic Blueprint Tracking
15:39:59 <mestery> #link https://review.openstack.org/#/c/136835/
15:40:00 <mestery> Services split
15:40:03 <mestery> I think it's very close
15:40:12 <mestery> And I had 3 new repositories created with infra yesterday as well
15:40:22 <mestery> salv-orlando markmcclain armax amotoki: What do you folks think?>
15:40:39 <mestery> I mean, we could keep nit picking it, but at some point I think we can call it baked.
15:40:50 <salv-orlando> mestery: I think it needs a rewiew from armax at least!
15:40:55 <mestery> lol
15:40:57 <armax> mestery: I had the same feeling
15:41:05 <mestery> armax: OK, lets wait on this one.
15:41:07 <armax> salv-orlando: I did
15:41:10 <salv-orlando> I’m pretty sure after his review it will be a lot farther from being ready
15:41:14 <markmcclain> haha
15:41:16 <mestery> Wait, you reviewed it armax?
15:41:25 <salv-orlando> armax: yes he did.
15:41:27 <armax> salv-orlando: but not one on a fresh  ps
15:41:39 <mestery> Regardless, lets wait on this one then.
15:41:41 <salv-orlando> I searched comments for armax, I forgot we use real names on gerrit!
15:41:53 <mestery> lol
15:41:58 <armax> salv-orlando: I make people’s lives easier having a simple nick
15:41:58 <mestery> OK next one
15:42:00 <mestery> #link https://review.openstack.org/#/c/134680/
15:42:02 <armax> not like salv-orlando
15:42:06 <armax> :)
15:42:12 <mestery> This is armax and marun's decomposition spec
15:42:26 <mestery> It's been nit picked, looks ready to me. Thanks for addressing my last pedantic nit armax. :)
15:42:29 <salv-orlando> I’m soft ok with it.
15:42:49 <salv-orlando> meaning that I’m ok as long as the other folks in the core team don’t have a grudge with it
15:42:52 <armax> mestery: no worries
15:43:10 <mestery> I'm good with this one, I think the plan is laid out well and like I said, my last nit was addressed.
15:43:28 * salv-orlando waits for somebody to speak against this spec....
15:43:28 * dougwig puts split spec back in the oven at 425 degrees.
15:44:03 <mestery> Going once ...
15:44:07 <salv-orlando> if nobody opposes it anymore, the lazy consensus principle tells us what to do
15:44:08 <armax> mestery: if there’s rejection later, it won’t be the first time that a merged bp fails to complete :)
15:44:12 <mestery> lol
15:44:13 <markmcclain> sorry was looking over who's commented on it
15:44:28 <armax> markmcclain: you havent :)
15:44:37 <amotoki_> sorry i am late. I am just back to home.
15:44:38 <markmcclain> I think I've said enough in person :)
15:44:45 <mestery> amotoki_: No worries :)
15:44:53 <mestery> markmcclain: lol
15:45:08 <armax> markmcclain: true enough, in fact I am not complaining, I figured you were tired to hear the same stuff over and over again :P
15:45:12 <salv-orlando> /me is fairly sure no spec high-fiving is occurring this release cycle
15:45:44 <mestery> OK, lets assume htis one will merge by Friday and move on.
15:45:53 <mestery> I don't see any huge blockers right now.
15:45:54 <marun> er
15:45:58 <mestery> ?
15:46:03 <marun> the way it reads the work has to be done in kilo
15:46:10 <marun> mestery: weren't you advocating for more time?
15:46:19 <marun> i.e. done by the end of L
15:46:21 <mestery> marun: The wording was adjusted by armax, I am happy with the new wording.
15:46:33 <armax> marun: let’s say that the work has to start in Kilo for sure
15:46:35 <mestery> marun: I only meant that if people put in a good effort for K, but fail to reach the goal, we are lenient with them.
15:46:44 <mestery> marun: If people do no work, then it's a different story.
15:46:53 <mestery> armax addressed my comments in the latest version
15:46:53 <mestery> I'm good
15:46:54 <armax> mestery: yes, that’s the gist of it
15:46:56 <salv-orlando> I think plugin maintainers are hiring lawyers to understand what they can and what they can’t do ;)
15:47:01 <mestery> rofl
15:47:04 <marun> 'required to be rewritten in kilo' seems pretty definitive
15:47:05 <armax> salv-orlando: nice one!
15:47:14 <marun> I'm not complaining, just making sure that was your intent.
15:47:44 <armax> marun: it is, but at the same time we can open up the possibility of reevaluating where we are a couple of months down the rouad
15:47:50 <salv-orlando> armax: that where a guy like our old friend Donal would come handy. He was both a lawyer and an engineer
15:47:59 <mestery> marun: Line 354
15:48:04 <mestery> Start there for the new wording
15:49:08 <armax> mestery: truth to be said, if you started…it should be possible for you to complete as well
15:49:23 <armax> mestery: but one never knows
15:49:25 <mestery> armax: Yes, I was just looking out for folks here.
15:49:25 <marun> mestery: I guess I see 339 as conflicting with 354.  maybe 354 should simply be removed
15:49:39 <mestery> I've already had a few talk to me privately about this, not defending folks, just looking to balance things a bit.
15:49:39 <marun> but I'm niggling.  probably nobody will care.
15:49:53 <mestery> marun: Your point is valid
15:50:02 <armax> I can say ‘should’ instead of will?
15:50:13 <amotoki_> I think "should" or "strongly recommended" is an appropriate wording based on our discussion so far.
15:50:18 <armax> ok
15:50:20 <mestery> amotoki_: ++
15:50:21 <marun> +1
15:50:25 <armax> another rev coming up
15:50:28 <mestery> armax: Cool
15:50:33 <armax> dougwig: you said your is at 425F?
15:50:44 <armax> I’ll put mine at 390F
15:50:45 <mestery> lol
15:50:48 <dougwig> armax: yes, but it's a convection oven
15:50:53 <mestery> OK, lets move on
15:50:53 <mestery> Next up: rootwrap
15:50:55 <mestery> #link https://review.openstack.org/#/c/93889/
15:50:59 <mestery> salv-orlando: A nrew rev was done, I think we can just approve now.
15:51:02 <mestery> You had already done so in fact
15:51:03 <mestery> :)
15:51:07 <armax> dougwig: :)
15:51:17 <markmcclain> mestery: +1
15:51:18 <salv-orlando> mestery: doing that now
15:51:25 <mestery> Excellent! That was easy.
15:51:28 * mestery looks out for the trap
15:52:06 <salv-orlando> pretty sure there is hidden line saying that people +2ing that spec will become enslaved to the spec author
15:52:20 <mestery> rofl
15:52:34 <salv-orlando> anyway, next one
15:52:42 <mestery> #link https://review.openstack.org/#/c/105660
15:52:45 <mestery> DHCP Agent Refactor
15:52:58 <mestery> This one hasn't been updated in a long while
15:53:02 <mestery> Wait
15:53:05 <mestery> This is relay not refactor
15:53:07 <mestery> hold on
15:53:13 <markmcclain> do we have bandwidth for this?
15:53:22 <salv-orlando> mestery: you have to do a bit of refactor for doing a relay
15:53:40 * mestery needs more coffee
15:53:58 <mestery> #undo
15:53:59 <openstack> Removing item from minutes: <ircmeeting.items.Link object at 0x3c050d0>
15:54:00 <salv-orlando> but I would also say that I have not seen a blueprint for “refactoring the DHCP agent"
15:54:02 <mestery> #link https://review.openstack.org/#/c/137808/
15:54:06 <mestery> L2 Agent Improvements
15:54:12 <mestery> From rossella_s
15:54:17 <mestery> This one I haven ot reviewed yet
15:54:21 <mestery> Looks like armax has at least :)
15:54:30 <armax> yay!
15:54:34 <mestery> lol
15:54:41 <armax> I am first, for once
15:54:48 <salv-orlando> armax: are you sure?
15:54:50 <rossella_s> I think salv-orlando was first
15:54:52 <armax> can’t compete with you guys I am slooooow
15:54:55 <armax> damn
15:55:00 <armax> I thought I had it for a sec
15:55:03 * mestery gives salv-orlando a gold star
15:55:07 <salv-orlando> armax: thanksgiving played to my advantage
15:55:21 <armax> but salv-orlando and I are technically interchangeable
15:55:33 <salv-orlando> anyway it’s getting in good shape. We just need a sync-up with otherwiseguy to separate responsabilities
15:55:42 <salv-orlando> and a contribution from marios for functional testing
15:55:44 <armax> I’ll look at it again
15:55:53 <mestery> ++
15:56:06 <mestery> #action neutron-drivers team to review L2 Agent Improvements spec
15:56:09 <salv-orlando> anyway, if this should miss the deadline I guess nobody would object ane xception
15:56:26 <marun> :/
15:56:46 <mestery> Ack
15:56:49 <markmcclain> salv-orlando: +1
15:56:53 <amotoki_> agree
15:56:53 <mestery> OK next up
15:56:54 <mestery> #link https://review.openstack.org/#/c/97967/
15:56:57 <mestery> Pluggable IPAM
15:57:10 <mestery> Again, salv-orlando and armax are on the ball here
15:57:30 <salv-orlando> I think this one is close.
15:57:40 <markmcclain> oh .. I was going to say the opposite
15:57:43 <salv-orlando> However, it needs a counterpart which I’m writing now.
15:57:55 <salv-orlando> markmcclain: I think you want to rewrite it, I know.
15:58:23 <salv-orlando> Just let us know if you think it’s done in a terrible way, so that we’ll just move it out early of our Kilo goal
15:58:30 <markmcclain> I think this is something we should work on next week
15:58:36 <salv-orlando> also because it potentially clashes a lot with plugin interface refactoring
15:59:16 <mestery> OK, so sounds like this one will require a bit more review then
15:59:26 <salv-orlando> markmcclain, mestery: sounds like we should freeze this
15:59:36 <markmcclain> yeah it's part the conflict and part the lack of specifics
15:59:59 <mestery> markmcclain: Can you comment in the spec on these aspects too?
16:00:07 <markmcclain> yes will do
16:00:10 <mestery> Cool
16:00:12 <salv-orlando> yeah just to inform the other people
16:00:16 <mestery> OK, last one I wanted to highlight
16:00:19 <mestery> #link https://review.openstack.org/#/c/128257
16:00:24 <mestery> Full-stack white-box test framework
16:00:28 <mestery> This is part of the testing effort
16:00:36 <salv-orlando> I had a long chat with marun on these.
16:00:43 <mestery> Nice :)
16:00:43 <salv-orlando> I am ok with this effort going on.
16:01:02 <salv-orlando> I waited honestly a bit for some feedback from the QA team, but since there isn’t any
16:01:08 <mestery> I reviewed a much earlier version, I'll circle back on the latest one
16:01:13 <marun> I'll need to review as well.
16:01:30 <mestery> marun: Excellent
16:01:34 <mestery> #topic Open Discussion
16:01:38 <mestery> Anything else this week?
16:01:43 <mestery> Any other BPs people want to highlight?
16:01:59 <salv-orlando> nothing major… but i wanted to understand what we’re supposed to do with l2 gateway
16:02:17 <armax> salv-orlando: yes, and I also wanted to spend a few words on the vsphere ones
16:02:29 <mestery> L2 gateway, armax will have something to say there :)
16:02:31 <salv-orlando> we have 3 related API specifications under review. I don’t want to pick a winner, also because I don’t feel like I have the technical authority too
16:03:09 <salv-orlando> but I wonder why this topic is so contentious that it’s been 2 years that we’re trying to get to a sort of consensus on the shape of the API
16:03:19 <armax> salv-orlando: to be honest I am now in one of the final stages of the kubler-ross model
16:03:30 <salv-orlando> so at this stage I’d let independent competing effort to go ahead
16:03:33 <armax> acceptance
16:03:35 <armax> :)
16:03:41 <salv-orlando> and let the users pick a winner
16:03:58 <salv-orlando> there will be only one
16:04:03 <salv-orlando> like highlander, you know
16:04:46 <armax> I think the best course of action would be to allow these to bake a little more
16:04:56 <amotoki_> re: L2 gateway  it needs more descripiton on how it covers use cases by the proposed model (though I haven't commented yet)
16:05:16 <armax> ultimately the one effort that I think is the most attainable should be developed out of neutron
16:05:18 <salv-orlando> so my opinion is that if teams want to go ahead and implement out of tree versions of l2 gateway APIs I’m happy with it, but we aren’t able as a community to define a L2 gateway API which can be deemed “official"
16:05:29 <armax> at least until the feature is fully backed
16:05:31 <armax> baked
16:05:54 <salv-orlando> why everyone wants to bake everything today? Is that because christmas is coming?
16:05:56 <marun> go ahead -> go ahead outside of tree?
16:05:58 <armax> salv-orlando: that’s my thinking progress, at least for now
16:06:05 <salv-orlando> marun: yes.
16:06:08 <marun> +1
16:06:19 <mestery> +1
16:06:22 <armax> we could consider l2gw api, another example of a service api
16:06:30 <armax> and revisit progress later on
16:06:36 <mestery> stackforge it is!
16:06:50 <armax> having said that I am making the effort of reviewing the specs to provide guidance
16:06:56 <markmcclain> salv-orlando: what is the recommended baking temp?
16:07:01 <salv-orlando> ok I suggest to -2 the relevant blueprints explaining what we have said here
16:07:04 <armax> but no committment about reviewing code if it targets the neutron repo
16:07:12 <salv-orlando> and wait for the furious reaction from the owners
16:07:18 <armax> salv-orlando: I don’t think a -2 is appropriate
16:07:19 <salv-orlando> with the usual trail of threats and stuff like that
16:07:30 <mestery> Threats before Christmas, nice.
16:07:39 <mestery> Someone is getting coal this year
16:08:39 <mestery> Anything else, or shall we close this meeting early today?
16:08:48 <armax> about vsphere...
16:08:49 <salv-orlando> armax had the vsphere thing
16:08:53 <mestery> ah
16:08:53 <mestery> vsphere
16:08:54 <mestery> yeah
16:08:59 <mestery> please go ahead armax :)
16:09:05 <armax> similar discussion we had on l2gw
16:09:23 <armax> imo this is a clear example of a new effort that should follow the model marun and I have been pushing for
16:09:34 <marun> why isn't -2 appropriate for things that are not going to go forward in the tree?
16:10:09 <armax> my opinion is that if stuff is out of tree but still have a viable integration path into neutron
16:10:15 <armax> why would they need to be blocked?
16:10:28 <salv-orlando> crossing wires...
16:10:51 <armax> the spec then becomes just a matter of visibility
16:11:00 <salv-orlando> for the vsphere effort I just think that in light of spec #136480 the umbrella blueprint is superseded
16:11:22 <salv-orlando> it seemed to me it was an attempt of forcibly building a community. But this is just my opinion
16:11:36 <armax> the umbrella is there to give a context about what’s going on as far as vsphere efforts are concerned
16:11:39 <salv-orlando> it does not necessarily reflect the community or my employers’s view ;)
16:11:43 <armax> but point taken
16:11:52 <marun> I think the spec process if first and foremost to in-tree development effort.
16:11:58 <marun> But that's just me.
16:12:02 <marun> if -> is
16:12:07 <marun> arg.
16:12:12 <armax> marun: that model is evolving imo
16:12:22 <armax> and we have stuff that’s infligh
16:12:23 <armax> t
16:12:25 <marun> I think the spec process is first and foremost to gate in-tree development effort.
16:12:38 <marun> If we don't focus it, we're going to waste cycles on non-essentials.
16:12:59 <marun> There are lots of other avenues for feedback that don't gum up mainline development.
16:13:29 <amotoki_> from user perspective, isn't it also important to coordinate similar efforts like vspher works.... even though it is not in-tree.
16:13:52 <armax> my point being that spec serve a useful documentation purpose
16:13:53 <mestery> ++ to what marun is saying
16:13:59 <mestery> My opinion is if we let things which aren't in-tree have specs, we'll drown fast
16:14:03 <marun> amotoki_: I'm not sure why that has to happen in the spec repo.
16:14:05 <salv-orlando> so neutron-specs should actually be the place not just for neutron specs but for all specs concerning development related to openstack networking. Still, it should not be used to ask the drivers/core team approval for what amount to “experiments” which can live in stackforge without any oversight imho
16:14:16 <marun> amotoki_: And if it does, a -2 makes it clear where the spec stands without preventing people from collaborating.
16:14:45 <salv-orlando> but I agree with marun that anything that goes in neutron specs must be related to things that get then implemented in code
16:14:53 <mestery> So, we're ok taking on extra overhead in neutron-specs for things which won't land in-tree and will live out of tree?
16:14:55 <armax> in lieu of a new pmechanism that allows to raise visibility, I am not sure what’s the best course of action
16:14:56 <mestery> That's what I'm reading this as .
16:15:02 <amotoki_> marun: I agree only if we are talk about spec reviews.
16:15:15 <anteaya> salv-orlando: just as a piece of info stackforge is the wild west on purpose
16:15:28 <salv-orlando> mestery: I think wires are crossed. I don’t understand if we’re talking about the l2 gw specs or the vsphere umbrella blueprint
16:15:29 <marun> amotoki_: so, use spec repo for reviewing potential work that won't land in tree, but -2 to indicate that status?
16:15:33 <anteaya> I agree in spirit but the mechanics aren't there
16:15:43 <armax> perhaps we can tweak the template for now, to add a section that describes the relationship of the work with Neutron
16:16:05 <mestery> salv-orlando: I thought we were talking in general about things which will live out of tree, but are networking related, having specs in neutron-specs?
16:16:05 <markmcclain> I'd really like to keep specs focused on in tree work
16:16:15 <markmcclain> we're trying to tell the operators this is what we're working on
16:16:34 <markmcclain> and if something does not stand a chance of merging we should be explicit about it
16:16:38 <mestery> I worry about bandwidth and expectations if we allow specs to open up for code which isn't in tree too
16:16:39 <armax> markmcclain: ok but what about work that’s happening on the side, that can still make meaningful progress?
16:16:42 <mestery> markmcclain: Right
16:16:46 <amotoki_> I agree we should focus spec reviews on in-tree works.
16:16:53 <mestery> armax: Why do they need a spec for on the side work?
16:16:53 <armax> markmcclain: we’d need to have a away to capture that somehow
16:16:56 <marun> well, if we -2 doesn't it make it clear to everyone what's going on?
16:17:00 <dougwig> if you want it to be specs for neutron, but want the community to have a place in gerrit for "non-neutron" specs, make a new specs repo for that.  neutron-incubator-specs or something
16:17:03 <marun> nothing stopping iteration even with -2
16:17:11 <markmcclain> armax: side work can always continue on the ML, stackforge, etc
16:17:17 <amotoki_> vendor split-out brings users a question on how to coordinate competing efforts.... it is antoher problem.
16:17:34 <marun> amotoki_: not sure what you mean?
16:17:35 <armax> markmcclain: my point being -2 gives the wrong signal to the eyes that look at it
16:17:42 <marun> armax: which eyes?
16:17:58 <markmcclain> it we allow anyone to discuss anything I'm afraid we'll return to the problem we had at past design summits
16:18:00 <marun> armax: and if so, dougwig's suggestion of a separate repo makes sense imho
16:18:18 <amotoki_> there are many proposals on vsphere supports. how do we coordinate these efforts? this is my question.
16:18:18 <anteaya> sounds like education needs to happen, we can't keep changing our process to fit the expections of the lowest thereof
16:18:23 <armax> yes, that could be a viable alternative
16:18:27 <dougwig> -2 does not mean "not in neutron, but keep on!".  to the community, it means, "here, enjoy this 2x4 to the face!"  sorry, but it's overloaded at this point.
16:18:42 <mestery> dougwig: lol
16:18:49 <markmcclain> where folks mis-read the officialness/ready for production of the things and then we paid for it in complaints
16:18:54 <salv-orlando> personally I am not a bull, so seeing a red cross does drive me mad
16:19:01 <marun> dougwig: it's a pretty handy 2x4
16:19:01 <anteaya> markmcclain: going back to what was at past design summits would be a huge step backward
16:19:15 <marun> anteaya: +1
16:19:20 <markmcclain> saying not yet is hard… but honestly we've got to say it more
16:19:30 <marun> +1
16:19:32 <salv-orlando> ok, let’s say no -2… we’ll put those spec back in WIP status (workflow -1)
16:19:33 <mestery> If it's not in-tree or proposed as in-tree in neutron, it doesn't need a spec in neutron-specs.
16:19:47 <marun> salv-orlando: but wip can be removed on a new patch submission :/
16:19:57 <armax> mestery: so I am unclear about the outcome of this discussion
16:19:58 <mestery> If people can't find other ways to discuss things than neutron-specs, we've failed as a community.
16:20:07 <salv-orlando> marun: just trying to find a way out from this discusion…. sorry
16:20:18 <markmcclain> well the specs are for kilo so if it is clearly not going to make it we should -2 with a comment that says "discussion deferred to kilo"
16:20:25 <mestery> markmcclain: Right
16:20:35 <marun> -2 is 'this ain't gonna merge' from a gerrit perspective
16:20:38 <marun> entirely appropriate here
16:20:39 <markmcclain> ^H^H^H^HLemming
16:20:45 <mestery> But my point is, if I'm developing "rabbit out of a hat as a service" in stackforge, don't file a neutron-spec for it
16:20:53 <mestery> It's not in neutron
16:20:58 <armax> would it make sense to go over the specs and select the ones that can be developed outside of neutron and still capture them somewhere else?
16:21:00 <mestery> if you propose it to neutron later, file a spec then
16:21:03 <armax> like dougwig suggested?
16:21:22 <mestery> armax: My concern is that we don't have authority for "outside of neutron"
16:21:24 <mestery> we can say "do it outside neutron"
16:21:32 <mestery> But once that happens, they can do it however they want outside neutron
16:21:35 <marun> stackforge/neutron-specs
16:21:44 <salv-orlando> armax: ok, but why? Just to have a place where people can know things are happening?
16:21:56 <marun> --> specs ghetto ;)
16:21:58 <mestery> marun: But don't we then validate things and move the old problem to stackforge/neutron-specs?
16:22:06 <armax> salv-orlando: primarely yes
16:22:20 <marun> mestery: I'm for simply -2'ing.
16:22:24 <mestery> marun: Me too
16:22:27 <mestery> It's simple and clear
16:22:32 <marun> mestery: that can mean 'not yet' or 'not ever', depending.
16:22:33 <markmcclain> isn't that the ML?
16:22:41 <armax> mestery: ok, I was unable to convince why it isn’t, but ok
16:22:47 <markmcclain> basically post and say I'm working on FooaaS ping me and we'll collaborate
16:22:55 <mestery> yes
16:22:57 <anteaya> if folks don't understand -2 then they need to learn, not change giving a -2 when it is needed
16:23:06 <mestery> anteaya: ++
16:23:09 <marun> mestery: but the takeaway is 'we don't have to treat this as something to review on a priority basis.  only if you care about the topic.
16:23:28 <marun> anteaya: ++
16:23:28 <mestery> Right, that sounds like a -2 to me
16:23:39 <armax> ML does not sound like the best way to document things
16:23:52 <marun> armax: we don't need process for things that we aren't managing
16:24:00 <marun> armax: process for process sake -> nobody's friend
16:24:05 <salv-orlando> armax: ok, but we don’t need to put those through a review process then, do we?
16:24:08 <armax> marun: I am not advocating for process
16:24:18 <salv-orlando> marun: I think it’s also called bureaucracy
16:24:33 <marun> armax: if someone wants to pursue an out-of-tree effort, because neutron isn't appropriate for it right now, they should do so unencumbered by us in any way.
16:24:56 <marun> armax: our job is done when a consensus is reached that a -2 is appropriate
16:24:58 <mestery> marun: ++
16:24:59 <anteaya> marun: that is my defintion of out-of-tree
16:25:09 <armax> marun: ij
16:25:11 <armax> marun: ok
16:25:32 <anteaya> that doesn't prevent those people from attending meetings and leraning and listening
16:25:42 <mestery> Right
16:25:46 <anteaya> and guiding their efforts so they will be accepted
16:25:52 <armax> armax: at this point I’d be just tempted to say ‘abandon the spec’
16:25:58 <anteaya> it jus tmeans they can't take review resources
16:26:06 <marun> armax: I think that's reasonable.
16:26:34 <armax> and do it somewhere else if you wanted to…but do we want to provide that ‘somewhere’ else, to help the discoverability of the effort?
16:26:34 <mestery> ++
16:26:37 <armax> ML is not appropriate
16:26:37 * mestery notes 4 minutes left
16:26:46 <armax> people complain about ML
16:26:52 * mestery wants to manage less, not more
16:26:53 <armax> not me, but people do
16:26:53 <armax> :)
16:26:54 <mestery> stackforge
16:27:01 <marun> armax: our new meeting format should be a good place
16:27:08 <salv-orlando> people complain about stackforge. not me, but people do.
16:27:12 <salv-orlando> just kidding
16:27:13 <marun> armax: 'hey, i'm working on this, if you're interested talk to me!'
16:27:16 <anteaya> armax: what would happen if you take the material in the spec and use that for documentation in the repo?
16:27:23 * mestery slaps salv-orlando
16:27:23 <mestery> ;)
16:27:38 <armax> anteaya: not sure I fully understand what you mean
16:27:59 <anteaya> if you have a bunch of information currently in a spec that is homeless
16:28:13 <anteaya> would the repo itself be a potential home
16:28:14 <mestery> Folks, we have < 2 minutes left.
16:28:38 <mestery> Lets look at continuing this discussion at some point if we need to
16:28:44 <mestery> Maybe on the ML
16:28:47 <marun> anteaya: even abandoned changes live forever in gerrit
16:28:50 <salv-orlando> one more quick thing from me… can I?
16:28:52 <anteaya> they do
16:28:52 * mestery runs for cover :)
16:28:55 <mestery> salv-orlando: yes
16:28:58 <salv-orlando> spec for consolidarting neutron core: https://review.openstack.org/#/c/136760/ - I sense there is an intention of reading as a renaming of extension into feature, and leaving the core - intenteded as the API every deployment must provide - as simple as it is today.
16:28:59 <mestery> you have 40 seconds
16:29:06 <salv-orlando> if that is the intention, I will just abandon the spec
16:29:26 <mestery> salv-orlando: Will look, please, others look as well.
16:29:30 <amotoki_> as a consensus, now -2 on neutron-specs means two things: that  it is deferred out of Kilo (for things appropriate for neutron in-tree) andthat it does not fit in-tree neutron. we are looking for a place to discuss out-of-tree neutron-related tipics..
16:29:32 <amotoki_> right?
16:29:33 <salv-orlando> because the point for me is that we shoul stop thinking that the backend defines the ip
16:29:35 <mestery> OK, we're out of time now folks.
16:29:40 <salv-orlando> that’s all fromme
16:29:43 <mestery> Thanks for the lively discussion, see you all again soon!
16:29:45 <mestery> #endmeeting