21:00:42 <mestery> #startmeeting networking
21:00:43 <openstack> Meeting started Mon Aug 11 21:00:42 2014 UTC and is due to finish in 60 minutes.  The chair is mestery. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:00:44 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:00:46 <openstack> The meeting name has been set to 'networking'
21:00:52 <mestery> #link https://wiki.openstack.org/wiki/Network/Meetings Agenda
21:00:57 <mestery> I expect this to be a boring meeting ...
21:01:02 <dougwig> lol
21:01:04 <mestery> #topic Announcements
21:01:07 <emagana> hola!
21:01:17 * salv-orlando bored already
21:01:21 <mestery> I'm sure people have forgotten, but Juno-3 is approaching fast
21:01:22 <mestery> #link https://launchpad.net/neutron/+milestone/juno-3
21:01:32 <mestery> Please spend some time reviewing things for Juno-3.
21:01:43 <mestery> I expect a nice gate crush the closer we get to both FPF and FF.
21:02:04 <mestery> Also, just a note that Neutron policies are documented on the wiki
21:02:05 <mestery> #link https://wiki.openstack.org/wiki/NeutronPolicies
21:02:17 <mestery> And one final announcment from the Ryu team:
21:02:23 <mestery> #info the Ryu plugin is being deprecated in Juno
21:02:33 <mestery> #info Juno is the last release to support Ryu plugin
21:02:45 <mestery> #info The Ryu team will be focusing on the ofagent going forward
21:02:48 <mestery> Any other announcements?
21:02:57 <reed> what's the impact on users of the Ryu plugin?
21:03:12 <mestery> reed: There is no upgrade provided by the ryu team per their notes
21:03:22 <reed> cool, thanks
21:03:23 <mestery> reed: It seems it will be a manual move to ML2+ofagent
21:03:48 <yamamoto> i plan to write some text to document how to transit to eg. ofagent
21:03:55 <mestery> yamamoto: Thanks!
21:04:10 <emagana> yamamoto: we will need to update some guides
21:04:28 <emagana> yamamoto: I will touch based with you offline
21:04:49 <yamamoto> emagana: thank you
21:04:54 <mestery> #action emagana to work with yamamoto offline on doc updates for ryu plugin deprecation.
21:04:58 <mestery> Thanks emagana!
21:05:02 <mestery> #topic Bugs
21:05:18 <mestery> enikanorov mentioned that we have some new bugs which are due to the DVR merge, and that he and armax are on these.
21:05:41 <mestery> armax: Any particular links you want to share at this slot?
21:05:44 <armax> mestery, enikanorov: these seem to cause log noise more than anything ele
21:05:48 <armax> *else
21:05:53 <mestery> armax: OK, that's less serious then. :)
21:06:07 <armax> mestery: still treating them seriously, working on them :)
21:06:14 <mestery> armax: ++
21:06:25 <armax> mestery: but as far as I can tell, no major gate outage or anything like that
21:06:39 <mestery> armax: That echoed enikanorov's thoughts as well, thanks!
21:07:00 <mestery> #topic Team Discussion Topics
21:07:20 <mestery> First item is about rotating the team meeting time.
21:07:31 <mestery> I think marun proposed this to the agenda.
21:07:49 <marun> We discussed this at summit and it got lost
21:07:51 <mestery> Thoughts from people on a rotating meeting?
21:07:53 <mestery> marun: ++
21:07:59 <nati_ueno> ++
21:08:15 <ajo_> that'd be nice,  it's very late here ;)
21:08:26 <mestery> This ultimately ties into another item which I doubt we'll get to today (sub-team culling and life cycle management, and how this meeting is run).
21:08:33 <marun> Ideally we would rotate the time between two slots so that folks in non-NA timezones would have an easier time participating
21:08:34 <mestery> But we've only got 52 minutes left in this meeting ...
21:08:39 <marun> Tempest already does this, btw
21:08:47 <markmcclain> ceilometer and nova too
21:09:00 <emagana> +1 let's do it!
21:09:07 <reed> yeah, I think it's fairly well accepted practice in other teams, too
21:09:18 <mestery> I'll take an action to take care of setting this up then.
21:09:24 <marun> mestery: +1
21:09:31 <mestery> #action mestery to setup rotating neutron team meeting schedule
21:09:42 <mestery> I'll start a thread on the mailer with some proposed time slots. Fair?
21:09:43 <markmcclain> the rotation would be good… I think we should implement starting in Sept which is after FF
21:09:55 <marun> fair to me
21:10:00 <pcm_> +1
21:10:02 <mestery> markmcclain: It may take us long to come to an agreement on the mailer.
21:10:02 <rudrarugge> +1
21:10:03 <mestery> ;)
21:10:18 <ajo_> +1
21:10:21 <carl_baldwin> +1
21:10:23 <amotoki> +1
21:10:35 <markmcclain> haha
21:10:37 <mestery> OK, good, agreement!
21:10:37 <ArxCruz> krtaylor: hey, sorry, I was finishing things for the travel
21:10:39 <gus> +1 (although I know the other time is going to end up worse for me ;)
21:11:14 <Sukhdev> +1 - suggest we do the rotations after Juno
21:11:35 <mestery> OK, for the next topic, reed has kindly volunteered to run this portion of the meeting around the GBP Topic, how we got here, and how not to get here again in the future.
21:11:38 <mestery> #chair reed
21:11:39 <openstack> Current chairs: mestery reed
21:11:47 <mestery> reed: The floor is yours!
21:11:53 <reed> yeah! the fun part :)
21:12:08 * dougwig makes popcorn.
21:12:22 * sc68cal digs a foxhole
21:12:41 <reed> anyone wants to share their thoughts on how we got at this point?
21:12:48 <mestery> hahahahahaha
21:13:01 <markmcclain> reed: I'll start :)
21:13:23 <reed> great, thanks markmcclain, let's start
21:14:10 <mscohen> reed: curious what you mean by that?  For GBP, we have been working on this for some time.  We had a session in Atlanta on this and proposed a blueprint and have been running weekly meetings on the topic.
21:14:36 <alagalah_> mscohen: +1
21:14:40 <reed> what I mean is framing the current status of the discussion around GBP
21:14:43 <markmcclain> mscohen: that's exactly what reed wants to establish how we got here
21:15:15 <rkukura> Not sure we’d even get agreement on where we are.
21:15:29 <reed> in Atlanta a working group was established, right? and the group met weekly
21:15:41 * mestery notes if we can't agree on where we are, we're bound to get to this exact (unknown) spot again soon.
21:15:48 <reed> progressing with code, sending patches in
21:15:49 <s3wong> reed: actually in Hong Kong a working group was established
21:15:58 <SumitNaiksatam> reed: this actually started in HK
21:16:17 <SumitNaiksatam> the blueprint was registeted in launchpad on oct 24th 2013
21:16:22 <reed> who/what triggered the effort?
21:16:25 <markmcclain> reed: so we've ended up at this point because for the most part while the group based policy team has been iterating in the open for some time there has been a large contingent of the core largely disengaged from the discussion
21:16:35 <SumitNaiksatam> it was followed up with a session in the HK summit in november 2013
21:16:49 <markmcclain> the reasons for disengagement are varied among the reviewers
21:17:09 <banix> markmcclain: Yes that is why we are here. Agree.
21:17:20 <ivar-lazzaro> markmcclain: who was disengaged exactly?
21:17:25 <reed> SumitNaiksatam, just to be super clear: the discussion was at the *Design* summit, in HK and Atlanta, right ?
21:17:40 <markmcclain> reed: yes this has come up twice
21:17:40 <SumitNaiksatam> reed: yes, it started during that summit
21:17:57 <SumitNaiksatam> reed: actually the blueprint was registered priror to the summit
21:18:00 <mestery> reed: Yes, in HK and Atlanta.
21:18:20 <reed> SumitNaiksatam, what sparked the discussions? user requests? product management? personal interests? other?
21:18:40 <salv-orlando> I feel like in Law & order
21:18:49 <salv-orlando> I see a prosecutor, but I see no judge
21:18:55 <markmcclain> reed: all three
21:19:00 <emagana> reed: I got the feeling this is going to be a long discussion and there are other topics to cover, can you establish a limit on the time invested in this discussion?
21:19:00 <SumitNaiksatam> markmcclain: i can list the following cores be engaged: markmcclain, rkukura, mestery, oleg, nati_ueno, armax emagana who have been giving feedback on the patches
21:19:26 <markmcclain> SumitNaiksatam: the level of engagement is not the same across
21:19:30 <emagana> salv-orlando: +1
21:19:31 <reed> emagana, I can stop any time and chase you all individually :)
21:19:44 <blogan> is it a requirement that most cores are engaged for something of this magnitude get merged?
21:19:49 <SumitNaiksatam> markmcclain: agreed but that is because there is a pending -2 on the patch
21:19:51 <salv-orlando> reed as long as you’re not chasing me with a stick, it’s fine!
21:19:51 <mscohen> we have been investigating ways of creating more flexible abstractions for describing network resources.   that was the spark behind this.
21:19:56 <a_le> emagana: there should be a timelimit on -2's with no follow up after the issues are addressed!!!
21:19:57 <emagana> reed: not a bad idea... :-)
21:19:58 <mestery> blogan: Fair question.
21:20:32 <markmcclain> blogan: yes
21:20:35 <blogan> mestery: that also bring up the question of how magnitude is measured
21:20:37 <reed> so is there consensus that parts of the GBP efforts were done in parallel and without enough interaction with core development?
21:20:47 <markmcclain> because this particular feature is sizeable
21:20:54 <reed> salv-orlando, this is not the inquisition
21:21:01 <emagana> a_le: not sure what you mean.
21:21:09 <SumitNaiksatam> reed: i would say a strong no to your question
21:21:20 <salv-orlando> reed: if it were we were probably not using internet!
21:21:35 <marun> The group policy team has been very diligent about following the policies and procedures that are defined for the Neutron project.
21:21:41 <marun> Despite this, the initiative has remained deeply divisive, as evidenced by the the traffic on the mailing list this past week.
21:22:01 <markmcclain> marun: that is mostly true
21:22:02 <marun> I think this highlights the importance of the non-technical aspects of contributing to an open source project like Neutron.  It's not enough to discuss and implement.
21:22:02 <mestery> marun: good summary
21:22:05 <reed> marun, SumitNaiksatam: why do you think it's such a hot topic?
21:22:11 <mscohen> what is so divisive about it?
21:22:13 <reed> or divisive, as you say?
21:22:21 <marun> The importance of securing broad consensus on potentially contentious work cannot be understated.
21:22:36 <SumitNaiksatam> reed: its definitely a hot topic from a technical perspective
21:22:38 <marun> And I think it's clear that such consensus has not yet been achieved for the policy effort.
21:22:54 <markmcclain> reed: there are still pockets of the community that don't agree with the approach for a variety of reasons
21:22:58 <SumitNaiksatam> reed: other than that i only see a set of vocal people talking against it
21:23:00 <reed> marun, indeed, I think it's pretty clear
21:23:08 <markmcclain> my -2 reflects that disagreement that I've heard from many all summer
21:23:17 <SumitNaiksatam> reed: why do you say that its pretty clear?
21:23:32 <SumitNaiksatam> okay lets take the case of the -2
21:23:44 <reed> so we got to this point because despite two summits and lots of meetings, online, offline, etc, there is still no consensus on the features?
21:23:45 <banix> so I think we failed as a community (GBP group and the rest) to openly discuss the disagreements
21:23:56 <SumitNaiksatam> the -2 was initially put since there was no data path patch
21:24:05 <marun> 778897
21:24:11 <a_le> markmcclain: you have never mentioned that before.
21:24:26 <a_le> the -2 never mentioned any disagreement you ever heard
21:24:32 <ivar-lazzaro> SumitNaiksatam: exactly, that was the -2 reason originally :)
21:24:38 <SumitNaiksatam> at that point the data path patch was WIP
21:25:07 <marun> I think it's important to separate discussion of procedural issues from the lack of consensus.
21:25:10 <markmcclain> banix: agreed someone in another project once said we are much better at using procedures to get what we want than having the hard discussions we have to have to have from time to time
21:25:17 <SumitNaiksatam> and the data path patch was shortly pushed upstream shortly after the -2 was posted (patch was pushed by rkukura)
21:25:23 <reed> banix, interesting... why do you think we failed at discussing the disagreement?
21:25:27 <salv-orlando> I made one fundamental complaint back in HK - that this should have been proposed as a new tenant API. This went largely ignored, and so I thought I was wrong after all. Then from what I read last week, it seems to me that several groupo policy contributor are actually seeing it as a new api with different abstractions.
21:25:28 <rkukura> The people actively working on the feature, which includes two cores, did reach consensus. That consensus was described in the spec that was reviewed and approved.
21:25:55 <SumitNaiksatam> reed: i think we are going in circles here
21:26:06 <SumitNaiksatam> reed: we dont even know what the diagreement is about
21:26:09 <salv-orlando> Which to me is not consistent with the impleentation as a service plugin, despite the mapping effort. So I would like to reconsider that. But at the same time I don’t want to be slapped in the face for beeing too late.
21:26:11 <nati_ueno> salv-orlando: which one?
21:26:12 <markmcclain> rkukura: the consensus was only reached within the GPB team
21:26:14 <salv-orlando> I have been slapped already once.
21:26:16 <SumitNaiksatam> reed: can i speak for a couple of minutes?
21:26:19 <reed> SumitNaiksatam, please
21:26:25 <SumitNaiksatam> reed: its a request
21:26:28 <marun> rkukura: That consensus does not appear to have been broad enough, or the mailing list threads wouldn't have spanned 100+ posts.
21:26:44 <SumitNaiksatam> ok let me start from the beginning
21:27:00 <banix> reed, salv-orlando: it would have been wonderful to have your ideas discussed in our group meetings; I tried to the extent I could to bring in other cores to our discussions but did not succeed;
21:27:04 <SumitNaiksatam> i mentioned that the bp was registered in launchpad on oct 24th 2013
21:27:14 <SumitNaiksatam> it was discussed during the HK summit in nov 2013
21:27:30 <SumitNaiksatam> after that we had weekly IRC meetings on this topic for the entire H cycle
21:27:42 <SumitNaiksatam> during this whole time a google doc was published in the community
21:27:54 <SumitNaiksatam> and it was worked on collaboratively by several people
21:28:12 <SumitNaiksatam> so this went on for the the whole of the H cycel
21:28:24 <SumitNaiksatam> again we had weekly IRC meetings
21:28:26 <marun> banix: That's an aspect of contribution - it's not enough to submit patches.  It's the responsibility of a given initiative to secure the necessary support to have it proceed.  If at first you don't succeed - try a different path?
21:28:41 <reed> SumitNaiksatam, I get it, it looks to me like the GBP team did apparently everything right, all the things that I suggest teams to do when they want to propose large new features
21:28:51 <SumitNaiksatam> reed: there is some more
21:28:57 <reed> and yet, something failed here and I'd like to get to the root cause
21:29:01 <reed> SumitNaiksatam, please continue
21:29:19 <salv-orlando> banix: it’s pretty much my fault. Since the havana release I’ve stopped working on all “new” stuff because work was needed first and foremost to make neutron a decent product. So I’ve lost contact with group policy, load balancing, firewall, etc.
21:29:20 <SumitNaiksatam> towards the end of the H cycle the team was told to create a PoC to validate
21:29:23 <SumitNaiksatam> the concept
21:29:29 <SumitNaiksatam> the team did this
21:29:32 <marun> …everything right, barring actually securing sufficient trust and goodwill from the community for their efforts.
21:29:37 <SumitNaiksatam> iterating in a public repository
21:29:47 <marun> But that's not on the contribution checklist, so it's easy enough to ignore.
21:30:03 <SumitNaiksatam> we presented this PoC in the Atlanta summit
21:30:18 <SumitNaiksatam> also note that this PoC was not an individual effort
21:30:19 <marun> You're describing what you've done, and I accept everything you say.
21:30:21 <markmcclain> I don't think anyone disputes you tried to make this open
21:30:35 <marun> It doesn't mean you have achieved the outcome desired, though.  :(
21:30:40 <SumitNaiksatam> there were about 10 or more people from different organizations participating
21:30:43 <banix> marun, understand now; my assumption (which now i know was incorrect) was that if no objection is raised and then the spec is approved it means even if there is some diasagreements they are not serious in nature; That is the aspect we need to work on for this and any other initiative in coming cycles
21:30:57 <SumitNaiksatam> then during the ATL summit this was presented in a design summit session, and also in the conference session
21:31:13 <salv-orlando> Would you agree on this short summary: a large chunk of the community works on something new for a long time. The process is followed. 4 core dev review the specification, 3 approve it. Other devs, which ignored the specification and did not complain at the time, now have cold feet.
21:31:16 <marun> banix: The approval of a spec was never intended as a commitment to accept a feature.
21:31:17 <rkukura> banix: +1
21:31:17 <reed> marun, that's definitely something to keep in mind (the lack of a point on the checklist)
21:31:33 <SumitNaiksatam> we were provided feedback during the summit session, which we incorporate in the patches and presented the first patch on May 26th
21:31:36 <marun> banix: It is intended to indicate that, to the best of our knowledge, we would like work to proceed.
21:31:43 <salv-orlando> what to do? Ignore people with cold feet and tell them they had their time to talk?
21:31:43 <reed> salv-orlando, looks like a fair assessment to me, from what I understand
21:32:01 <marun> banix: It doesn't preclude a feature being bumped for any number of reasons.
21:32:09 <salv-orlando> reed: I’m just trying to avoid the conversation from getting sidestepped into details ;)
21:32:13 <markmcclain> salv-orlando: good synopsis
21:32:21 <tmc3inphilly> mestery, do the cores meet on a regular caidence to discuss all of the WIP?
21:32:27 <banix> marun: so does it make any sense if we have different categories of specs ….
21:32:44 <SumitNaiksatam> after reviews between May 26th and July 2nd, during which several comments were provided, a -2 was put on the patch
21:32:46 <marun> banix: I think we need to clarify the spec documentation so that the expectation is in line with our intentions.
21:32:47 <salv-orlando> does our current “law” tell how to behave in this case?
21:32:50 <mestery> tmc3inphilly: Usually at our weekly "core only" meetings at the clubhouse, yes.
21:32:54 <mestery> tmc3inphilly: I jest, no, we do not.
21:33:04 <SumitNaiksatam> the first time we heard back after july 2nd was on Aug 4th
21:33:04 <reed> marun, bumping something like this so late may require building a strong case, because this sort of issue can make/break the collaboration on OpenStack
21:33:12 <SumitNaiksatam> when this erupted it where we are now
21:33:21 <marun> I think there is something else in the mix, though.
21:33:22 <markmcclain> SumitNaiksatam: I spent a good deal of time talking to those with reservations
21:33:24 <ivar-lazzaro> salv-orlando: I think the solution to this is understanding how 'complaints' late in the process should be addressed in a first place
21:33:39 <marun> The fact that up until now we have not had a good procedure for evolving new APIs.
21:33:47 <SumitNaiksatam> markmcclain: why did these discussions have to happen in private?
21:33:51 <markmcclain> marun: +100
21:33:52 <SumitNaiksatam> markmcclain: the patches were in gerrit
21:33:56 <reed> I think there are 2 issues: how we solve the immediate GBP problem (merge in trunk, out of trunk, if at all...) and how we deal with future discussions like this
21:34:02 <SumitNaiksatam> markmcclain: why werernt the reservations stated in gerrit?
21:34:06 <rkukura> Why can’t all these people with reservations state their reservations in public?
21:34:10 <markmcclain> SumitNaiksatam: they were private because several folks asked them to be
21:34:16 <marun> Group based policy is a new API, and putting it into the tree in the same way that lbaas, vnpaas and fwaas invites the same problems we had with those efforts in terms of API quality
21:34:20 <SumitNaiksatam> markmcclain: what is that supposed to mean?
21:34:25 <gus> captain obvious: as the reviewer pool increases, it will be increasingly impossible to get 100% agreement.
21:34:44 <SumitNaiksatam> marun: that is an unsubstantiated claim
21:34:46 <markmcclain> rkukura: some felt they were ignored and told their input was not valid because they had months that shoudl have done it earlier
21:34:54 <marun> SumitNaiksatam: Uh
21:34:59 <markmcclain> that is a something I've heard from many folks
21:35:03 <reed> until now we used "lazy consensus", not 100% agreement
21:35:12 <marun> SumitNaiksatam: Given how many people tell me it's crap, I don't think its as unsubstantiated as you seem to think.
21:35:24 <gus> .. so whatever the process is going forwards, it can't rely on 100% agreement in order to make progress.
21:35:26 <marun> SumitNaiksatam: And if you are blind to those quality issues, I'm not sure I trust you to vet group policy's API as stable.
21:35:30 <tmc3inphilly> mestery seems like it would make sense for the cores to meet regularly to discuss items up for review so that there is a core consensus
21:35:34 <SumitNaiksatam> reed: so here we are in the situation where its claimed that reservations were present, but they could not express them - is this how the community works?
21:35:50 <salv-orlando> SumitNaiksatam, marun: what metrics do we have to measure quality?
21:35:56 <marun> SumitNaiksatam: Allowing the API to mature would seem a reasonable middle path, so that iteration can occur before stabilization.
21:36:00 <markmcclain> tmc3inphilly: we do here everyone week
21:36:03 <salv-orlando> specifically gro group policy
21:36:04 <reed> SumitNaiksatam, not sure I understand the question, can you rephrase it please?
21:36:07 <marun> salv-orlando: right now, people complaining :)
21:36:08 <s3wong> reed: 100% agreement is a very difficult requirement to enforce...
21:36:09 <SumitNaiksatam> reed: and a year long effort is being blocked now on the basis of things which were never said or commented!
21:36:13 <a_le> markmcclain: if you hear people have reservations you should encourage them to speak for themselves and voice their reservations in public
21:36:14 <ivar-lazzaro> SumitNaiksatam: +1
21:36:20 <SumitNaiksatam> reed: sure
21:36:32 <marun> SumitNaiksatam: You may notice the effort is stalled.
21:36:34 <salv-orlando> but I guess we have tests passing and jobs ready to be pushed for CI?
21:36:40 <reed> SumitNaiksatam, yep, it feels unfair and that's why we're having this conversation
21:37:21 <SumitNaiksatam> reed: the claim here is that somehow there is this huge section of the community which was against this effort but could not express it (for whatever reason) - and they relied on markmcclain to put a -2 and provided him feedback to preserve the -2 for the time from july 2 to aug 4th
21:37:23 <marun> SumitNaiksatam: I think we have lots of lessons to learn from this experience, but I don
21:37:23 <reed> I think we have a clear view of why/ho we got here... how to move forward?
21:37:24 <a_le> +1 - so here we are in the situation where its claimed that reservations were present, but they could not express them - is this how the community works?
21:37:26 <markmcclain> a_le: I encourage them to talk, but some folks were afraid to step out front of this one for fear of retribution
21:37:43 <salv-orlando> marun, SumitNaiksatam: regarding quality, I think we have some sort of automated testing to verify it? Don’t we?
21:37:55 <marun> salv-orlando: there is no substitute for user feedback
21:37:55 <SumitNaiksatam> reed: so based on that assertion we are supposed to push this effort
21:38:06 <SumitNaiksatam> reed: so my question was - is this how the community is supposed to work?
21:38:13 <salv-orlando> marun: If users are like me, there’s nothing to trust in it
21:38:22 <SumitNaiksatam> reed: most of all - is this the expectation for the cores?
21:38:36 <salv-orlando> and I honeslty have realized most users are like me - therefore no trust anymore to user feedback and any form of anedoctal evidence
21:38:37 <marun> SumitNaiksatam: You're part of this community.  It's built on trust and relationships at least as much as policy and procedure.
21:38:41 <SumitNaiksatam> for -> from
21:38:48 <ivar-lazzaro> marun: what about user feedback who want this to be in tree? (which in the ML seems to be the largest part btw)
21:38:51 <salv-orlando> and even if seems like I’m joking, I’m serious here.
21:38:58 <marun> SumitNaiksatam: If it's not working the way you want it, we welcome your efforts to make it more effective.
21:39:20 <marun> SumitNaiksatam: You have to understand why it works the way it does, though.  It's not enough to claim 'foul!'
21:39:21 <reed> SumitNaiksatam, looking at the numbers of the 'community' I think this sort of friction is normal and to be expected, at this size (we're a lot better than most other collaborations)
21:39:21 * mestery can't tell when salv-orlando is joking anymore.
21:39:55 <reed> how do we get out of the lock?
21:39:56 <salv-orlando> mestery: the nice aspect of being a psychotic jester ;)
21:39:57 <SumitNaiksatam> reed: i fully accept that
21:40:06 <banix> mestery: salv-orlando is always “not joking” :)
21:40:12 <marun> ivar-lazzaro: I've seen the group policy team accept any and all support and feedback that confirms their belief that the effort is on track.
21:40:25 <SumitNaiksatam> reed: but not at the cost of jeopordizing a long runnning effort like this
21:40:33 <reed> SumitNaiksatam, my objective is to find the root cause and keep improving, reduce waste, friction
21:40:35 <marun> ivar-lazzaro: And I've seen the same team ignore criticism.
21:40:44 <marun> ivar-lazzaro: I think this is called 'confirmation bias'
21:40:49 <ivar-lazzaro> reed: yeah exactly, so there should be a process to address complaints later in the process. Otherwise a -1 is always stronger than a +1 ( metaphorically speaking)
21:40:49 <SumitNaiksatam> reed: we can definitely help you with that
21:40:51 <reed> SumitNaiksatam, we need a solution, I agree with you
21:41:13 <reed> ivar-lazzaro, agreed, voicing concerns ...
21:41:31 <reed> do people really feel for their jobs if they voice concerns?
21:41:40 <mscohen> ideally, we would like a solution that would work for Juno as well.  There are users on the ML who expressed interest in consuming this work.
21:41:46 <banix> so the question is where we go from here :)
21:41:59 <ivar-lazzaro> mscohen: +1
21:42:04 <markmcclain> mscohen, banix: I've got a way to address
21:42:12 <markmcclain> #link https://wiki.openstack.org/wiki/Network/Incubator
21:42:14 <marun> ivar-lazzaro: which suggests the need for an incubation repo.  So that we can merge early and often and always be able to correct mistakes before we have to accept a feature as stable.
21:42:35 <marun> ivar-lazzaro: having to have a huge chain of patches in flight makes it super painful on all who want to review
21:42:42 <reed> mscohen, technically speaking code doesn't need to be in trunk to be consumed by users (there is a separate thread on this at the moment)
21:42:50 <ivar-lazzaro> marun: that is not the only solution proposed though :)
21:42:59 <banix> markmcclain: great to see your proposal; will need some time to read through
21:43:03 <marun> ivar-lazzaro: it's the best one so far
21:43:15 <mscohen> markmcclain: I think this is an interesting direction.  My worry is that the incubator may end up a “dumping” ground if its not well integrated into the rest of neutron and openstack
21:43:16 <markmcclain> marun: +1000 the large chains were an effort to solve one problem but created another type
21:43:36 <SumitNaiksatam> reed: that thread is a separate and a longer discussion
21:43:42 <markmcclain> mscohen: so the 30sec pitch is the incubator is designed to take code that will land <2 cycles
21:43:47 <tmc3inphilly> markmcclain, mestery: why would we go through this process with LBaaS if we are going to be spinning it out within 2 cycles
21:43:51 * mestery worries about core reviewer time for an added incubator repository and how to avoid another GBP via the incubator.
21:44:05 <ivar-lazzaro> markmcclain: your 'plus' are slowing getting over 9000 :)
21:44:07 <mestery> tmc3inphilly: Read the wiki page, we can spinout right from the incubator if we need to.
21:44:09 <SumitNaiksatam> mestery: +1
21:44:10 <mscohen> But that does not address my concern of doing something for Juno.  I think GBP is past that point.
21:44:19 <reed> I don't think there is a simple solution to this problem ...
21:44:21 <mestery> I'm not saying these aren't solvable issues.
21:44:30 <SumitNaiksatam> reed: we need more time think about the incubator proposal
21:44:30 <reed> I think we should focus on GBP
21:44:33 <blogan> I think if the incubator is executed correctly it will benefit neutron, but if it is not it is just kicking the can the road
21:44:35 <rkukura> markmcclain: The incubator proposal seems useful for experimantation, but the GBP effort is much more of a feature we’ve committed to implementing, not an experiment.
21:44:37 <SumitNaiksatam> reed: yes
21:44:47 <mestery> blogan: +100
21:45:07 <SumitNaiksatam> reed: so specifically in the case of GBP, this its a good candidate for what rkukura has proposed
21:45:18 <reed> blogan, indeed, it's a delicate decision, wouldn't suggest rushing it to address the issue with GBP
21:45:20 <markmcclain> rkukura: except that gpb api isn't stable
21:45:24 <tmc3inphilly> mestery: I like the process as it helps stabalize Neutron and should ensure that it remains stable.
21:45:32 <marun> SumitNaiksatam: I don't think we want anything merging that doesn't have broad consensus.
21:45:32 <SumitNaiksatam> reed: rkukura’s proposal is here #link http://lists.openstack.org/pipermail/openstack-dev/2014-August/042461.html
21:45:37 <markmcclain> rkukura: jaypipes was asking very valid questions and maturing the API is exactly what we need
21:45:51 <a_le> http://s2.quickmeme.com/img/eb/eb331b1b9bf0f029722a7e734a51c9fcb7aaefb6b6a20df33e2f5baa200eff9e.jpg
21:45:51 <marun> SumitNaiksatam: And we don't have time this late in the cycle to gain that consensus without negatively impacting more important work
21:45:54 <rkukura> markmcclain: The working assumption all along is that initial releases of new APIs are not considered stable. My proposal is just to formalize and clarify that.
21:45:55 <emagana> mestery and reed: we just have 15 minutes left!
21:46:00 <markmcclain> tmc3inphilly: yes I want ops to know that what is in tree is production ready
21:46:10 <mestery> emagana: That's plenty of time to find a solution which makes everyone happy here.
21:46:11 <marun> SumitNaiksatam: So, incubate it until we do have consensus
21:46:18 <reed> emagana, fair enough, I don't think we'll reach consensus on how to proceed in that time
21:46:22 <emagana> emagana: stop being such as time controller!
21:46:24 <blogan> If neutron cores are the only ones to review the incubator projects, then I don't see how that will help core reviewers bandwidth or velocity on getting merged into the incubator themselves
21:46:24 <markmcclain> and that stuff in the incubator is getting there, but still needs work to matrue
21:46:40 <emagana> mestery: I hope so  ;)
21:46:44 <mestery> emagana: ;)
21:46:48 <reed> mestery, we can continue on the list, on rkukura proposal and I'll chase some more of you offline
21:46:52 <rkukura> Get the feature implemented to production quality, get it in the hands of eartly adopters, and incorporate the feedback to stabilize the feature in the next release.
21:46:55 <markmcclain> blogan: the goal is that smaller more incremental patches can go in there
21:46:59 <reed> and if needed we can continue next week
21:46:59 <mestery> reed: Thank you sir!
21:47:00 <markmcclain> so that review time is less
21:47:29 <nati_ueno> IMO, we should have a special meeting slot for this
21:47:44 <nati_ueno> otherwise, we lose core meeting time, right?
21:47:48 <mestery> nati_ueno: For GBP or incubator or something even more contentious?
21:47:53 <marun> rkukura: why would we want to rely on an implicit warning of an unstable api when we could make it explicit via separate distribution?
21:47:54 <dougwig> blogan: i'd hope/expect the bar to be different for merging; namely, the expectation of rapid iteration.  i don't want to see a bunch of non-cores reviewing, and end up with a big ball of code that cores have never seen at graduation time.
21:47:54 <blogan> markmcclain: so if it is the requirement that a majority of cores have to be engaged, does that mean majority of cores have to be engaged throughout the lifecycle of incubated projects or only upon graduation?
21:47:55 <nati_ueno> marun: both of
21:48:08 <mestery> blogan: Both!
21:48:17 <marun> both
21:48:18 <nati_ueno> sorry mestery: both of
21:48:23 <mestery> nati_ueno: Got it.
21:48:37 <nati_ueno> mestery: thanks
21:48:45 <marun> dougwig: +1
21:49:18 <blogan> mestery, marun: in that case do you think if GBP had done this from the start would we be in the same predicament?
21:49:19 * banix wishes for the good old slow and sometimes dull meetings of the past :) cannot keep up
21:49:29 <marun> dougwig: there could be more emphasis on merging small patches in incubator, since we know that the feature is still evolving
21:49:38 <reed> emagana, mestery, what are the next topics in the agenda?
21:49:42 <mestery> blogan: That's the part we hope to avoid.
21:49:47 <mestery> OK, lets move on.
21:49:58 <salv-orlando> Do we have to go on like this for another week? I don’t think the user community, botht the part that uses v2 API and the one that can’t wait to use v3 API will see all this turmoil as positive.
21:50:07 <emagana> reed: Contrail Plugin review & Sub-team culling
21:50:13 <mscohen> so where does that leave this past topic?
21:50:14 <kevinbenton> It seems there is nothing GBP could have done because non of the dissent was strongly voiced until a couple of days ago
21:50:17 <mestery> marun: Do we need to talk contrail next?
21:50:19 <salv-orlando> so if we can at least agree on how we should put an end to this discussion….
21:50:28 <SumitNaiksatam> reed: so whats the resolution here?
21:50:36 <ivar-lazzaro> kevinbenton: +1
21:50:37 <reed> SumitNaiksatam,  mscohen, no consensus, we'll have to continue discussion
21:50:39 <SumitNaiksatam> reed: regarding GBP?
21:50:42 <marun> blogan: I think incubating group policy could have avoided this, yes.  There could have been more feedback earlier on and no need to rush things before consensus.
21:50:45 <marun> mestery: yes
21:50:51 <mestery> marun: OK, we'll get to it next.
21:51:04 <a_le> kevinbenton: +1billion
21:51:07 <banix> salv-orlando: +1
21:51:09 <mscohen> reed: the problem with that is that juno-3 is moving along.  We’re defacto blocked from Juno if this continues though.
21:51:20 <kentwu> kevinbenton: +1
21:51:25 <mestery> My personal fear is that even if someone magically says "lets the GBP reviews proceed" there seems to be the sense they would get -2s from others and we'd be right back here next week.
21:51:30 <blogan> marun: I'm not so sure myself.  I'm all for the incubator project (if its executed well), but I think framing it as a solution to what GBP is going through isn't correct
21:51:41 <marun> mscohen: The incubator proposal doesn't require incubator release to follow the openstack cycle.
21:51:43 * mestery notes his english isn't sluring because of anything alcoholic.
21:51:43 <rkukura> I’m not really convinced that the same exact blocking behaviour wouldn’t occur any time there is an attempt to graduate something “contentious” from incubation.
21:51:56 <marun> mscohen: Release could be whenever there is something meaningful to distribute
21:51:57 <reed> mscohen, SumitNaiksatam: I'll be working this week with you to move this forward
21:52:00 <emagana> mestery: good point, I think it makes sense markmcclain proposal then
21:52:00 <markmcclain> mestery: that is true
21:52:04 <SumitNaiksatam> reed: sure
21:52:12 <sc68cal> rkukura: +1
21:52:17 <marun> rkukura: I think we'd want to have regular checkpoints on incubated efforts.
21:52:23 <a_le> mestery: where do you get that sense from?
21:52:24 <reed> I don't think we can do more than this at the moment, there clearly is no consensus
21:52:24 <dougwig> i agree with blogan on GBP/incubator.  we all assume the best of intentions, but what's to stop a last minute -2 on graduation due to "people that are opposed but don't want to speak out" ? nothing.  this comes down to people, not process.
21:52:24 <mestery> So, with that knowledge in tow, how do we move forward?
21:52:36 <marun> rkukura: so that concerns could be raised early enough to address them constructively and without unnecessary fallout
21:52:45 <banix> is it fair to say until we find consnsus we wont be able to merge GBP and alike?
21:52:56 <reed> is anyone here from Contrail/Juniper?
21:53:04 <nati_ueno> hi
21:53:04 <salv-orlando> honeslty from what I see we can keep discussing for months but we’ll never reach a 100% consensus
21:53:06 <rudrarugge> hi
21:53:07 <marun> dougwig: incubator projects would have 2 cycles to gain consensus
21:53:08 <praneet> yes
21:53:08 <mestery> a_le: Were you paying attention to this meeting?
21:53:14 <banix> and we need to figure out the process to get there whether it is through markmcclain ’s proposal or something else
21:53:18 <aranjan> hi
21:53:21 <dougwig> marun: gbp has had two cycles.  :)
21:53:29 <reed> salv-orlando, have you ever seen a meeting at the UN?
21:53:31 <marun> dougwig: not in the tree, they haven't
21:53:47 <marun> dougwig: if things were merged and had had 2 cycles to mature, it would be very different
21:53:50 <a_le> mestery: yes, and the elephant in the room is that no one expressed dissent in the open
21:54:00 <salv-orlando> reed: noe, but Germans and English are still arguing over a goal scored 48 years ago
21:54:09 <marun> a_le: There are vendors involved in this project.
21:54:16 <mestery> a_le: I was hoping people would, but alas, we're not going to be that lucky.
21:54:31 <reed> salv-orlando, this is nothing compared to that :)
21:54:37 <salv-orlando> reed: and honestly the kind of compromise they do at the UN will probably not be so good for a software project
21:54:37 <marun> so, contrail?
21:54:47 <nati_ueno> ya.
21:54:50 <salv-orlando> yeah let’s move contrail
21:54:50 <reed> marun, right, contrail :)
21:54:52 <mestery> Lets move on
21:54:53 <mestery> contrail
21:54:54 <SumitNaiksatam> mestery: that leads me to question if there really was any dissent, or are we fishing for reasons now?
21:54:55 <nati_ueno> marun: could you share your thought on here?
21:55:00 <gus> something I've seen address problems like this elsewhere fwiw is clearly separating reviewer vs approver roles.  reviewers get to add comments, but fundamentally only approver's opinions matter.  You then make policies that restrict the number and name up front who the approvers are going to be for a particular change (ie: it wouldn't just de-facto be all core reviewers).
21:55:01 <dougwig> marun: maybe, but there's a very real risk that the "graduation" gate is similar to the current "push a chain of review in" gate.  it goes back to the soft touch issues you mentioned earlier.
21:55:13 <marun> Em
21:55:26 <marun> Maybe we'll have to talk about contrail separately?
21:55:32 <marun> we have 5 minutes left
21:55:32 <reed> #chair mestery
21:55:33 <openstack> Current chairs: mestery reed
21:55:37 <nati_ueno> who's interested in that topic?
21:55:38 <mestery> #unchair reed
21:55:39 <openstack> Current chairs: mestery
21:55:40 <nati_ueno> I mean contrail
21:55:41 <banix> i think related to this is also a large number of other specs that have been approved and honestly I cannot think them getting in… we will have more unhappy developers
21:55:48 <nati_ueno> we have also have a separate meeting on this
21:55:54 <marun> nati_ueno: agreed
21:56:10 <salv-orlando> nati_ueno, marun: I’ve pointed out that I do not understand why we would need a plugin which is pretty much a proxy which does some minimal changes to the payload and then sends the API request to another neutron endpoint. However, as you see I’ve not put a -2
21:56:30 <marun> banix: The fact that spec approval doesn't guarantee feature inclusion needs to be communicated better in the docs and on the list.
21:56:31 <roampune> why not put it to vote with ATC's
21:56:33 <nati_ueno> salv-orlando: Thanks. could you have a time for discussion for this?
21:56:33 <salv-orlando> because that’s the way contrail server is designed, and as much as that seems crazy to me I have no voice there
21:56:52 <marun> roampune: What qualifies someone to vote on a given issue?
21:57:15 <nati_ueno> salv-orlando: contrail want to use neutron functionalities such as policy.json quota services (vpn lbaas, fwaas)
21:57:15 <markmcclain> reed: thanks for helping to work through discussion
21:57:21 <marun> roampune: we are not actually a democracy.  People have to earn their influence, it isn't given for showing up.
21:57:23 <salv-orlando> nati_ueno: there is no need to discuss that - from the neutron point of view the code is simple and linear. I think you’ll end up in trouble everytime there will be an API change but is none of my business that
21:57:24 <nati_ueno> salv-orlando: l2 stuff is proxyed thorught
21:57:45 <nati_ueno> salv-orlando: ya that's pain point but we can work on it
21:57:54 <marun> I think that contrail is not a very useful plugin from a community perspective.
21:58:05 <marun> It is a shim to integrate the contrail controller into Neutron, sure.
21:58:17 <sc68cal> marun: showing up is important, turning people away with comments like that does not further the project
21:58:21 <marun> But it provides no real benefit to the community that couldn't be easily carried out of tree.
21:58:24 <nati_ueno> marun: ya but it is also point of neturon, right? user can choose backend. no lockin
21:58:32 <salv-orlando> nati_ueno: yes using neutron for authN/authZ only is a bit… not enough. But again, if that’s how contrail works, I can’t really say anything about that. So from my perspective, I am happy to see that plugin land in jno.
21:58:42 <marun> And the contrail team has a bad record of interacting with the community.
21:58:42 <rudrarugge> marun: backend choices are dependent on the plugin
21:58:50 <emagana> marun: few other plugins will fall into that category then
21:59:05 <nati_ueno> it looks like there are some communication issue. but i can fix it
21:59:08 * salv-orlando hoping that we’ll move all non-reference plugin away from the main code repo in Kilo because it has become unmaneageable
21:59:09 <marun> Things like escalating to the foundation rather than trying to resolve things direclty.
21:59:25 <markmcclain> marun: most plugins are thin shims
21:59:30 <mestery> salv-orlando: ++
21:59:33 <nati_ueno> marun: ya we should discuss it in here
21:59:33 <mestery> salv-orlando: That's next week's topic.
21:59:39 <mestery> salv-orlando: I'm sure it will be an easy discussion.
21:59:39 <reed> marun, who is 'the foundation'?
21:59:45 <marun> you, as I understand it
21:59:54 <reed> marun, ok, jutss checking :)
21:59:58 <salv-orlando> mestery: huh? What was the last easy discussion we had?
22:00:02 <mestery> 1 minute left
22:00:04 <markmcclain> my main concern with this particular implementation is that it is different enough that attempts to refactor the core will break it
22:00:14 <reed> marun, and indeed, I'd be happy to get involved
22:00:30 <markmcclain> but that is on the back of the proposing company
22:00:33 <marun> That said, I have been assured that the unproductive modes of interaction that have characterized the contrail team thus far are not going to continue.
22:00:48 <mestery> OK, we;re at time folks.
22:00:50 <sc68cal> yeah if we refactor core and it breaks them, oh well
22:00:58 <mestery> I invite you all back to next week's weekly neutron meeting where the fun will continue.
22:00:58 <nati_ueno> markmcclain: it is chagned in latest one
22:00:59 <mestery> #endmeeting