21:00:42 #startmeeting networking 21:00:43 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 21:00:46 The meeting name has been set to 'networking' 21:00:52 #link https://wiki.openstack.org/wiki/Network/Meetings Agenda 21:00:57 I expect this to be a boring meeting ... 21:01:02 lol 21:01:04 #topic Announcements 21:01:07 hola! 21:01:17 * salv-orlando bored already 21:01:21 I'm sure people have forgotten, but Juno-3 is approaching fast 21:01:22 #link https://launchpad.net/neutron/+milestone/juno-3 21:01:32 Please spend some time reviewing things for Juno-3. 21:01:43 I expect a nice gate crush the closer we get to both FPF and FF. 21:02:04 Also, just a note that Neutron policies are documented on the wiki 21:02:05 #link https://wiki.openstack.org/wiki/NeutronPolicies 21:02:17 And one final announcment from the Ryu team: 21:02:23 #info the Ryu plugin is being deprecated in Juno 21:02:33 #info Juno is the last release to support Ryu plugin 21:02:45 #info The Ryu team will be focusing on the ofagent going forward 21:02:48 Any other announcements? 21:02:57 what's the impact on users of the Ryu plugin? 21:03:12 reed: There is no upgrade provided by the ryu team per their notes 21:03:22 cool, thanks 21:03:23 reed: It seems it will be a manual move to ML2+ofagent 21:03:48 i plan to write some text to document how to transit to eg. ofagent 21:03:55 yamamoto: Thanks! 21:04:10 yamamoto: we will need to update some guides 21:04:28 yamamoto: I will touch based with you offline 21:04:49 emagana: thank you 21:04:54 #action emagana to work with yamamoto offline on doc updates for ryu plugin deprecation. 21:04:58 Thanks emagana! 21:05:02 #topic Bugs 21:05:18 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 armax: Any particular links you want to share at this slot? 21:05:44 mestery, enikanorov: these seem to cause log noise more than anything ele 21:05:48 *else 21:05:53 armax: OK, that's less serious then. :) 21:06:07 mestery: still treating them seriously, working on them :) 21:06:14 armax: ++ 21:06:25 mestery: but as far as I can tell, no major gate outage or anything like that 21:06:39 armax: That echoed enikanorov's thoughts as well, thanks! 21:07:00 #topic Team Discussion Topics 21:07:20 First item is about rotating the team meeting time. 21:07:31 I think marun proposed this to the agenda. 21:07:49 We discussed this at summit and it got lost 21:07:51 Thoughts from people on a rotating meeting? 21:07:53 marun: ++ 21:07:59 ++ 21:08:15 that'd be nice, it's very late here ;) 21:08:26 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 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 But we've only got 52 minutes left in this meeting ... 21:08:39 Tempest already does this, btw 21:08:47 ceilometer and nova too 21:09:00 +1 let's do it! 21:09:07 yeah, I think it's fairly well accepted practice in other teams, too 21:09:18 I'll take an action to take care of setting this up then. 21:09:24 mestery: +1 21:09:31 #action mestery to setup rotating neutron team meeting schedule 21:09:42 I'll start a thread on the mailer with some proposed time slots. Fair? 21:09:43 the rotation would be good… I think we should implement starting in Sept which is after FF 21:09:55 fair to me 21:10:00 +1 21:10:02 markmcclain: It may take us long to come to an agreement on the mailer. 21:10:02 +1 21:10:03 ;) 21:10:18 +1 21:10:21 +1 21:10:23 +1 21:10:35 haha 21:10:37 OK, good, agreement! 21:10:37 krtaylor: hey, sorry, I was finishing things for the travel 21:10:39 +1 (although I know the other time is going to end up worse for me ;) 21:11:14 +1 - suggest we do the rotations after Juno 21:11:35 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 #chair reed 21:11:39 Current chairs: mestery reed 21:11:47 reed: The floor is yours! 21:11:53 yeah! the fun part :) 21:12:08 * dougwig makes popcorn. 21:12:22 * sc68cal digs a foxhole 21:12:41 anyone wants to share their thoughts on how we got at this point? 21:12:48 hahahahahaha 21:13:01 reed: I'll start :) 21:13:23 great, thanks markmcclain, let's start 21:14:10 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 mscohen: +1 21:14:40 what I mean is framing the current status of the discussion around GBP 21:14:43 mscohen: that's exactly what reed wants to establish how we got here 21:15:15 Not sure we’d even get agreement on where we are. 21:15:29 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 progressing with code, sending patches in 21:15:49 reed: actually in Hong Kong a working group was established 21:15:58 reed: this actually started in HK 21:16:17 the blueprint was registeted in launchpad on oct 24th 2013 21:16:22 who/what triggered the effort? 21:16:25 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 it was followed up with a session in the HK summit in november 2013 21:16:49 the reasons for disengagement are varied among the reviewers 21:17:09 markmcclain: Yes that is why we are here. Agree. 21:17:20 markmcclain: who was disengaged exactly? 21:17:25 SumitNaiksatam, just to be super clear: the discussion was at the *Design* summit, in HK and Atlanta, right ? 21:17:40 reed: yes this has come up twice 21:17:40 reed: yes, it started during that summit 21:17:57 reed: actually the blueprint was registered priror to the summit 21:18:00 reed: Yes, in HK and Atlanta. 21:18:20 SumitNaiksatam, what sparked the discussions? user requests? product management? personal interests? other? 21:18:40 I feel like in Law & order 21:18:49 I see a prosecutor, but I see no judge 21:18:55 reed: all three 21:19:00 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 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 SumitNaiksatam: the level of engagement is not the same across 21:19:30 salv-orlando: +1 21:19:31 emagana, I can stop any time and chase you all individually :) 21:19:44 is it a requirement that most cores are engaged for something of this magnitude get merged? 21:19:49 markmcclain: agreed but that is because there is a pending -2 on the patch 21:19:51 reed as long as you’re not chasing me with a stick, it’s fine! 21:19:51 we have been investigating ways of creating more flexible abstractions for describing network resources. that was the spark behind this. 21:19:56 emagana: there should be a timelimit on -2's with no follow up after the issues are addressed!!! 21:19:57 reed: not a bad idea... :-) 21:19:58 blogan: Fair question. 21:20:32 blogan: yes 21:20:35 mestery: that also bring up the question of how magnitude is measured 21:20:37 so is there consensus that parts of the GBP efforts were done in parallel and without enough interaction with core development? 21:20:47 because this particular feature is sizeable 21:20:54 salv-orlando, this is not the inquisition 21:21:01 a_le: not sure what you mean. 21:21:09 reed: i would say a strong no to your question 21:21:20 reed: if it were we were probably not using internet! 21:21:35 The group policy team has been very diligent about following the policies and procedures that are defined for the Neutron project. 21:21:41 Despite this, the initiative has remained deeply divisive, as evidenced by the the traffic on the mailing list this past week. 21:22:01 marun: that is mostly true 21:22:02 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 marun: good summary 21:22:05 marun, SumitNaiksatam: why do you think it's such a hot topic? 21:22:11 what is so divisive about it? 21:22:13 or divisive, as you say? 21:22:21 The importance of securing broad consensus on potentially contentious work cannot be understated. 21:22:36 reed: its definitely a hot topic from a technical perspective 21:22:38 And I think it's clear that such consensus has not yet been achieved for the policy effort. 21:22:54 reed: there are still pockets of the community that don't agree with the approach for a variety of reasons 21:22:58 reed: other than that i only see a set of vocal people talking against it 21:23:00 marun, indeed, I think it's pretty clear 21:23:08 my -2 reflects that disagreement that I've heard from many all summer 21:23:17 reed: why do you say that its pretty clear? 21:23:32 okay lets take the case of the -2 21:23:44 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 so I think we failed as a community (GBP group and the rest) to openly discuss the disagreements 21:23:56 the -2 was initially put since there was no data path patch 21:24:05 778897 21:24:11 markmcclain: you have never mentioned that before. 21:24:26 the -2 never mentioned any disagreement you ever heard 21:24:32 SumitNaiksatam: exactly, that was the -2 reason originally :) 21:24:38 at that point the data path patch was WIP 21:25:07 I think it's important to separate discussion of procedural issues from the lack of consensus. 21:25:10 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 and the data path patch was shortly pushed upstream shortly after the -2 was posted (patch was pushed by rkukura) 21:25:23 banix, interesting... why do you think we failed at discussing the disagreement? 21:25:27 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 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 reed: i think we are going in circles here 21:26:06 reed: we dont even know what the diagreement is about 21:26:09 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 salv-orlando: which one? 21:26:12 rkukura: the consensus was only reached within the GPB team 21:26:14 I have been slapped already once. 21:26:16 reed: can i speak for a couple of minutes? 21:26:19 SumitNaiksatam, please 21:26:25 reed: its a request 21:26:28 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 ok let me start from the beginning 21:27:00 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 i mentioned that the bp was registered in launchpad on oct 24th 2013 21:27:14 it was discussed during the HK summit in nov 2013 21:27:30 after that we had weekly IRC meetings on this topic for the entire H cycle 21:27:42 during this whole time a google doc was published in the community 21:27:54 and it was worked on collaboratively by several people 21:28:12 so this went on for the the whole of the H cycel 21:28:24 again we had weekly IRC meetings 21:28:26 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 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 reed: there is some more 21:28:57 and yet, something failed here and I'd like to get to the root cause 21:29:01 SumitNaiksatam, please continue 21:29:19 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 towards the end of the H cycle the team was told to create a PoC to validate 21:29:23 the concept 21:29:29 the team did this 21:29:32 …everything right, barring actually securing sufficient trust and goodwill from the community for their efforts. 21:29:37 iterating in a public repository 21:29:47 But that's not on the contribution checklist, so it's easy enough to ignore. 21:30:03 we presented this PoC in the Atlanta summit 21:30:18 also note that this PoC was not an individual effort 21:30:19 You're describing what you've done, and I accept everything you say. 21:30:21 I don't think anyone disputes you tried to make this open 21:30:35 It doesn't mean you have achieved the outcome desired, though. :( 21:30:40 there were about 10 or more people from different organizations participating 21:30:43 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 then during the ATL summit this was presented in a design summit session, and also in the conference session 21:31:13 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 banix: The approval of a spec was never intended as a commitment to accept a feature. 21:31:17 banix: +1 21:31:17 marun, that's definitely something to keep in mind (the lack of a point on the checklist) 21:31:33 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 banix: It is intended to indicate that, to the best of our knowledge, we would like work to proceed. 21:31:43 what to do? Ignore people with cold feet and tell them they had their time to talk? 21:31:43 salv-orlando, looks like a fair assessment to me, from what I understand 21:32:01 banix: It doesn't preclude a feature being bumped for any number of reasons. 21:32:09 reed: I’m just trying to avoid the conversation from getting sidestepped into details ;) 21:32:13 salv-orlando: good synopsis 21:32:21 mestery, do the cores meet on a regular caidence to discuss all of the WIP? 21:32:27 marun: so does it make any sense if we have different categories of specs …. 21:32:44 after reviews between May 26th and July 2nd, during which several comments were provided, a -2 was put on the patch 21:32:46 banix: I think we need to clarify the spec documentation so that the expectation is in line with our intentions. 21:32:47 does our current “law” tell how to behave in this case? 21:32:50 tmc3inphilly: Usually at our weekly "core only" meetings at the clubhouse, yes. 21:32:54 tmc3inphilly: I jest, no, we do not. 21:33:04 the first time we heard back after july 2nd was on Aug 4th 21:33:04 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 when this erupted it where we are now 21:33:21 I think there is something else in the mix, though. 21:33:22 SumitNaiksatam: I spent a good deal of time talking to those with reservations 21:33:24 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 The fact that up until now we have not had a good procedure for evolving new APIs. 21:33:47 markmcclain: why did these discussions have to happen in private? 21:33:51 marun: +100 21:33:52 markmcclain: the patches were in gerrit 21:33:56 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 markmcclain: why werernt the reservations stated in gerrit? 21:34:06 Why can’t all these people with reservations state their reservations in public? 21:34:10 SumitNaiksatam: they were private because several folks asked them to be 21:34:16 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 markmcclain: what is that supposed to mean? 21:34:25 captain obvious: as the reviewer pool increases, it will be increasingly impossible to get 100% agreement. 21:34:44 marun: that is an unsubstantiated claim 21:34:46 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 SumitNaiksatam: Uh 21:34:59 that is a something I've heard from many folks 21:35:03 until now we used "lazy consensus", not 100% agreement 21:35:12 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 .. so whatever the process is going forwards, it can't rely on 100% agreement in order to make progress. 21:35:26 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 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 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 SumitNaiksatam, marun: what metrics do we have to measure quality? 21:35:56 SumitNaiksatam: Allowing the API to mature would seem a reasonable middle path, so that iteration can occur before stabilization. 21:36:00 tmc3inphilly: we do here everyone week 21:36:03 specifically gro group policy 21:36:04 SumitNaiksatam, not sure I understand the question, can you rephrase it please? 21:36:07 salv-orlando: right now, people complaining :) 21:36:08 reed: 100% agreement is a very difficult requirement to enforce... 21:36:09 reed: and a year long effort is being blocked now on the basis of things which were never said or commented! 21:36:13 markmcclain: if you hear people have reservations you should encourage them to speak for themselves and voice their reservations in public 21:36:14 SumitNaiksatam: +1 21:36:20 reed: sure 21:36:32 SumitNaiksatam: You may notice the effort is stalled. 21:36:34 but I guess we have tests passing and jobs ready to be pushed for CI? 21:36:40 SumitNaiksatam, yep, it feels unfair and that's why we're having this conversation 21:37:21 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 SumitNaiksatam: I think we have lots of lessons to learn from this experience, but I don 21:37:23 I think we have a clear view of why/ho we got here... how to move forward? 21:37:24 +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 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 marun, SumitNaiksatam: regarding quality, I think we have some sort of automated testing to verify it? Don’t we? 21:37:55 salv-orlando: there is no substitute for user feedback 21:37:55 reed: so based on that assertion we are supposed to push this effort 21:38:06 reed: so my question was - is this how the community is supposed to work? 21:38:13 marun: If users are like me, there’s nothing to trust in it 21:38:22 reed: most of all - is this the expectation for the cores? 21:38:36 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 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 for -> from 21:38:48 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 and even if seems like I’m joking, I’m serious here. 21:38:58 SumitNaiksatam: If it's not working the way you want it, we welcome your efforts to make it more effective. 21:39:20 SumitNaiksatam: You have to understand why it works the way it does, though. It's not enough to claim 'foul!' 21:39:21 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 how do we get out of the lock? 21:39:56 mestery: the nice aspect of being a psychotic jester ;) 21:39:57 reed: i fully accept that 21:40:06 mestery: salv-orlando is always “not joking” :) 21:40:12 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 reed: but not at the cost of jeopordizing a long runnning effort like this 21:40:33 SumitNaiksatam, my objective is to find the root cause and keep improving, reduce waste, friction 21:40:35 ivar-lazzaro: And I've seen the same team ignore criticism. 21:40:44 ivar-lazzaro: I think this is called 'confirmation bias' 21:40:49 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 reed: we can definitely help you with that 21:40:51 SumitNaiksatam, we need a solution, I agree with you 21:41:13 ivar-lazzaro, agreed, voicing concerns ... 21:41:31 do people really feel for their jobs if they voice concerns? 21:41:40 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 so the question is where we go from here :) 21:41:59 mscohen: +1 21:42:04 mscohen, banix: I've got a way to address 21:42:12 #link https://wiki.openstack.org/wiki/Network/Incubator 21:42:14 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 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 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 marun: that is not the only solution proposed though :) 21:42:59 markmcclain: great to see your proposal; will need some time to read through 21:43:03 ivar-lazzaro: it's the best one so far 21:43:15 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 marun: +1000 the large chains were an effort to solve one problem but created another type 21:43:36 reed: that thread is a separate and a longer discussion 21:43:42 mscohen: so the 30sec pitch is the incubator is designed to take code that will land <2 cycles 21:43:47 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 markmcclain: your 'plus' are slowing getting over 9000 :) 21:44:07 tmc3inphilly: Read the wiki page, we can spinout right from the incubator if we need to. 21:44:09 mestery: +1 21:44:10 But that does not address my concern of doing something for Juno. I think GBP is past that point. 21:44:19 I don't think there is a simple solution to this problem ... 21:44:21 I'm not saying these aren't solvable issues. 21:44:30 reed: we need more time think about the incubator proposal 21:44:30 I think we should focus on GBP 21:44:33 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 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 reed: yes 21:44:47 blogan: +100 21:45:07 reed: so specifically in the case of GBP, this its a good candidate for what rkukura has proposed 21:45:18 blogan, indeed, it's a delicate decision, wouldn't suggest rushing it to address the issue with GBP 21:45:20 rkukura: except that gpb api isn't stable 21:45:24 mestery: I like the process as it helps stabalize Neutron and should ensure that it remains stable. 21:45:32 SumitNaiksatam: I don't think we want anything merging that doesn't have broad consensus. 21:45:32 reed: rkukura’s proposal is here #link http://lists.openstack.org/pipermail/openstack-dev/2014-August/042461.html 21:45:37 rkukura: jaypipes was asking very valid questions and maturing the API is exactly what we need 21:45:51 http://s2.quickmeme.com/img/eb/eb331b1b9bf0f029722a7e734a51c9fcb7aaefb6b6a20df33e2f5baa200eff9e.jpg 21:45:51 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 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 mestery and reed: we just have 15 minutes left! 21:46:00 tmc3inphilly: yes I want ops to know that what is in tree is production ready 21:46:10 emagana: That's plenty of time to find a solution which makes everyone happy here. 21:46:11 SumitNaiksatam: So, incubate it until we do have consensus 21:46:18 emagana, fair enough, I don't think we'll reach consensus on how to proceed in that time 21:46:22 emagana: stop being such as time controller! 21:46:24 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 and that stuff in the incubator is getting there, but still needs work to matrue 21:46:40 mestery: I hope so ;) 21:46:44 emagana: ;) 21:46:48 mestery, we can continue on the list, on rkukura proposal and I'll chase some more of you offline 21:46:52 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 blogan: the goal is that smaller more incremental patches can go in there 21:46:59 and if needed we can continue next week 21:46:59 reed: Thank you sir! 21:47:00 so that review time is less 21:47:29 IMO, we should have a special meeting slot for this 21:47:44 otherwise, we lose core meeting time, right? 21:47:48 nati_ueno: For GBP or incubator or something even more contentious? 21:47:53 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 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 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 marun: both of 21:48:08 blogan: Both! 21:48:17 both 21:48:18 sorry mestery: both of 21:48:23 nati_ueno: Got it. 21:48:37 mestery: thanks 21:48:45 dougwig: +1 21:49:18 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 dougwig: there could be more emphasis on merging small patches in incubator, since we know that the feature is still evolving 21:49:38 emagana, mestery, what are the next topics in the agenda? 21:49:42 blogan: That's the part we hope to avoid. 21:49:47 OK, lets move on. 21:49:58 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 reed: Contrail Plugin review & Sub-team culling 21:50:13 so where does that leave this past topic? 21:50:14 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 marun: Do we need to talk contrail next? 21:50:19 so if we can at least agree on how we should put an end to this discussion…. 21:50:28 reed: so whats the resolution here? 21:50:36 kevinbenton: +1 21:50:37 SumitNaiksatam, mscohen, no consensus, we'll have to continue discussion 21:50:39 reed: regarding GBP? 21:50:42 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 mestery: yes 21:50:51 marun: OK, we'll get to it next. 21:51:04 kevinbenton: +1billion 21:51:07 salv-orlando: +1 21:51:09 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 kevinbenton: +1 21:51:25 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 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 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 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 mscohen: Release could be whenever there is something meaningful to distribute 21:51:57 mscohen, SumitNaiksatam: I'll be working this week with you to move this forward 21:52:00 mestery: good point, I think it makes sense markmcclain proposal then 21:52:00 mestery: that is true 21:52:04 reed: sure 21:52:12 rkukura: +1 21:52:17 rkukura: I think we'd want to have regular checkpoints on incubated efforts. 21:52:23 mestery: where do you get that sense from? 21:52:24 I don't think we can do more than this at the moment, there clearly is no consensus 21:52:24 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 So, with that knowledge in tow, how do we move forward? 21:52:36 rkukura: so that concerns could be raised early enough to address them constructively and without unnecessary fallout 21:52:45 is it fair to say until we find consnsus we wont be able to merge GBP and alike? 21:52:56 is anyone here from Contrail/Juniper? 21:53:04 hi 21:53:04 honeslty from what I see we can keep discussing for months but we’ll never reach a 100% consensus 21:53:06 hi 21:53:07