20:02:52 <flaper87> #startmeeting tc
20:02:52 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:02:55 <mugsie> o/
20:02:56 <openstack> 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 <mordred> rockyg: did you bring enough smoothies for everyone?
20:03:28 <flaper87> #topic Equal Integration Chances for all Projects ( mugsie )
20:03:30 <flaper87> #link https://review.openstack.org/342366
20:03:34 <joehuang> to mordred :)
20:03:41 <flaper87> mugsie: floor is yours
20:04:03 <rockyg> mordred, Sure!  You like tomato/mint/berry smoothies?
20:04:04 <flaper87> mugsie: if you're around, of course
20:04:06 <flaper87> :)
20:04:06 <mugsie> so, I proposed this (as a long term) way for us to move forward in the big tent
20:04:42 <joehuang> what's the topic now?
20:04:53 <flaper87> joehuang: Equal Integration Chances for all Projects
20:04:59 <mugsie> 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 <mugsie> there has been a few emails about the issue
20:05:20 <mugsie> and some good reviews.
20:05:48 <dhellmann> #link http://lists.openstack.org/pipermail/openstack-dev/2016-July/100007.html
20:05:48 <mugsie> I suppose the question is if the substantive aim of the motion is something we can work towards
20:06:09 <dhellmann> #link http://lists.openstack.org/pipermail/openstack-dev/2016-July/099290.html
20:06:11 <mugsie> or if it is not really something people agree with
20:06:18 <flaper87> dhellmann: thanks for getting those links
20:06:27 <mugsie> yeap, thanks dhellmann
20:06:36 * mugsie should have had them ready
20:06:46 <dhellmann> were those the only 2 threads? I actually lost track of how many different threads we've had...
20:06:50 <isunil> is this openstack scientific work group?
20:06:51 <mugsie> I think so
20:06:56 <mtreinish> dhellmann: I think it was just those 2
20:06:58 <flaper87> 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 <jroll> I think there was a third subject line on the tail of one of those threads
20:07:05 <dhellmann> mtreinish : thanks
20:07:07 <Kiall> isunil: nope
20:07:16 <flaper87> Maybe a resolution itself is not the right first step forward
20:07:33 <dhellmann> jroll : maybe you can find that one?
20:07:40 * jroll looks
20:07:43 <flaper87> 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 <mugsie> maybe - I am just trying to find a way forward
20:08:00 <johnthetubaguy> so I like sharing the best practices between horizontal teams
20:08:21 <jroll> dhellmann: "plugins for all" -> "Equal Chances for all projects" here: http://lists.openstack.org/pipermail/openstack-dev/2016-July/100007.html
20:08:22 <dhellmann> 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 <dhellmann> jroll : thanks
20:08:29 <mugsie> 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 <flaper87> #link http://lists.openstack.org/pipermail/openstack-dev/2016-July/100007.html
20:08:35 <flaper87> jroll: thanks
20:08:38 <jroll> np
20:08:56 <sdague> 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 <mtreinish> flaper87: that was dhellmann's first link :)
20:09:04 <sdague> dhellmann: right, exactly that
20:09:14 <dhellmann> most of the teams have put some sort of liaison system into place to address the coordination and contribution load issues
20:09:49 <sdague> and the way you increase interactions between teams isn't policy, it's people stepping across fences and helping out
20:10:02 <mtreinish> sdague: yes, that ++
20:10:03 <jroll> sdague++
20:10:08 <johnthetubaguy> sdague: +1
20:10:12 <mugsie> and as I have said, I will do when the skills I have can help
20:10:15 <flaper87> sdague: indeed, that's why I think a resolution is not the right first step
20:10:22 <dhellmann> 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 <dtroyer> And even in that case, rules are not the first resort…
20:10:51 <dhellmann> mugsie : yep, your commitment isn't in question
20:10:55 <mugsie> smaller project have had rules added to them to start using some of these projects
20:10:56 <flaper87> 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 <dhellmann> dtroyer : right
20:10:57 <sdague> dtroyer: agreed
20:11:04 <johnthetubaguy> maybe I missed something in the email, but mugsie where are you hitting issues?
20:11:21 <mugsie> tempest, docs, grenade, osc, horizon
20:11:26 <jroll> 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 <mugsie> is the short list in my head from this cycle
20:11:35 <sdague> no one has to use grenade
20:11:48 <mugsie> well, if we want to say we support upgrade, we basically
20:11:50 <sdague> my life would be easier if less people did :)
20:11:51 <Kiall> 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 <mugsie> + do
20:12:03 <dhellmann> 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 <mugsie> 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 <dhellmann> Kiall : all of the existing examples appear to already be doing that, to varying degrees of "finished"
20:13:39 <mugsie> dhellmann: but in each case, there is a special section that is reserved for "privaledged projects"
20:13:42 <dhellmann> mugsie : that sounds like a discussion that needs to happen with the team in question, to understand how their interfaces work?
20:13:56 <dhellmann> you keep using that word, but is it really "priviledged" or is it "not yet ported"?
20:14:17 <mugsie> well, i was told to stop using core :)
20:14:26 <mordred> I'm starting to have an old-grandpa moment where this is reminding me of pre-integrated release days
20:14:26 <flaper87> 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 <russellb> is there a specific case we can look at?
20:14:33 <dhellmann> 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 <mugsie> mordred: yup
20:14:59 <sdague> 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 <Kiall> 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 <sdague> 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 <Kiall> (I'm on a cell, and typing real slow ;))
20:15:25 <mugsie> docs. we are told to put docs in docs.o.o/developer/<project> which is not linked from docs.o.o for users
20:15:32 <johnthetubaguy> russellb: +1
20:15:45 <russellb> docs is a good example, though that issue has been specifically discussed on list
20:15:51 <dhellmann> mugsie : that's changing right? loquacities has described the experimentation they're doing with install guides, for example.
20:15:55 <sdague> and, is evolving
20:15:55 <mugsie> which in turn causes issues for adoption, which makes getting to the main docs eve harder
20:15:56 <russellb> i don't think a TC resolution helps that
20:16:00 <johnthetubaguy> mugsie: so thats a good specific, but I thought they are working on that
20:16:08 <mugsie> in one small area
20:16:08 <jroll> 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 <flaper87> FWIW, I think these issues are real but we should look at them individually.
20:16:10 <johnthetubaguy> by they, I mean us
20:16:17 <russellb> flaper87: ++
20:16:22 <flaper87> We as in OpenStack/TEams and not necessarily the TC itself
20:16:25 <jroll> docs people are very focused on fixing these things, e.g. they just finished up making the install guide pluggable
20:16:27 <dhellmann> 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 <mtreinish> johnthetubaguy: 'one of us' :)
20:16:48 <jroll> 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 <dhellmann> jroll : does that point to a need for more documentation on those "boundaries"?
20:16:54 <sdague> 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 <flaper87> 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 <sdague> flaper87: or, honestly, more social
20:17:15 <flaper87> sdague: that too
20:17:16 <mugsie> actually, this seems ot be a misconception - the timeline is not proposed in this motion
20:17:25 <johnthetubaguy> what jroll said, they are working on it
20:17:26 <flaper87> (time check: giving this topic 4 more mins)
20:17:29 <mugsie> and in no way do I think it should be in this cycle
20:17:38 <Kiall> 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 <sdague> 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 <jroll> 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 <mugsie> if it was 1 or 2 - yes - do it on a case by case basis
20:17:59 <flaper87> sdague: amen
20:18:09 <dhellmann> jroll : ok, I was looking for some sort of positive action we could recommend here
20:18:30 <mugsie> 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 <jroll> 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 <sdague> yeh, and jroll is super awesome with that. thanks for it.
20:19:08 <dhellmann> mugsie : if we approved this resolution, what change would you expect to see as an outcome from that?
20:19:10 <jroll> dhellmann: or file bugs / write docs if they aren't sufficient
20:19:12 <mugsie> 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 <dhellmann> jroll : ++
20:19:43 <jroll> sdague: mugsie: :)
20:20:02 <flaper87> 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 <mugsie> dhellmann: as we move forward over then next (x) cycles we would move all proects to plugins (or in tree)
20:20:19 <mugsie> flaper87: I honestly don;t think we are there yet
20:20:22 <dhellmann> mugsie : ok. we have in each of these cases indicated why we do not want to do that, though.
20:20:26 <sdague> mugsie: I think blanket statements like that aren't really useful
20:20:28 <flaper87> 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 <flaper87> mugsie: well, I'm not looking for a solution but a step forward for the discussion
20:20:53 <Kiall> I
20:21:01 <Kiall> (cell phone ;))
20:21:05 <fungi> mugsie: i'm curious who the "we" is you're volunteering to "move all proects to plugins (or in tree)"
20:21:08 <johnthetubaguy> it seems like most of the groups are working really hard on this already
20:21:19 <dhellmann> 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 <johnthetubaguy> is there something we can do to ask for more help, or are there specific gaps that we should highlight here?
20:21:36 <fungi> 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 <mugsie> 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 <johnthetubaguy> it feels like all the key bits are moving forward right now
20:21:48 <flaper87> #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 <dhellmann> mugsie : because we are not moving to the place that your policy defines
20:22:23 <Kiall> 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 <flaper87> #action flaper87 to summarize the discussion on the review
20:22:44 <dhellmann> 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 <mugsie> i can do that
20:23:00 <mugsie> Kiall: ^
20:23:05 <flaper87> dhellmann: ++
20:23:06 <jroll> 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 <sdague> 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 <johnthetubaguy> dhellmann: ++
20:23:25 <sdague> dhellmann: ++
20:23:30 <Kiall> dhellmann: agree, docs can't write everyone's docs.
20:23:39 <fungi> 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 <fungi> i don't think that can be changed safely/sanely
20:23:57 <dhellmann> that's another good example, fungi
20:24:07 <Kiall> 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 <dhellmann> 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 <fungi> Kiall: in the case of the vmt, that "api" is a group of people having conversations
20:24:32 <anteaya> dhellmann: ++
20:24:33 <sdague> Kiall: sometimes, and sometimes they have to evolve things
20:24:34 <mugsie> 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 <dhellmann> Kiall : that is already documented as an expectation
20:25:02 <mugsie> and are activly moving in that direction
20:25:08 <Kiall> fungi: yea, some groups really are different. And the resolution likely needs updating to reflect that
20:25:31 <johnthetubaguy> +1 dhellmann, also I think its generally all a work in progress and happening
20:25:33 <dhellmann> mugsie : which team is blocking you in that way?
20:25:51 <mugsie> in which way? getting in tree?
20:25:54 <fungi> 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 <dhellmann> mugsie : in whatever way you just implied by the "based on when it was integrated ..." statement
20:26:13 <flaper87> fungi: another good example
20:26:15 <mugsie> fungi: but you could ask them to allow all project into the transaltion system
20:26:24 <dhellmann> mugsie : if you want to make a change-the-whole-world policy change, you need to be talking in more detail
20:26:28 <mugsie> and they can use that to translate themselves
20:26:35 <flaper87> ok, we need to move on as there are other topics to discuss
20:26:37 <fungi> mugsie: they already allow that
20:26:45 <Kiall> 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 <flaper87> We'll bring this up again in the next meeting if necessary
20:26:51 <mugsie> so, htey wouodl be fine in this motion
20:27:26 <dhellmann> flaper87 : +1 to moving on
20:27:29 <flaper87> 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 <flaper87> #topic Add project Tricircle to OpenStack big-tent ( joehuang )
20:27:33 <flaper87> #link https://review.openstack.org/338796 (round 2)
20:27:53 <flaper87> So, we discussed this topic in our lsat meeting
20:28:12 <flaper87> 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 <flaper87> joehuang: thanks again from joining us, we know this is a difficult hour in your TZ
20:28:34 <joehuang> some questions I asked in the comment now answered yet
20:28:38 <flaper87> joehuang: anything you'd like to share/say ?
20:28:48 <joehuang> thanks to flapper87
20:29:07 <joehuang> yes, I would like to express my opinion a little
20:29:11 <flaper87> joehuang: please do
20:29:25 <joehuang> 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 <sdague> 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 <joehuang> which api proxy, you mean cells API proxy?
20:30:26 <johnthetubaguy> sdague: +1
20:30:34 <dhellmann> 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 <joehuang> to dhellmann
20:31:03 * jroll <3 flaper87's review on this
20:31:16 <joehuang> so I asked question in ttx's comment,
20:31:25 <flaper87> mordred you had a discussion f2f with joehuang a couple of weeks ago, right. Anything you want/can share?
20:31:31 <flaper87> jroll: <3
20:31:38 <mordred> I've written adn deleted like 12 things since this topic started :)
20:31:38 <russellb> 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 <joehuang> 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 <flaper87> mordred: lol
20:31:52 <flaper87> mordred: take your time
20:31:52 <russellb> overall, i'd like to see stronger consensus around this before making it official in any way
20:32:11 <joehuang> 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 <russellb> i've rejected plenty in the past :)
20:32:29 <mordred> 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 <mestery> joehuang: I posted another comment on the review, but I think russellb summarized my thoughts quite well
20:32:32 <dhellmann> 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 <mordred> I think what's more important is the intent of the team and what they are trying to accomplish
20:32:53 <russellb> 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 <mordred> and whether that intent is in keeping with our mission or not
20:33:17 <joehuang> 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 <russellb> there's no such thing as "incubation project"
20:33:32 <sdague> dhellmann: ++
20:33:50 <joehuang> 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 <dhellmann> 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 <mordred> 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 <flaper87> 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 <edleafe> joehuang: I don't think anyone is placing -1's without reason
20:34:31 <joehuang> to mordred: ++
20:34:31 <russellb> mordred: sure, but i do think the architecure matters too
20:34:37 <mordred> 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 <russellb> and there are fundamental objections to the approach at the most basic level ...
20:34:52 <sdague> mordred: sure, but there are other efforts as well, like the federated cloud work from the umass folks
20:35:00 <mordred> 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 <mordred> sdague: sure there are, but the umass folks have not requested big tent inclusion and tricircle has
20:35:41 <dhellmann> 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 <flaper87> #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 <sdague> dhellmann: ++
20:35:50 * flaper87 hopes that's a good first/partial summary
20:35:53 <mordred> dhellmann: I do not think that is the question we're asking or answering here
20:36:02 <russellb> flaper87: i object to the technical merits and details of the project
20:36:06 <mordred> nobody at any point in time has said anything about tricircle being a part of DefCore
20:36:09 <dhellmann> mordred : I think that is the question we will be asked if we start accepting projects like tricircle
20:36:22 <joehuang> to make the archi WG get consensus,
20:36:24 <sdague> flaper87: I also object to the proxy nature
20:36:25 <flaper87> russellb: in general or as a part of tent ?
20:36:31 <russellb> both?
20:36:36 <flaper87> I meant that as part of the evaluation but it's fair
20:36:39 <flaper87> #undo
20:36:40 <dhellmann> 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 <openstack> Removing item from minutes: <ircmeeting.items.Info object at 0x7f5bbfbb3a10>
20:36:43 <flaper87> bom
20:36:44 <flaper87> :D
20:36:50 <joehuang> it's good to include tricircle in the big-tent with incubation tag
20:36:55 <sdague> because I think that's the gratuitous overlap
20:36:55 <jroll> 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 <russellb> there's no such thing as incubation
20:37:03 <dhellmann> joehuang : we do not have a tag like that
20:37:06 <jroll> s/valid/better/ even?
20:37:07 <mordred> dhellmann: right. but I don't think adding something to the big tent adds a level of officianess to its api
20:37:16 <mordred> like, literally that's the opposite of what we did with big tent
20:37:31 <dhellmann> mordred : we call big tent projects "official projects"
20:37:38 <russellb> 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 <dtroyer> mordred: that is not how many outside this group interpret the big tent
20:37:44 <dhellmann> dtroyer : ++
20:37:46 <joehuang> to dhellmann, good
20:37:48 <sdague> mordred: and we are putting up official API docs now
20:37:50 <mordred> dtroyer: sure. that means we have failed at educating them
20:37:52 <mordred> sure
20:38:06 <jroll> 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 <mtreinish> 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 <edleafe> will having tricircle in the big tent affect how we look at the umass project if they later apply for inclusion?
20:38:20 <mordred> 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 <mordred> that is not what this is currently
20:38:26 <mugsie> i thought that the big tent was supposed to stop TC doing arch review of projects?
20:38:29 <russellb> jroll: i would put this int he category of "strongly object to overlap/competition" category, yes
20:38:32 <mordred> no matter who thinks it is erroneuously
20:38:38 <sdague> russellb: ++
20:38:45 <jroll> russellb: right, that's the point I'm trying to make
20:38:48 <russellb> k :)
20:38:51 <jroll> :)
20:38:52 <joehuang> to mordred +1
20:39:00 <dhellmann> 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 <mordred> dhellmann: right. which is one of the reasons I was suggesting to joehuang that we talk about different apis for tricircle
20:39:36 <russellb> sounds like a great discussion
20:39:54 <joehuang> that's how to governance tricricle will not make deviation on api
20:39:56 <mordred> 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 <dhellmann> mordred : ok, cool. I look forward to being a fly on the wall for that.
20:40:02 <dtroyer> 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 <dtroyer> so go do that
20:40:12 <joehuang> I propose Nova/Cinder team can govern the tricircle api gw
20:40:32 <dhellmann> 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 <anteaya> joehuang: do the nova/cinder teams want that responsiblity?
20:40:44 <sdague> well, you know right for a week
20:40:47 <jroll> dhellmann: heh, +1
20:40:52 <sdague> then it would be wrong again
20:41:00 <sdague> when the first new use case showed up :)
20:41:01 <dtroyer> 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 <dhellmann> sdague : humbug
20:41:10 <mtreinish> sdague: and then right again 5 years later :)
20:41:26 <sdague> at stopped API is right twice a decade?
20:41:28 <joehuang> the use cases are quite new
20:41:36 <mordred> 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 <dhellmann> sdague : ++
20:41:50 <joehuang> I don't know how deep the new use cases have been discussed in the past 6 years
20:41:54 <mordred> gah
20:41:55 <dhellmann> mordred : I appreciate and am not questioning that in any way
20:41:57 <mordred> I mean dtroyer
20:42:43 <joehuang> please look at the use case2 from the finiacial segements
20:42:43 <sdague> 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 <mordred> sdague: this is quite different than what they're trying to do
20:43:43 <mordred> 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 <sdague> mordred: that's fine, I just want to characterize the level of collaboration I've seen
20:43:52 <mordred> sdague: totally
20:43:55 <jroll> 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 <jroll> it's just pick a nova and pass the request
20:44:19 <joehuang> to mordred, multi-regions don't work for these use cases
20:44:20 <sdague> jroll: what about when nova's are at different versions
20:44:28 <flaper87> 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 <dhellmann> flaper87 : +1
20:44:38 <sdague> flaper87: +1
20:44:43 <sdague> I think that's what the vote looks like now
20:44:46 <mestery> flaper87: +1
20:44:49 <dhellmann> so, not a rejection, but a deferral
20:44:53 <mordred> flaper87: I will volunteer to work further with joehuang
20:45:03 <flaper87> mordred: awesome! Thanks <3
20:45:09 <dhellmann> (which may actually look like a rejection in the short term if we abandon this specific review)
20:45:13 <joehuang> to mordred: thanks
20:45:15 <jroll> 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 <mordred> 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 <flaper87> #action mordred will follow-up with joehuang to help the Tricircle team move forward
20:45:25 <dhellmann> mordred : +1
20:45:35 <flaper87> mordred: is that action item fair? Want me to change it?
20:45:36 <jroll> sdague: good point though
20:45:39 <sdague> mordred: +1
20:45:41 <joehuang> microversion support is listed in our agenda
20:45:42 <mordred> flaper87: it's great
20:45:58 <flaper87> awesome
20:46:15 <mordred> 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 <flaper87> joehuang: thanks a bunch again for joining and I do hope you all will continue working on what you're doing
20:46:44 <dhellmann> mordred : you need some interns or something
20:46:48 <flaper87> As a final note, joehuang, this is a deferral and not a rejection! Looking forward to the future proposal
20:46:54 <joehuang> to mordred and flaper87: ok
20:46:56 <joehuang> :)
20:46:57 <jroll> he needs clones :)
20:47:00 <flaper87> ok, let's move on
20:47:02 <mordred> 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 <anteaya> jroll: no, no clones
20:47:14 <flaper87> #topic Update thresholds for active reviewers ( flaper87 )
20:47:15 <flaper87> #link https://review.openstack.org/337853 and clarify what an active (core) reviewer is
20:47:17 <flaper87> #link https://review.openstack.org/342225
20:47:27 <jroll> anteaya: the more mordreds the merrier :D
20:47:31 <joehuang> to flaper87, could you comment on the review for "defer but not rejection"
20:47:33 <anteaya> no, no, no
20:47:36 <anteaya> one is more than enough
20:47:39 <jroll> hehe
20:47:49 <flaper87> 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 <dhellmann> flaper87 : mordred mentioned doing something with standard deviations, too, did you look at what impact that would have over a simple %?
20:47:59 <rockyg> or is that the more dreds the merrier?
20:48:04 <flaper87> I'd love for us to focus on this one https://review.openstack.org/337853
20:48:14 <joehuang> thank you, I have to sleep now :)
20:48:14 <flaper87> dhellmann: I did not, tbh
20:48:18 <flaper87> dhellmann: but I could
20:48:21 <dhellmann> flaper87 : ok, just checking
20:48:39 <dhellmann> I'm curious, but I don't know what actually makes sense here
20:48:46 <flaper87> 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 <flaper87> we have majority already
20:49:30 <flaper87> I wonder if there are other questions
20:49:37 <mugsie> 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 <mugsie> (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 <mugsie> and if it had 3 cores, it would be ~ 30%
20:50:25 <flaper87> :P
20:50:33 <dhellmann> 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 <mordred> mugsie: that's sort of why I was origianlly musing about standard deviations
20:50:42 <mugsie> yeah
20:50:47 <mordred> it's harder math of course
20:50:55 <mtreinish> 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 <mugsie> its just the 2% rule seems ... low
20:50:59 <mtreinish> mordred: bring in numpy :)
20:51:03 <mugsie> :D
20:51:08 <dhellmann> 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 <dhellmann> or https://docs.python.org/3.5/library/statistics.html#statistics.stdev
20:51:41 <dhellmann> 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 <sdague> flaper87: so... what changed after this add?
20:52:07 <sdague> like which projects moved across a line?
20:52:15 <dhellmann> 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 <mordred> dhellmann: you are a walking encyclopedia of python
20:52:28 <flaper87> sdague: mostly not visible changes as some projects got closer to the line
20:52:31 <amrith> dhellmann, in truth, this commit doesn't do that.
20:52:42 <dhellmann> mordred : it comes in print and all major ebook formats...
20:52:42 <mugsie> 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 <sdague> flaper87: ok, which projects had the biggest drift?
20:52:54 <sdague> that might help validate if this feels fine
20:52:55 <dhellmann> mugsie : not "stuffing" no
20:53:00 <flaper87> sdague: telemetry is one example
20:53:22 <flaper87> sdague: it's in the edge of missing the diversity tag
20:53:42 <dhellmann> 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 <mordred> 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 <mordred> mugsie: good example from dhellmann
20:54:10 <sdague> flaper87: ok, that seems valid then
20:54:12 <johnthetubaguy> did we try 5%?
20:54:28 <flaper87> johnthetubaguy: we did but it left out some core reviewers that are clearly active
20:54:33 <mugsie> yeah, meant telemetrey lost the diversity tag, right?
20:54:34 <flaper87> johnthetubaguy: in teams like Telemetry for example
20:54:48 <johnthetubaguy> ah, OK
20:54:57 <flaper87> so, it was a bit too high
20:55:02 <fungi> this still seems like a lot of added complexity for very little gain. i'm particularly curious how it handles the fact that many larger teams have different core reviewer groups on different deliverables with some overlap across deliverables
20:55:25 <dhellmann> flaper87 : how are they "clearly active"?
20:55:28 <flaper87> We can adjust this later but the main change I would like to see is the check of activity for core reviewers
20:55:39 <anteaya> fungi: like infra?
20:55:47 <flaper87> dhellmann: number of reviews in the projects they are most focused on
20:55:48 <fungi> anteaya: like infra and a number of others, sure
20:55:53 <flaper87> dhellmann: Telemetry has other smaller projects
20:55:58 * anteaya thinks of the jjb team
20:56:05 <flaper87> and not everyone reviews on every Telemetry project
20:56:06 <dhellmann> flaper87: ok, oslo is another program like that
20:56:10 <flaper87> dhellmann: yeah
20:56:13 <mugsie> woul that not indicate that we shouldupdate the formula, not the % ?
20:56:14 <dhellmann> s/program/project/
20:56:30 * mugsie hates this keyboard
20:56:39 <johnthetubaguy> FWIW the more complicated logic gives me a warmer fuzzier feeling we have a better estimate than the straight 30 review cut off, not that it really makes any more sense
20:56:47 <flaper87> ok, we've 5mins left
20:57:03 <flaper87> Unless there are strong objections to discuss, I'll change topics to open discussion
20:57:14 <sdague> flaper87: ++
20:57:15 <flaper87> (sorry for cutting some ppl off, do post comments on the review)
20:57:17 <dhellmann> flaper87, johnthetubaguy : maybe we should change it to say "active for one deliverable" or something
20:57:18 <fungi> i think the diversity tag is a fundamentally flawed implementation that needs to be per-deliverable for it to make any sense
20:57:23 <corvus> some reviews take seconds.  some take hours.  the more complex we make this metric, the more important it is to get it right, and i fear that will be very difficult.
20:57:42 <dhellmann> corvus : good point
20:57:51 <flaper87> corvus: ++
20:57:54 <flaper87> #topic Open discussion
20:57:55 <johnthetubaguy> dhellmann: yeah, makes sense
20:58:04 <mugsie> which circles back to "why" ?
20:58:09 <dhellmann> fungi : also a reasonable way to change it
20:58:14 <johnthetubaguy> so its all an estimate, not sure there will ever by a good "automated" way to do it
20:58:23 <flaper87> In case ppl have some spare time for a meetbot review: https://review.openstack.org/342069
20:58:30 <fungi> also, as we know, adding metrics brings pervese incentives to make behavioral changes to meet the metric rather than to necessarily do what the metric intends to try and measure
20:59:05 <fungi> so i can see it encouraging core reviewers to focus on quick and easy reviews (to corvus's point) so they meet their quota
20:59:10 <flaper87> fungi: yeah, that's the main point against having an explicit definition of what "active" is
20:59:21 <flaper87> which is also why I've split this into several reviews
20:59:26 <flaper87> one for the code changes and another for the wording
20:59:37 <mtreinish> johnthetubaguy: well, thats kinda why I +1'd it, best first effort. We can try to get better in the future or formalize giving up trying and make it subjective
20:59:42 <dhellmann> mugsie : we want to accurately reflect how active people are, so we can accurately reflect how robust a team is, so users of projects can understand whether teams are stable or subject to the whims of a single corporate entity
20:59:45 <johnthetubaguy> mtreinish: same here
20:59:47 <flaper87> mtreinish: ++
21:00:20 <johnthetubaguy> so we are doing well with open
21:00:25 <flaper87> 1 min left
21:00:37 <mugsie> dhellmann: is there an issue we need solved, based on this? a projects that needs to have the tag removed, or the sibgle verndor one applied, based on this discussion
21:00:47 * flaper87 takes a deep breath before shouting good night to everyone
21:00:52 <mugsie> or, should we deal with this on project basis?
21:00:55 <flaper87> mugsie: this is not targeting a single project, fwiw
21:01:00 <dhellmann> mugsie : looking at some of the teams, we think they're less diverse than our current definition implies, yes
21:01:10 <flaper87> ok, time's up
21:01:17 <flaper87> #endmeeting