21:02:03 <mestery> #startmeeting networking
21:02:04 <openstack> Meeting started Mon Aug  4 21:02:03 2014 UTC and is due to finish in 60 minutes.  The chair is mestery. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:02:05 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:02:08 <openstack> The meeting name has been set to 'networking'
21:02:20 <Sukhdev> Hello
21:02:23 <mestery> #link https://wiki.openstack.org/wiki/Network/Meetings Agenda
21:02:24 <dougwig> o/
21:02:34 <mestery> #topic Announcements
21:02:55 <mestery> I would be indecent if I didn't start off the meeting by mentioning our large Juno-3  BP list: https://launchpad.net/neutron/+milestone/juno-3
21:02:57 <mestery> #link https://launchpad.net/neutron/+milestone/juno-3
21:03:04 <mestery> We've merged ... 4 BPs so far.
21:03:35 <mestery> We're making progress, but it's slow, though I do see some activity picking up this week on a few things.
21:03:42 <mestery> Thanks to all the revewiers and contributors here!
21:04:09 <mestery> #link https://wiki.openstack.org/wiki/Juno_Release_Schedule
21:04:15 <mestery> FPF is August 21
21:04:24 <mestery> Feature Freeze is September 4
21:04:31 <mestery> Those dates are fast approaching.
21:04:36 <mestery> Which means Juno is nearing it's end.
21:04:45 <mestery> #info FPF is August 21
21:04:51 <mestery> #info Feature Freeze is September 4
21:04:56 <mestery> Any other announcements from anyone?
21:05:57 <mestery> OK, our bug czar can't join us today, so we'll skip the bugs section today.
21:06:07 <mestery> And I'll go into one last announcement:
21:06:16 <mestery> #info The LB and OVS plugins are due to be removed from the tree this week.
21:06:33 <mestery> #topic Docs
21:06:35 <mestery> emagana: Hi there!
21:06:43 <emagana> mestery: hello!
21:06:45 <mestery> emagana: You had a nice etherpad last week with doc work, do you have that handy again?
21:06:55 <emagana> mestery: absolutely
21:06:59 <mestery> emagana: thanks!
21:07:09 <emagana> #link https://etherpad.openstack.org/p/neutron-docs-juno
21:07:40 <emagana> I was expecting a lot of volunteers but.. sadly none
21:08:04 <mestery> emagana: That's disappointing indeed. :(
21:08:19 <emagana> mestery: We will make some progress in our end and as we get closer to Juno release, we will cal people directly
21:08:41 <emagana> Hopefully, folks will have more availability after Juno-3
21:08:44 <mestery> emagana: I think we may have to go that route, yes.
21:08:49 <mestery> emagana: ++
21:09:04 <emagana> mestery: nothing more to report captain
21:09:20 <mestery> emagana: Thanks! Hopefully next week we get a few new people to signup for docs items on that etherpad.
21:09:30 <mestery> #topic Tempest
21:09:32 <mestery> mlavalle: Hi there!
21:09:41 <mlavalle> mestery: hi
21:09:59 <mlavalle> mestery: so I have been working with the new LBaaS team, testing the api
21:10:24 <mlavalle> mestery: at this point we have confirmed that most of the api works fine
21:10:35 * markmcclain joins late
21:10:52 <mlavalle> there is an issue with deleting listerners that might be a problem with testing script
21:10:55 <mestery> markmcclain: We'll get to the parity items next :)
21:11:10 <mlavalle> I will investigate further tonight and report results
21:11:19 <mestery> mlavalle: I saw your email to the list, are you working with dougwig and/or blogan on that?
21:12:05 <dougwig> yes, he's been on the lbaas channel.
21:12:06 <mlavalle> mestery: yeah, I am in contact with both of them in irc. Plus, I have the dubious privilege of seeing blogan every day at the office :-)
21:12:16 <mestery> mlavalle: Heh :)
21:12:41 <mestery> #info LBaaS API tests are working except for deleting listeners.
21:12:59 <mlavalle> mestery: there is also a couple of api tests being develepode by zzelle that I am tracking
21:13:11 <mlavalle> those are for provider networks
21:13:33 <mlavalle> next step with new LBaaS is to write a scenario test
21:13:37 <mestery> #info mlavalle tracking some API tests for provider networks being developed by zzelle
21:13:55 <mlavalle> that's all I have this week
21:13:56 <mestery> mlavalle: For the scenario test, is the plan to use the agentless ha-proxy driver?
21:14:09 <mlavalle> mestery: yes, that's my target
21:14:19 <mestery> mlavalle: OK, thanks!
21:14:32 <mestery> #topic Parity
21:14:35 <mestery> markmcclain: hi there!
21:14:42 <markmcclain> hi
21:14:45 <mlavalle> for the api test I've been using the ha-proxy agentless driver as weel
21:15:09 <markmcclain> so we're still making lots of progress on parity work
21:15:34 <markmcclain> I'm about read to mark dvr as done for parity
21:15:48 <mestery> Yes, I think it's reached that point as well!
21:16:11 <markmcclain> currently working with the nova team to redefine the migration plan for users
21:16:29 <mestery> #info DVR work will be marked as complete with regards to parity coverage
21:16:40 <mestery> markmcclain: So, the plan around migration is to not require it I believe, right?
21:17:26 <markmcclain> based on discussion with the Nova team we're heading that way
21:17:42 <obondarev> neutron migration design spec was updated and now includes both live and cold migration approaches
21:17:50 <mestery> obondarev: Awesome!
21:18:03 <mestery> #info nova/neutron teams leaning towards not requiring migration from a parity gap perspective
21:18:15 <banix> not requiring it, meaning not requiring having a migration path?
21:18:17 <mestery> #info Migration doc updated to include both live and cold approaches
21:18:22 <mestery> banix: Correct.
21:18:35 <markmcclain> so both cold and live have operational issues
21:18:44 <banix> that simplifies things a bit :)
21:18:54 <mestery> banix: Indeed :)
21:19:02 * salv-orlando not the first time hears this story about migration path not required for parity...
21:19:22 <marun> there was broad consensus among the nova team present at the mid-cycle that migration should be a post-parity concern
21:19:27 <markmcclain> which is why we're converging on agreeing it might be a bad idea to push one size fits all
21:20:04 <mestery> markmcclain: I think that's the main problem with the migration idea, so I'm happy to hear this was the consensus last week.
21:20:19 <obondarev> are there any meetings minutes regarding migration form nova mid-cyxle anywhere?
21:20:26 <obondarev> from*
21:20:33 <markmcclain> obondarev: just in the etherpad
21:20:42 <obondarev> ok, saw them
21:21:05 <regXboi> link for those who come later?
21:21:10 <regXboi> (i.e. for the minutes?)
21:21:11 <markmcclain> #link https://etherpad.openstack.org/p/juno-nova-mid-cycle-meetup
21:21:23 <regXboi> thanks
21:21:39 <HenryG> Did the "nova network as an ML2 mechanism driver" idea get any traction?
21:21:56 <markmcclain> HenryG: not really because there are technical downsides to that approach
21:21:57 <marun> no
21:21:58 <emagana> HenryG: I hope not!
21:22:14 <mestery> It was mostly DOA I believe :)
21:22:27 <HenryG> OK, just wanted to make sure, thanks.
21:22:55 <markmcclain> mestery: that's all I've got on parity
21:23:00 <mestery> markmcclain: Thanks!
21:23:25 <mestery> Just one more note, markmcclain and I will be presneting the status again this week in the TC and/or release meetings tomorrow.
21:23:33 <mestery> #topic L3
21:23:34 <mestery> carl_baldwin: Hi there!
21:23:39 <carl_baldwin> mestery: hi
21:23:50 <carl_baldwin> We’ve made lots of progress on DVr.
21:23:53 <carl_baldwin> *DVR
21:24:11 <carl_baldwin> There is a backlog but many of the issues have already been addressed.
21:24:26 <carl_baldwin> #link https://bugs.launchpad.net/neutron/+bugs?field.tag=l3-dvr-backlog
21:24:34 <carl_baldwin> … or are in progress.
21:25:08 <carl_baldwin> l3-high-availability is in review.
21:25:16 <carl_baldwin> #link https://review.openstack.org/#/q/topic:bp/l3-high-availability,n,z
21:25:52 <carl_baldwin> Oh, on DVR.  There is an experimental job that runs tempest with DVR fully enabled.
21:26:04 <mestery> carl_baldwin: That's really good news!
21:26:08 <carl_baldwin> There are a few tests still not passing but not bad.
21:26:27 <armax> most notably the ones around firewall
21:26:31 <mestery> #info Experimental Tempest job which utilizes DVR is running as experimental
21:26:32 <carl_baldwin> We’ll be looking to convert that job to a non-voting job.
21:26:47 <armax> mestery: to kick it off just post ‘check experimental’ on a review of interest
21:26:48 <mestery> armax SridarK: Any updates on the work to make FWaaS and DVR work together?
21:27:08 <mestery> #info To kickoff the experimental job, just run "check experimental" on a review of interest.
21:27:10 <mestery> armax: thanks!
21:27:13 <SridarK> mestery: working thru this - will get a patch out in a few days
21:27:24 <mestery> SridarK: Cool!
21:27:31 <SumitNaiksatam> mestery: SridarK and vishnu are working on a DVR setup
21:27:39 <mestery> SumitNaiksatam: Thanks!
21:27:46 <armax> SridarK: super!
21:27:57 <SumitNaiksatam> mestery: we are in touch with Swami and the DVR team for this
21:27:58 <armax> SumitNaiksatam: thanks
21:28:20 <mestery> #info FWaaS team is working with DVR to close the DVR/FWaaS integration in Juno.
21:28:23 <mestery> SumitNaiksatam: Thanks for the udpate!
21:28:36 <carl_baldwin> I’m also reaching out about rootwrap daemon mode.  I think we’d like to know this week if it has a chance.
21:28:37 <SumitNaiksatam> mestery: sure, and thanks to SridarK and Vishnu
21:29:01 <carl_baldwin> mestery: That is all from me.  The rest of the status is on the wiki.
21:29:08 <mestery> carl_baldwin: It seems unlikely, given the concerns raised by ttx.
21:29:18 <mestery> carl_baldwin: But we need to close on that by this week if it has a chance at all.
21:29:29 <markmcclain> mestery: I'm also digging into it further
21:29:43 <carl_baldwin> mestery: markmcclain:  thanks.
21:30:00 <mestery> carl_baldwin: Thanks for the updates!
21:30:03 <mestery> #topic Advanced Services
21:30:06 <mestery> SumitNaiksatam: Hi there!
21:30:10 <SumitNaiksatam> mestery: hi
21:30:20 <SumitNaiksatam> so the flavors spec is still in bit of a limbo
21:30:39 <SumitNaiksatam> but enikanorov_ has posted an implementation patch: #link https://review.openstack.org/#/c/105982
21:30:50 <mestery> SumitNaiksatam: Flavors is the only other spec with a chance at an exception at this point, but it appears to e stuck as yousay.
21:30:52 <SumitNaiksatam> i believe based on teh agreed upon aspects of the spec
21:30:56 <markmcclain> enikanorov_: thanks forworking on the implementation
21:30:59 <SumitNaiksatam> mestery: yeah
21:31:25 <SumitNaiksatam> other than that hemanthravi and songole are making progress on the service chain implementation, and should be posting a patch soon
21:31:46 <mestery> #info Flavor Framework spec still at risk of not making Juno.
21:32:02 <SumitNaiksatam> mestery: thats its from me for this
21:32:21 <mestery> SumitNaiksatam: thanks!
21:32:30 <mestery> #topic IPv6
21:32:32 <mestery> sc68cal: Hi there!
21:33:01 * mestery notes that the final set of IPV6 BPs are close to merging now.
21:33:55 <mestery> I think, based on reading BPs, that IPV6 support will be complete in Juno if those merge.
21:34:02 <mestery> In lieu of sc68cal not being here, lets move on though.
21:34:08 <mestery> #topic ML2
21:34:14 <mestery> rkukura Sukhdev: Hi!
21:34:16 <rkukura> hi
21:34:22 <Sukhdev> mestery: hi
21:34:25 <rkukura> not a lot new with ML2
21:34:34 <rkukura> a number of new drivers are in review
21:34:53 <rkukura> and we are working to get the remaining BP implementations into review
21:34:53 <mestery> rkukura: Was curious on how the extension support was coming along, is that seeing some progress?
21:35:20 <rkukura> nlahouti: do you have an update on that?
21:35:21 <nlahouti> mestery: the code is under review
21:35:46 <mestery> nlahouti: OK, was curious about that one as I was looking at Juno-3 BPs today.
21:35:49 <nlahouti> mestery rkukura: https://review.openstack.org/#/c/89211/
21:36:12 <mestery> #info Remaining ML2 BPs hope to enter implementation stage soon
21:36:28 <rkukura> Sukhdev: Did we miss anything?
21:36:39 <markmcclain> I'm concerned about adding additional attributes to responses… they basically make our API responses random
21:36:39 <mestery> #link https://review.openstack.org/#/c/89211/
21:36:42 <nlahouti> I was going to ask markmcclain to remove -2 from the review
21:36:46 <nlahouti> as the BP is approved
21:37:05 <Sukhdev> rkukura: you covered good - one thing I'll add is that we hope to close of on hierarchical port binding soon
21:37:18 <Sukhdev> s/of/off
21:37:29 <rkukura> nlahouti: I recall that -2 was on a previous patch and the current code is an entirely different approach
21:38:05 <rkukura> Sukhdev: Yes, hope to have an initial hierarchical port binding patch later this week.
21:38:14 <nlahouti> rkukura: that's correct.
21:38:33 <mestery> nlahouti: So, there is no -2 on the new approach that you and rkukura worked on>
21:38:34 <mestery> ?
21:38:45 <markmcclain> my -2 is still there
21:38:45 <nlahouti> mestery: No
21:38:50 <armax> I did review the patch this morning
21:38:54 <nlahouti> markmcclain: yes
21:38:55 <mestery> markmcclain nlahouti: OK, got it.
21:38:58 <armax> I have some concerns on the approach
21:38:59 <nlahouti> https://review.openstack.org/#/c/89211/
21:39:02 <armax> but more info on the patch
21:39:23 <nlahouti> armax: I got your comment and we will address those
21:39:33 <armax> I welcome salv-orlando to give his opinion too, as he’s been instrumental in driving the API extension framework and its integration wit hte policy framework
21:39:41 <armax> nlahouti: thanks
21:40:10 <armax> *the
21:40:42 <mestery> OK, thanks for the ML2 updates rkukura and Sukhdev!
21:40:53 <mestery> #topic Group Based Policy
21:40:55 <mestery> SumitNaiksatam: hi!
21:40:59 <SumitNaiksatam> mestery: hi again
21:41:11 <SumitNaiksatam> so, the patches have been in review for a while - https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy/Patches - nothing new there
21:41:24 <SumitNaiksatam> the -2 on the first also persists, so nothing new there either
21:41:36 <SumitNaiksatam> hence the team sent out an email to the mailer today
21:41:39 <markmcclain> SumitNaiksatam: I posted this http://lists.openstack.org/pipermail/openstack-dev/2014-August/041863.html
21:41:48 <SumitNaiksatam> #link http://lists.openstack.org/pipermail/openstack-dev/2014-August/041864.html
21:41:53 <mestery> #link https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy/Patches
21:41:57 <nati_ueno> So we have whole set of patch now?
21:42:06 <SumitNaiksatam> markmcclain: yes, i saw that just before the meeting
21:42:13 <SumitNaiksatam> nati_ueno: yes the whole series is present
21:42:37 <ivar-lazzaro> markmcclain: imho, that proposal looks like a workflow change in the neutron process (something like CI for vendor plugins)
21:42:56 <SumitNaiksatam> markmcclain: this topic has been discussed in the open for well over a year now
21:43:02 <markmcclain> ivar-lazzaro: it is a change
21:43:05 <marun> ivar-lazzaro: I'm not sure how you came to that conclusion.
21:43:11 <ivar-lazzaro> markmcclain: why addressing it this way? I think it should be discussed properly like what happened at that time
21:43:23 <SumitNaiksatam> markmcclain: so there its mature enough
21:43:41 <marun> SumitNaiksatam: Has any of the discussion addressed how the policy initiative is going to evolve?
21:43:54 <ivar-lazzaro> marun: well, it's kind of asking for all the extensions to be put in stackforge, did I get it wrong?
21:43:56 <marun> SumitNaiksatam: It's pretty clear to all involved that the effort is experimental.
21:43:57 <SumitNaiksatam> marun: huh?
21:44:05 <markmcclain> SumitNaiksatam: I've heard from policy contributors that they want the API to experiment and get user feedback
21:44:10 <regXboi> marun: huh^2?
21:44:11 <ivar-lazzaro> marun: how is GBP different from LBaaS or FWaaS?
21:44:11 <SumitNaiksatam> markmcclain: there also dont seem to be any outstanding concerns
21:44:12 <rkukura> markmcclain: I hope that I haven’t confused matters in using the word “experimental”. My understanding is that the initial version of any new service API is labelled “experimental”, indicating it is subject to incompatible tweeks and isn’t considered stable.
21:44:32 <marun> SumitNaiksatam: And as per Mark's email we don't have a good track record of evolving complex features in-tree.
21:44:40 <markmcclain> ivar-lazzaro: the difference is we learned from those experiences
21:44:59 <rkukura> markmcclain: But your email seems to have a completely different interpretation of “experimental”.
21:45:00 <ivar-lazzaro> markmcclain: right, that's why your proposal… just like CI for vendors
21:45:08 <markmcclain> rkukura: right incompatible tweaks is where we get into problems
21:45:21 <ivar-lazzaro> markmcclain: as such, it should be targeted properly, and discussed like it has been done that time
21:45:21 <markmcclain> once the code lands in master our ability to refine is limited
21:45:31 <armax> ivar-lazzaro: we can’t really compare GBP with LBaaS or FWaaS, as they sit at a different levels of abstractions
21:45:35 <markmcclain> also if we have a defect we have to a full cycle to fix it
21:45:56 <ivar-lazzaro> markmcclain: this way, it just looks like a new requirement kind of "out of the blue", doesn't it?
21:45:56 <marun> rkukura: I'm not sure how you could define 'experimental' other than 'we don't know what a good solution looks like, so we're going to iterate until we find it'.
21:45:58 <markmcclain> the deployers do expect some stability even when experimental features in the tree
21:46:30 <ivar-lazzaro> armax: I cited FWaaS and LBaaS like Mark did in his email
21:46:43 <SumitNaiksatam> markmcclain: and i believe we are at that stage
21:46:44 <marun> ivar-lazzaro: And you think those are examples of how to do things right?
21:47:02 <emagana> Why is so urgent and important the GBP? Seriously, looks like we are missing the most important staff which is Neutron stability, parity and HA
21:47:15 <ivar-lazzaro> marun: what? discussing a workflow change with the due time, the whole community, and without targeting already approved patches?
21:47:24 <armax> ivar-lazzaro: imo process != API
21:47:40 <SumitNaiksatam_> emagana: you should check with the PTL, this feature has been prioritized as high
21:48:00 <emagana> mestery: Can you explain why this is so important??
21:48:01 <ivar-lazzaro> armax: Sorry armax, I probably said something confusing, I've never talked about API did I?
21:48:04 <SumitNaiksatam_> emagana: and there is demand from both operators and vendors to support it
21:48:17 <marun> SumitNaiksatam: 'demand' is a pretty nebulous statement
21:48:28 <marun> SumitNaiksatam: since they don't actually know what a good solution looks like either
21:48:39 <marun> SumitNaiksatam: hence the need to iterate
21:48:39 <emagana> SumitNaiksatam_: vendors I do understand it but Operators??? I don't believe it!
21:48:50 <armax> ivar-lazzaro: ok, no worries, don’t mind me
21:48:52 <SumitNaiksatam_> marun: but they have all had a chance to review this for a long long time
21:49:11 <markmcclain> SumitNaiksatam_: I recognize that we have invested time in this
21:49:13 <SumitNaiksatam_> emagana: you can check the mailing list, i dont have the link handy here
21:49:18 <marun> SumitNaiksatam_: We both know that reviewing code and using it in a production scenario are very different things.
21:49:25 <regXboi> so I can speak from both the vendor and operator side on this one
21:49:37 <markmcclain> but APIs take time to gel which is why I think StackForge is a good platform to let it solidify with users
21:49:39 <regXboi> and yes, I can say as an operator that without GP neutron gets a bit less interesting
21:49:39 <SumitNaiksatam_> markmcclain: its not just because we have invested time
21:49:41 <emagana> SumitNaiksatam_: I am attending the Operators meet-up: https://etherpad.openstack.org/p/SAT-ops-meetup
21:50:01 <SumitNaiksatam_> emagana: See regXboi's input above ^^^
21:50:22 <emagana> SumitNaiksatam_: If you see the official agenda, there is nothing on GBP.. Actually, "congress" will be discussed
21:50:23 <marun> regXboi: There's exactly nothing preventing an operator from simplifying things for users.
21:50:25 * salv-orlando confused. Are we talking about proces, APIs, or users? Or everything at the same time?
21:50:37 <SumitNaiksatam_> marun: that goes for every feature or change we make in neutron
21:50:37 <emagana> SumitNaiksatam_: Very superficial.. anyway///
21:50:37 <ivar-lazzaro> salv-orlando: +1
21:50:38 <marun> regXboi: And also nothing to prevent gbp being useful out-of-tree
21:50:39 <nati_ueno> Hmm I'm not sure why this discussion happening now...
21:50:44 <SumitNaiksatam_> marun: but we dont iterate in stackforge on everythin else
21:50:56 <emagana> Anyway.. I will shut up!
21:50:58 <markmcclain> SumitNaiksatam_:  actually we do
21:51:12 <markmcclain> stackforge/kite is from Keystone
21:51:24 <regXboi> marun: I would argue that as an operator, if something isn't in-tree it doesn't exist
21:51:25 <markmcclain> and several incubated repos have started life in stackforge
21:51:32 <marun> Why is it that every indication of support is seen as vindication of your efforts, but you ignore every detractor?
21:51:33 <marun> Honestly?
21:51:36 <markmcclain> it is why I thought the platform would be a match for us
21:51:37 <rkukura> markmcclain: I’m kind of troubled by your suggestion to develop GP out-of-tree, given the negative reaction we had for even developing a small PoC implementation out-of-tree. We responded to this very valid feedback with several series of much smaller patches, incrementally building on each other. Do you really think if we went off and continued developing GP out-of-tree, there is any realistic chance of it being
21:51:38 <rkukura> merged in one huge piece in the future?
21:51:51 <ivar-lazzaro> markmcclain: So now all Neutron extensions should go through StackForge?
21:51:53 <kevinbenton> marun: isn’t the reason of keeping it out of neutron is so that operators don’t use it?
21:52:12 <marun> regXboi: You want all the work done for you, fair enough.
21:52:32 <marun> regXboi: The point is that iterating on untested features in the tree is painful for both developers and the people that have to review them.
21:52:45 <marun> regXboi: Many of us think that the situation could be improved
21:52:45 <regXboi> marun: I grant that point
21:52:48 <mestery> We have 8 minutes left, how do we as a community move forward together here?
21:53:00 <marun> So that important features could be developed faster and to a higher standard of quality
21:53:02 <emagana> resending my question:  mestery: Can you explain why this is so important??
21:53:14 <SumitNaiksatam_> markmcclain: it might be good for totally new features to go to stackforge, that is a separate discussion (on process)
21:53:21 <markmcclain> I think the way forward is stackforge
21:53:25 <emagana> mestery: We need to discuss about CI as well!
21:53:30 <regXboi> marun: but that does not translate to comments about operators not being interested in GP
21:53:32 <SumitNaiksatam_> markmcclain: but in this case this has been discussed and deliberated for almost an year now
21:53:45 <markmcclain> we get the consistency in process and the team get its velocity back
21:54:14 <marun> regXboi: The goal isn't to banish potentially important features and render them unusable by operators
21:54:15 <ivar-lazzaro> mestery: Honestly, I think that what Mark proposed should be discussed generically for all the Neutron extensions (to be fair)
21:54:31 <SumitNaiksatam_> mestery: what is the process for making such decisions
21:54:33 <marun> regXboi: The point is to evolve features and then give first-class support to the ones that prove themselves useful
21:54:35 <SumitNaiksatam_> mestery: ?
21:54:52 <mestery> Look, we as a community need to move forward here, if we can't do that, then we've lost everything IMHO.
21:54:59 <mestery> I am not going to make a single decision here.
21:55:02 <mestery> I don't expect others to either.
21:55:05 <mestery> This is a COMMUNITY.
21:55:08 <mestery> Got it?
21:55:13 <rkukura> marun: That is why we have structured neutron in terms of a small core plus a set of optional services that can be configured (or not).
21:55:13 <mestery> We need to work together and move forward.
21:55:17 <SumitNaiksatam_> mestery: absolutely
21:55:23 <marun> regXboi: We don't have the resources to treat everyone's new thing as worth supporting in the tree.   We need to make sure we are prioritizing our efforts.
21:55:36 <markmcclain> ivar-lazzaro: there's some merit to that idea for new services.. older services will have a complicated history to sort out
21:55:40 <SumitNaiksatam_> marun: this is not everyone's new thing either
21:55:44 <regXboi> marun: there is a dangerous assumption in that statement and that is that OpenStack becomes irrelevant if it can't keep up
21:55:57 <marun> regXboi: I think you're wrong
21:56:07 <regXboi> marun: we can agree to disagree on that point
21:56:22 <marun> regXboi: If that makes you feel better, sure.
21:56:28 <markmcclain> rkukura: right we do have optional features but operators depend on us to produce production ready
21:56:30 * mestery notes this all ends in 4 minutes.
21:56:37 <ivar-lazzaro> markmcclain: that's why this need to be discussed properly. And not being a blocker for patches already "ready"
21:57:03 <SumitNaiksatam_> ivar-lazzaro: i agree, this is completely adhoc
21:57:04 <ivar-lazzaro> markmcclail: otherwise it just becomes a last minute requirement IMHO
21:57:06 <marun> ivar-lazzaro: I think your determination of what 'ready' means differs from mine.
21:57:12 <markmcclain> what we learned by the way we introduced other features is that the path was not optimal
21:57:12 <emagana> mestery: Reminder for the discussion about CI
21:57:15 <marun> ivar-lazzaro: that's kind of the crux of the problem.
21:57:24 <markmcclain> ivar-lazzaro: this is not a last minute requirement
21:57:32 <markmcclain> this is about figuring the right forward
21:57:39 <mestery> emagana: We may ahve to move that to the ML given the time left.
21:57:43 * armax thinks that this is not to be solved in 3 minutes
21:57:45 <markmcclain> experimenting in the master branch does work very well
21:57:47 <ivar-lazzaro> marun: ready means approved by the community (BP) and by the reviewers on technical side (review board)
21:57:58 <ivar-lazzaro> marun: (IMHO of course)
21:58:08 <kevinbenton> what is the point of the specs process when we have to rehash this stuff again after an approval?
21:58:13 <rkukura> markmcclain: We are working hard to make the Juno version of group policy production ready.
21:58:13 <regXboi> markmcclain: is that statement missing a "not"?
21:58:14 <marun> ivar-lazzaro: the process is never strictly mechanical.
21:58:27 <marun> ivar-lazzaro: that is simply how we channel our efforts, and maybe that's all you're seeing.
21:58:36 * regXboi thinks armax is spot on
21:58:39 <SridarK> kevinbenton: +1
21:58:49 <armax> kevinbenton: agile development requires a feeback loop
21:58:52 <mestery> Look, lets keep this discussion going on the ML given the time left.
21:58:54 <marun> armax: +1
21:58:54 <markmcclain> rkukura: it is agreed that the API needs users to validate it and that it could change.. production ready mean will support it for a minimum of N+2 cycles
21:58:55 <mestery> The threads are out there.
21:58:55 <ivar-lazzaro> markmcclain: everything is blocking something which is ready to merge with a request which was never made for similar patches is a last minute requirement for me…
21:58:56 <armax> kevinbenton:  we dont use a waterfall model
21:59:01 <mestery> I encourage everyone to jump in there.
21:59:02 <banix> kevinbenton: agree; we need to have these discussions early on
21:59:04 <kevinbenton> armax: then the specs process should go away
21:59:04 <armax> nothing gets carved in stone
21:59:19 <kevinbenton> armax: because it’s like a guessing ritual
21:59:20 <marun> kevinbenton: no
21:59:24 <armax> we revise our decisions, refine, iterate and make things better over time
21:59:35 <ivar-lazzaro> kevinbenton: +1
21:59:38 <marun> kevinbenton: it should be enhanced so we iterate on the specs in concert with the code
21:59:39 <markmcclain> ivar-lazzaro: if you notice I'm arguing code merits, just where we should experimenting and baking new features
21:59:42 <armax> just because a bp is approved doesn’t mean it’s the bible
21:59:49 <rkukura> we need review input to iterate - that will not happen outside the tree
21:59:51 <markmcclain> *I'm not arguing code merits*
21:59:54 <SumitNaiksatam_> mestery: i think there needs to be a clearly defined process on how such decisions are made
22:00:03 <marun> rkukura: input from who?
22:00:04 <SumitNaiksatam_> mestery: and they should not be applied retroactively
22:00:04 <armax> I am talking in the general sense here, not GBP specifically
22:00:15 <mestery> SumitNaiksatam_: I agree, and again, as a community, we need to decide how that process is defined.
22:00:23 <marun> rkukura: who are you needing input from that you won't be getting in stackforge?  it's not like you can't ask interested cores to do the same thing they do in-tree.
22:00:24 <salv-orlando> I don’t think I hve the technical stature to speak about this specific matter, nor I have visibility into user demands. The only thing I would like to point out, is that orthogonal extensions pose a large workload in terms of reviews on the core team. This is tremendously frustating for contributors as well (with some enraged reactions you might have become aware of).
22:00:24 <mestery> I'll leave folks with this:
22:00:26 <emagana> armax: +1
22:00:29 <mestery> Neutron is not a dictatorship.
22:00:40 <mestery> And with that, lets see everyone next week and on what is sure to be an exciting ML thread.
22:00:42 <mestery> #endmeeting