20:02:52 #startmeeting tc 20:02:52 Meeting started Tue Jul 26 20:02:52 2016 UTC and is due to finish in 60 minutes. The chair is flaper87. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:02:53 * rockyg slinks into the back, drinking a smoothie 20:02:53 * edleafe tries to look cool hanging in the back 20:02:54 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:02:55 o/ 20:02:56 The meeting name has been set to 'tc' 20:03:02 * mordred agrees with joehuang - it was good to sit down in person ... although I have not yet produced my follow up email I said I would 20:03:20 rockyg: did you bring enough smoothies for everyone? 20:03:28 #topic Equal Integration Chances for all Projects ( mugsie ) 20:03:30 #link https://review.openstack.org/342366 20:03:34 to mordred :) 20:03:41 mugsie: floor is yours 20:04:03 mordred, Sure! You like tomato/mint/berry smoothies? 20:04:04 mugsie: if you're around, of course 20:04:06 :) 20:04:06 so, I proposed this (as a long term) way for us to move forward in the big tent 20:04:42 what's the topic now? 20:04:53 joehuang: Equal Integration Chances for all Projects 20:04:59 I think that if we are going to contiune in the big tent, we need to work on getting everyone equal oportunites for intergrating with horizontal teams 20:05:13 there has been a few emails about the issue 20:05:20 and some good reviews. 20:05:48 #link http://lists.openstack.org/pipermail/openstack-dev/2016-July/100007.html 20:05:48 I suppose the question is if the substantive aim of the motion is something we can work towards 20:06:09 #link http://lists.openstack.org/pipermail/openstack-dev/2016-July/099290.html 20:06:11 or if it is not really something people agree with 20:06:18 dhellmann: thanks for getting those links 20:06:27 yeap, thanks dhellmann 20:06:36 * mugsie should have had them ready 20:06:46 were those the only 2 threads? I actually lost track of how many different threads we've had... 20:06:50 is this openstack scientific work group? 20:06:51 I think so 20:06:56 dhellmann: I think it was just those 2 20:06:58 I don't disagree with the view of giving projects equal opportunities but perhaps the approach proposed in the resolution is not the right one 20:07:04 I think there was a third subject line on the tail of one of those threads 20:07:05 mtreinish : thanks 20:07:07 isunil: nope 20:07:16 Maybe a resolution itself is not the right first step forward 20:07:33 jroll : maybe you can find that one? 20:07:40 * jroll looks 20:07:43 mugsie: the issues you highlight there seem, to great extent, to be technical. Some of them (OSC) seem to be being worked on 20:07:49 maybe - I am just trying to find a way forward 20:08:00 so I like sharing the best practices between horizontal teams 20:08:21 dhellmann: "plugins for all" -> "Equal Chances for all projects" here: http://lists.openstack.org/pipermail/openstack-dev/2016-July/100007.html 20:08:22 we considered this case when we originally discussed the big tent, and we wanted to give the cross-project teams flexibility in addressing how they would work with other teams. So we said that they had to come up with something, but that something might be different for different levels of support. 20:08:27 jroll : thanks 20:08:29 yes, there is bugs, and yes they are being worked on, but to try and avoid them as we grow, i think something like htis in policy is a good thing 20:08:33 #link http://lists.openstack.org/pipermail/openstack-dev/2016-July/100007.html 20:08:35 jroll: thanks 20:08:38 np 20:08:56 I also think that part of the intent of the big tent was to give horizontal teams the freedom to figure out what pattern works for them, which this also rolls back 20:08:59 flaper87: that was dhellmann's first link :) 20:09:04 dhellmann: right, exactly that 20:09:14 most of the teams have put some sort of liaison system into place to address the coordination and contribution load issues 20:09:49 and the way you increase interactions between teams isn't policy, it's people stepping across fences and helping out 20:10:02 sdague: yes, that ++ 20:10:03 sdague++ 20:10:08 sdague: +1 20:10:12 and as I have said, I will do when the skills I have can help 20:10:15 sdague: indeed, that's why I think a resolution is not the right first step 20:10:22 so unless we have a situation where a team is refusing to cooperate at all, I don't think we want to start adding more rules on top 20:10:50 And even in that case, rules are not the first resort… 20:10:51 mugsie : yep, your commitment isn't in question 20:10:55 smaller project have had rules added to them to start using some of these projects 20:10:56 mugsie: identifying the issues is also a thing to do and you've helped there. I think highlighting those issue to each project would be a way to contribute 20:10:57 dtroyer : right 20:10:57 dtroyer: agreed 20:11:04 maybe I missed something in the email, but mugsie where are you hitting issues? 20:11:21 tempest, docs, grenade, osc, horizon 20:11:26 mtreinish: oops on the dupe link, I was thinking the "Big tent? (Related to Plugins for all)" was one of the first two mentioned 20:11:32 is the short list in my head from this cycle 20:11:35 no one has to use grenade 20:11:48 well, if we want to say we support upgrade, we basically 20:11:50 my life would be easier if less people did :) 20:11:51 It's not necessary (IMO) about increasing interaction between teams. That's never going to scale to big tent, it's, again IMO, about ensuring horizontal teams are building a core widget, which is used by the projects they support in the same way projects they don't support can use that widget. 20:11:51 + do 20:12:03 mugsie : having the cross-project teams document their expectations is to be expected. by "rules" do you mean things you consider too onerous? 20:12:41 dhellmann: no, it is when developers from the project I work on see and issue, try to fix itm and get a -2, saying that @$thing is not for plugins@ 20:12:57 * mugsie switches KB mapping 20:13:05 Kiall : all of the existing examples appear to already be doing that, to varying degrees of "finished" 20:13:39 dhellmann: but in each case, there is a special section that is reserved for "privaledged projects" 20:13:42 mugsie : that sounds like a discussion that needs to happen with the team in question, to understand how their interfaces work? 20:13:56 you keep using that word, but is it really "priviledged" or is it "not yet ported"? 20:14:17 well, i was told to stop using core :) 20:14:26 I'm starting to have an old-grandpa moment where this is reminding me of pre-integrated release days 20:14:26 mugsie: each team should work with you on understanding how the interface works, what solutions you have and we should go from there 20:14:32 is there a specific case we can look at? 20:14:33 mugsie : I understand your frustration, but you're coming at this presenting the issue as bad intent on the part of these other teams that I just don't see 20:14:46 mordred: yup 20:14:59 dhellmann: right, it's like when I show up to change things in oslo.context, and you tell me "well... actually you shouldn't do it this way", and I bounce off a couple of options before I find a workable one 20:15:06 dhellmann: yes, I think many are working that way, but it's so common that most of us smaller projects give up after a while and just use the APIs we aren't allowed to, or reimplement things. A formal policy helps keep this on the minds of everyone, and ensures over time we see this less and less. 20:15:20 but that's just what happens when you explore into unfamiliar territory that doesn't have every use case documented out with examples 20:15:23 (I'm on a cell, and typing real slow ;)) 20:15:25 docs. we are told to put docs in docs.o.o/developer/ which is not linked from docs.o.o for users 20:15:32 russellb: +1 20:15:45 docs is a good example, though that issue has been specifically discussed on list 20:15:51 mugsie : that's changing right? loquacities has described the experimentation they're doing with install guides, for example. 20:15:55 and, is evolving 20:15:55 which in turn causes issues for adoption, which makes getting to the main docs eve harder 20:15:56 i don't think a TC resolution helps that 20:16:00 mugsie: so thats a good specific, but I thought they are working on that 20:16:08 in one small area 20:16:08 random data point: ironic has been working through some of the same issues. and it *is* difficult to understand where the boundaries are and how everything works. but with enough talking to people, we've stumbled our way through it 20:16:10 FWIW, I think these issues are real but we should look at them individually. 20:16:10 by they, I mean us 20:16:17 flaper87: ++ 20:16:22 We as in OpenStack/TEams and not necessarily the TC itself 20:16:25 docs people are very focused on fixing these things, e.g. they just finished up making the install guide pluggable 20:16:27 no, we had a very production session in austin with the docs team getting to the point of allowing more teams to write guides using their tools. this is all in flux. 20:16:43 johnthetubaguy: 'one of us' :) 20:16:48 but they can't do everything at once, if someone wants to make it move faster, they need to jump in and help :/ 20:16:54 jroll : does that point to a need for more documentation on those "boundaries"? 20:16:54 jroll: right, and I think that's kind of the point. OpenStack is really big, and everyone runs into things like that when in unfamiliar teritory 20:16:57 I don't think moving forward with a resolution will help us solving issues that, as of now, seem to be mostly technical and (hopefully) solvable 20:17:09 flaper87: or, honestly, more social 20:17:15 sdague: that too 20:17:16 actually, this seems ot be a misconception - the timeline is not proposed in this motion 20:17:25 what jroll said, they are working on it 20:17:26 (time check: giving this topic 4 more mins) 20:17:29 and in no way do I think it should be in this cycle 20:17:38 flaper87: I think these are as much mindset as they are technical. But I've nothing to back that up bar my gut. 20:17:40 because I think there seems to be an expectation that the rest of openstack is a solved problem, without realizing the whole problem space is co-evolving 20:17:41 dhellmann: maybe, it might just be us trying to go between docs and code examples (which may or may not be doing it right) 20:17:52 if it was 1 or 2 - yes - do it on a case by case basis 20:17:59 sdague: amen 20:18:09 jroll : ok, I was looking for some sort of positive action we could recommend here 20:18:30 but as it is not, is seems to be a more overarchig problem, which would (in my mind) end up in the TC space 20:18:46 dhellmann: I think as more projects adopt these pluggable things, they should help others (e.g. I sit in -qa and try to help with devstack/grenade plugin questions if I can) 20:19:06 yeh, and jroll is super awesome with that. thanks for it. 20:19:08 mugsie : if we approved this resolution, what change would you expect to see as an outcome from that? 20:19:10 dhellmann: or file bugs / write docs if they aren't sufficient 20:19:12 and thank you for that jroll - i had been banging my head on a wall for a few days when you replied 20:19:16 jroll : ++ 20:19:43 sdague: mugsie: :) 20:20:02 ok, the time for this topic is almost over. I can write a summary for this discussion but I'd like to close it with an action item if possible 20:20:02 dhellmann: as we move forward over then next (x) cycles we would move all proects to plugins (or in tree) 20:20:19 flaper87: I honestly don;t think we are there yet 20:20:22 mugsie : ok. we have in each of these cases indicated why we do not want to do that, though. 20:20:26 mugsie: I think blanket statements like that aren't really useful 20:20:28 Among the issues mugsie listed, can we at least identify which ones the TC can help with and which ones should be discussed with the different communities? 20:20:49 mugsie: well, I'm not looking for a solution but a step forward for the discussion 20:20:53 I 20:21:01 (cell phone ;)) 20:21:05 mugsie: i'm curious who the "we" is you're volunteering to "move all proects to plugins (or in tree)" 20:21:08 it seems like most of the groups are working really hard on this already 20:21:19 mugsie : and the fact that we have those reasons, and they are different for each cross-project concern, and the solutions are therefore different, is why we did not have this "treat all projects the same way" policy to begin with 20:21:33 is there something we can do to ask for more help, or are there specific gaps that we should highlight here? 20:21:36 mugsie: it sounds like you're offering to show up with an army of new contributors to make your dream a reality 20:21:47 and this seems weird to me. if we are oving this way already in projects, why should we not have it in policy 20:21:47 it feels like all the key bits are moving forward right now 20:21:48 #info we need to identify what issues are being worked on and which ones should be discussed further with the TC or other teams 20:22:02 mugsie : because we are not moving to the place that your policy defines 20:22:23 flaper87 / mugsie I'd be interested in a poll of PTLs, assessing general agreement / disagreement with mugsie's resolution. Broken down by project size etc. I imagine that will shed light on if this is really a problem, or not 20:22:38 #action flaper87 to summarize the discussion on the review 20:22:44 we do not want all projects to be treated exactly the same way in all cases, because we want cross-project teams to have flexibility in what they sign up to "own" versus what they sign up to support others doing 20:22:54 i can do that 20:23:00 Kiall: ^ 20:23:05 dhellmann: ++ 20:23:06 Kiall: it's complicated, as a PTL I agree with mugsie's problem statement ("this is really hard right now"), but not the solution 20:23:13 Kiall: that would be fine data to collect, but I also expect you would find that everyone thinks things are a problem that are different problems 20:23:17 dhellmann: ++ 20:23:25 dhellmann: ++ 20:23:30 dhellmann: agree, docs can't write everyone's docs. 20:23:39 as an example, the vmt is very specific about which deliverables they support directly and which they merely provide consultation and recommendations for 20:23:50 i don't think that can be changed safely/sanely 20:23:57 that's another good example, fungi 20:24:07 But they can (as a medium to long term goal, which they are doing) ensure the tooling works from projects they manage, AND projects they don't by using the same APIs for both. 20:24:16 the way to solve these issues is to add more people to the *cross-project work* not just the siloed project work 20:24:32 Kiall: in the case of the vmt, that "api" is a group of people having conversations 20:24:32 dhellmann: ++ 20:24:33 Kiall: sometimes, and sometimes they have to evolve things 20:24:34 but, the vmt will not block a project based on when it was integrated / other metrics, just on the basis of a review, which will have actionalble changes a project can do to get supprt 20:24:34 Kiall : that is already documented as an expectation 20:25:02 and are activly moving in that direction 20:25:08 fungi: yea, some groups really are different. And the resolution likely needs updating to reflect that 20:25:31 +1 dhellmann, also I think its generally all a work in progress and happening 20:25:33 mugsie : which team is blocking you in that way? 20:25:51 in which way? getting in tree? 20:25:54 similarly, you can't demand that the i18n team start translating more projects just because they're big tent. they need to decide where makes the most sense to focus their limited labor force 20:26:09 mugsie : in whatever way you just implied by the "based on when it was integrated ..." statement 20:26:13 fungi: another good example 20:26:15 fungi: but you could ask them to allow all project into the transaltion system 20:26:24 mugsie : if you want to make a change-the-whole-world policy change, you need to be talking in more detail 20:26:28 and they can use that to translate themselves 20:26:35 ok, we need to move on as there are other topics to discuss 20:26:37 mugsie: they already allow that 20:26:45 fungi: agree, but the i18n tooling is open to all projects, and it's the same API used by all. Thus the problem mugsie's proposal is addressing doesn't exist 20:26:50 We'll bring this up again in the next meeting if necessary 20:26:51 so, htey wouodl be fine in this motion 20:27:26 flaper87 : +1 to moving on 20:27:29 mugsie: thanks a lot for your work there, as much as it might not look like it, I think we're moving somewhere 20:27:31 #topic Add project Tricircle to OpenStack big-tent ( joehuang ) 20:27:33 #link https://review.openstack.org/338796 (round 2) 20:27:53 So, we discussed this topic in our lsat meeting 20:28:12 There were different opinions and feedback on the proposal and by now many of them have been posted in the review already 20:28:29 joehuang: thanks again from joining us, we know this is a difficult hour in your TZ 20:28:34 some questions I asked in the comment now answered yet 20:28:38 joehuang: anything you'd like to share/say ? 20:28:48 thanks to flapper87 20:29:07 yes, I would like to express my opinion a little 20:29:11 joehuang: please do 20:29:25 Thanks Kyle to check the material based on guideline. I think -1 should be based on guideline, http://governance.openstack.org/reference/new-projects-requirements.html. So I can't accept other -1 for now, need more clarification on why -1 for other comment. There are already several projects with tag "single vendor", single vendor is also not the reason to stop a project joining the big-tent. 20:29:36 I'm super not thrilled by the proxy API nature of this... especially as we've been deprecating the API proxies in Nova over this cycle 20:30:20 which api proxy, you mean cells API proxy? 20:30:26 sdague: +1 20:30:34 joehuang : I'm not sure anyone is arguing your team has not followed the 4 opens. The objections I'm seeing are related to questions about whether "The project aligns with the OpenStack Mission" 20:30:54 to dhellmann 20:31:03 * jroll <3 flaper87's review on this 20:31:16 so I asked question in ttx's comment, 20:31:25 mordred you had a discussion f2f with joehuang a couple of weeks ago, right. Anything you want/can share? 20:31:31 jroll: <3 20:31:38 I've written adn deleted like 12 things since this topic started :) 20:31:38 i think this fundamentally changes nearly all OpenStack APIs and gives them 2 very different ways they may work, and i'm not convinced that's a good direction we should take 20:31:43 can't figure out how the Tricircle will harmfully dilute an OpenStack cloud and hurt the mission, could you help me to point out more concretely, for example from technology, scenario, use case, etc aspect? From my understanding, the Tricircle will address four use cases listed in the communication material: 20:31:48 mordred: lol 20:31:52 mordred: take your time 20:31:52 overall, i'd like to see stronger consensus around this before making it official in any way 20:32:11 To get more consensus is a good proposal, The Tricircle has already been developed under the "four open" guidelines, and discussed/reviewed almost one year in the design, not received objection during the development. When we talk about the "get consensus", I would like to know what's the process is, and what's the criteria, so that we have a target to strive for. 20:32:27 i've rejected plenty in the past :) 20:32:29 I'm also not sure that the current proxy approach is the right one, and thingee and I chatted with joehuang a little bit about that. but that's an impl detail and one that can be worked on over time 20:32:29 joehuang: I posted another comment on the review, but I think russellb summarized my thoughts quite well 20:32:32 joehuang : we are working very hard to establish a single openstack API even among the existing projects so that we can have deployment interoperability. Tricircle is a proxy layer on top of that with subtle differences, which means it is yet another API. That dilutes the mission. 20:32:45 I think what's more important is the intent of the team and what they are trying to accomplish 20:32:53 i have absolutely no problem with the project existing, no need to object to that ... i just don't think it should be an official project 20:32:58 and whether that intent is in keeping with our mission or not 20:33:17 Just objection is easy, I would like to hear your proposal how to address the use cases mentioned in the reference material[1], if no new proposal to address these issues as, I would recommend to add Tricircle as incubation project. A compromise proposal is to restore incubation project type for Tricircle, or add an incubation tag in big-tent project. 20:33:32 there's no such thing as "incubation project" 20:33:32 dhellmann: ++ 20:33:50 If just objection is enough, then no consensus can be achieved no matter what proposal is given, because any one can just put -1 without concrete reason based on guideline for governance area. 20:34:02 joehuang: the fact that no one has objected so far does not mean that everyone agrees with the approach you've taken. as ttx points out in his comment, this is a significant architectural decision for the community. 20:34:04 impl details aside, tricircle is working on cross-cloud use cases, and ways of making certain complex cross-cloud use cases work better for end users 20:34:05 I'd feel more comfortable letting the project in the tent if there would be more discussions on the topic mostly because it's a difficult topic to address and I think it could definitely use a wider audience 20:34:20 joehuang: I don't think anyone is placing -1's without reason 20:34:31 to mordred: ++ 20:34:31 mordred: sure, but i do think the architecure matters too 20:34:37 I suggested when we were meeting that it might be worthwhile considering a completely new api that is focused on those use cases, and promised joehuang I would send him an email with a write up of more specific thoughts there 20:34:45 and there are fundamental objections to the approach at the most basic level ... 20:34:52 mordred: sure, but there are other efforts as well, like the federated cloud work from the umass folks 20:35:00 russellb: I do not think architecture matters, actually. not for big tent inclusion. but that's just my opinion and I respect alternate ones 20:35:23 sdague: sure there are, but the umass folks have not requested big tent inclusion and tricircle has 20:35:41 mordred : I don't think we want to have to deal with questions like "which version of the official openstack api do you mean?" 20:35:42 #info there's no objection to the technical merits and details of the project but rather on the timing of the proposal and its implications community wise 20:35:48 dhellmann: ++ 20:35:50 * flaper87 hopes that's a good first/partial summary 20:35:53 dhellmann: I do not think that is the question we're asking or answering here 20:36:02 flaper87: i object to the technical merits and details of the project 20:36:06 nobody at any point in time has said anything about tricircle being a part of DefCore 20:36:09 mordred : I think that is the question we will be asked if we start accepting projects like tricircle 20:36:22 to make the archi WG get consensus, 20:36:24 flaper87: I also object to the proxy nature 20:36:25 russellb: in general or as a part of tent ? 20:36:31 both? 20:36:36 I meant that as part of the evaluation but it's fair 20:36:39 #undo 20:36:40 mordred: I don't think that defcore is the be-all-end-all definition of the list of projects for which people will ask that question. 20:36:40 Removing item from minutes: 20:36:43 bom 20:36:44 :D 20:36:50 it's good to include tricircle in the big-tent with incubation tag 20:36:55 because I think that's the gratuitous overlap 20:36:55 given we don't like competing projects (missions?), the architecture does matter, right? or else we'll end up not accepting other valid multi-region scaling things? 20:36:56 there's no such thing as incubation 20:37:03 joehuang : we do not have a tag like that 20:37:06 s/valid/better/ even? 20:37:07 dhellmann: right. but I don't think adding something to the big tent adds a level of officianess to its api 20:37:16 like, literally that's the opposite of what we did with big tent 20:37:31 mordred : we call big tent projects "official projects" 20:37:38 jroll: the amount i care about competing/overlapping projects depends on the layer of the stack ... i care for keystone ... i don't care about deployment projects, for example 20:37:39 mordred: that is not how many outside this group interpret the big tent 20:37:44 dtroyer : ++ 20:37:46 to dhellmann, good 20:37:48 mordred: and we are putting up official API docs now 20:37:50 dtroyer: sure. that means we have failed at educating them 20:37:52 sure 20:38:06 russellb: sure, but we like to say there's on compute/identity/etc API, would we want multiple multi-region-control APIs? 20:38:06 mordred: maybe, but we don't have any other way to differentiate an apis officialness. If it's in the big tent it kinda means that 20:38:09 will having tricircle in the big tent affect how we look at the umass project if they later apply for inclusion? 20:38:20 ok. listen. I get all of those arguements. but if we want to start judging projects based on the technical merits of their current implementation, then we need to change this process 20:38:24 that is not what this is currently 20:38:26 i thought that the big tent was supposed to stop TC doing arch review of projects? 20:38:29 jroll: i would put this int he category of "strongly object to overlap/competition" category, yes 20:38:32 no matter who thinks it is erroneuously 20:38:38 russellb: ++ 20:38:45 russellb: right, that's the point I'm trying to make 20:38:48 k :) 20:38:51 :) 20:38:52 to mordred +1 20:39:00 mordred : I'm not making a technical judgement here. I'm saying that adding a second version of a nova API to openstack as an official project is a bad idea because it confuses things. It doesn't matter how that API is implemented. 20:39:27 dhellmann: right. which is one of the reasons I was suggesting to joehuang that we talk about different apis for tricircle 20:39:36 sounds like a great discussion 20:39:54 that's how to governance tricricle will not make deviation on api 20:39:56 which may mean we need to defer making a call on this right now ... I just want to make sure if we reject or defer we're doing it for the right reasons 20:39:59 mordred : ok, cool. I look forward to being a fly on the wall for that. 20:40:02 this is the cnace to get a single (appearing) aPI done 'right' fixing all the things we've learned in 6 years 20:40:08 so go do that 20:40:12 I propose Nova/Cinder team can govern the tricircle api gw 20:40:32 dtroyer : shoot, if we could get the API right I'd support having something like this replace all of our existing apis :-) 20:40:44 joehuang: do the nova/cinder teams want that responsiblity? 20:40:44 well, you know right for a week 20:40:47 dhellmann: heh, +1 20:40:52 then it would be wrong again 20:41:00 when the first new use case showed up :) 20:41:01 dhellmann: maybe in 6 more years it would… but that's what I hear mordred suggeesting, and I think is the right approach for this sort of thing 20:41:09 sdague : humbug 20:41:10 sdague: and then right again 5 years later :) 20:41:26 at stopped API is right twice a decade? 20:41:28 the use cases are quite new 20:41:36 dhellmann: right. that's sort of exactly what I'm saying the effort here is _really_ wanting to do - but the team doing it is trying their best to play nicely with everyone 20:41:39 sdague : ++ 20:41:50 I don't know how deep the new use cases have been discussed in the past 6 years 20:41:54 gah 20:41:55 mordred : I appreciate and am not questioning that in any way 20:41:57 I mean dtroyer 20:42:43 please look at the use case2 from the finiacial segements 20:42:43 mordred: ok, well my experience is quite different there. Because the umass folks show up and talk with (at least the nova team) through issues, and have been for the past 2 years (summits and midcycles), which has not been true here 20:43:05 sdague: this is quite different than what they're trying to do 20:43:43 sdague: this is a thing which actually understands all of your cloudregionzones, which is not a construct which exists anywhere in openstack, as openstack regions are completey independent sharednothing entities at the moment 20:43:46 mordred: that's fine, I just want to characterize the level of collaboration I've seen 20:43:52 sdague: totally 20:43:55 sdague: well, this is just trying to duplicate the nova API as a proxy, there aren't hard technical problems to work out with the nova team, right? 20:44:05 it's just pick a nova and pass the request 20:44:19 to mordred, multi-regions don't work for these use cases 20:44:20 jroll: what about when nova's are at different versions 20:44:28 Do we agree that we should defer the inclusion of Tricircle and encourage the team to work with the rest of the community on improving/discussing the approach taken on this issue? 20:44:36 flaper87 : +1 20:44:38 flaper87: +1 20:44:43 I think that's what the vote looks like now 20:44:46 flaper87: +1 20:44:49 so, not a rejection, but a deferral 20:44:53 flaper87: I will volunteer to work further with joehuang 20:45:03 mordred: awesome! Thanks <3 20:45:09 (which may actually look like a rejection in the short term if we abandon this specific review) 20:45:13 to mordred: thanks 20:45:15 sdague: doesn't seem like they intend to solve that now (microversions don't exist in tricircle), but I think we digress 20:45:19 as I think that the work the team is doing is valuable, but currently not structured in a way the rest of the community is well positoined to accept 20:45:19 #action mordred will follow-up with joehuang to help the Tricircle team move forward 20:45:25 mordred : +1 20:45:35 mordred: is that action item fair? Want me to change it? 20:45:36 sdague: good point though 20:45:39 mordred: +1 20:45:41 microversion support is listed in our agenda 20:45:42 flaper87: it's great 20:45:58 awesome 20:46:15 I owe like 10 different people writeups on like 10 different topics, so step one with joehuang may take a few weeks, and I apologize for that speed 20:46:18 joehuang: thanks a bunch again for joining and I do hope you all will continue working on what you're doing 20:46:44 mordred : you need some interns or something 20:46:48 As a final note, joehuang, this is a deferral and not a rejection! Looking forward to the future proposal 20:46:54 to mordred and flaper87: ok 20:46:56 :) 20:46:57 he needs clones :) 20:47:00 ok, let's move on 20:47:02 dhellmann: then I'd have to tell the interns what to do, which would involve me writing up thoughts for them :) 20:47:06 * rockyg hands mordred an honarary tricircle member badge, and a rose 20:47:12 jroll: no, no clones 20:47:14 #topic Update thresholds for active reviewers ( flaper87 ) 20:47:15 #link https://review.openstack.org/337853 and clarify what an active (core) reviewer is 20:47:17 #link https://review.openstack.org/342225 20:47:27 anteaya: the more mordreds the merrier :D 20:47:31 to flaper87, could you comment on the review for "defer but not rejection" 20:47:33 no, no, no 20:47:36 one is more than enough 20:47:39 hehe 20:47:49 So, I kept the second link in the topic just to say that I'd prefer to talk about that one later :D 20:47:53 flaper87 : mordred mentioned doing something with standard deviations, too, did you look at what impact that would have over a simple %? 20:47:59 or is that the more dreds the merrier? 20:48:04 I'd love for us to focus on this one https://review.openstack.org/337853 20:48:14 thank you, I have to sleep now :) 20:48:14 dhellmann: I did not, tbh 20:48:18 dhellmann: but I could 20:48:21 flaper87 : ok, just checking 20:48:39 I'm curious, but I don't know what actually makes sense here 20:48:46 So, this is another split of the original proposal and it focuses on the changes to the teamstats.py script we use 20:49:24 we have majority already 20:49:30 I wonder if there are other questions 20:49:37 so, i theory, if a team had 4 cores, the minimum level for an active reviewer wouold be closer to 15%, right? 20:49:51 (based on each patch needing 2 +2's) 20:50:24 * flaper87 tries to do the math in his head but it's passed the math hour in his TZ 20:50:25 and if it had 3 cores, it would be ~ 30% 20:50:25 :P 20:50:33 mugsie : if you have 4 folks and one is very slack, the effort goes up for the others. that's one reason for looking into standard deviations, I guess. 20:50:37 * amrith scratches his head on that math 20:50:38 mugsie: that's sort of why I was origianlly musing about standard deviations 20:50:42 yeah 20:50:47 it's harder math of course 20:50:55 yeah, that's what I was just thinking too. It kinda depends on the number of reviews and the number of cores to be fair 20:50:56 its just the 2% rule seems ... low 20:50:59 mordred: bring in numpy :) 20:51:03 :D 20:51:08 mordred : in python 3 it's a function call: https://docs.python.org/3.5/library/statistics.html#statistics.pstdev 20:51:27 * flaper87 stores that link 20:51:29 or https://docs.python.org/3.5/library/statistics.html#statistics.stdev 20:51:41 or someone who actually knows that math could find the right function :-) 20:51:42 * amrith thinks we should define what we want to accomplish before getting bogged down in the math functions 20:51:56 flaper87: so... what changed after this add? 20:52:07 like which projects moved across a line? 20:52:15 amrith: we're trying to make it so that teams that let core members "linger" even when they are not active do not benefit in terms of appearing to be diverse 20:52:23 dhellmann: you are a walking encyclopedia of python 20:52:28 sdague: mostly not visible changes as some projects got closer to the line 20:52:31 dhellmann, in truth, this commit doesn't do that. 20:52:42 mordred : it comes in print and all major ebook formats... 20:52:42 amrith: yeah. thats a good question - i may have missed a meeting thought - why do we need a definition of an active reviewer? is there teams suffing cores to get diversity? 20:52:44 flaper87: ok, which projects had the biggest drift? 20:52:54 that might help validate if this feels fine 20:52:55 mugsie : not "stuffing" no 20:53:00 sdague: telemetry is one example 20:53:22 sdague: it's in the edge of missing the diversity tag 20:53:42 yeah, I stayed on the core team there way longer than I should have and that skewed their diversity stats for a while 20:53:53 mugsie: there are some projects that don't ever clean up old non-active cores so they look like they've got more active core teams than they actually do 20:54:01 mugsie: good example from dhellmann 20:54:10 flaper87: ok, that seems valid then 20:54:12 did we try 5%? 20:54:28