15:00:19 <fungi> #startmeeting tc
15:00:21 <openstack> Meeting started Thu Jun  7 15:00:19 2018 UTC and is due to finish in 60 minutes.  The chair is fungi. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:23 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:25 <openstack> The meeting name has been set to 'tc'
15:00:32 <fungi> #topic Office Hour
15:00:47 <dhellmann> o/
15:00:51 <mnaser> o/
15:00:59 <smcginnis> o/
15:01:05 <fungi> #chair cmurphy smcginnis dims dhellmann mnaser
15:01:06 <openstack> Current chairs: cmurphy dhellmann dims fungi mnaser smcginnis
15:01:20 <smcginnis> Oh good, I was wondering if you could do multiple at once.
15:01:27 <fungi> yeah, i wanted to find out
15:01:28 <zaneb> o/
15:01:34 <fungi> #chair zaneb
15:01:35 <openstack> Current chairs: cmurphy dhellmann dims fungi mnaser smcginnis zaneb
15:02:27 <mnaser> i'm not sure if this ended up being discussed outside office hours
15:02:39 <smcginnis> I was hoping we could discuss some goals - http://lists.openstack.org/pipermail/openstack-dev/2018-June/131099.html
15:02:53 <mnaser> but last office hours cdent had some questions regarding dhellmann's summary about the AT&T comments (http://eavesdrop.openstack.org/meetings/tc/2018/tc.2018-06-06-01.00.log.html#l-17)
15:03:26 <dhellmann> I think the response there in the log was accurate. It was a one-off comment and there was no real discussion.
15:03:30 <smcginnis> It's been brought up to me in different contexts since that recap.
15:03:41 <smcginnis> That's what I recall.
15:03:44 <fungi> yeah, jbryce later confirmed there had been no prior discussion of that among the board members
15:03:54 <mugsie> o/
15:03:56 <fungi> that is just sort of came flying in out of nowhere
15:04:00 <fungi> #chair mugsie
15:04:01 <openstack> Current chairs: cmurphy dhellmann dims fungi mnaser mugsie smcginnis zaneb
15:04:11 <mnaser> (i think it would probably be good for us to bring in the out-of-office-hours comments and discussions into it so anyone reading them can catch up)
15:04:16 <smcginnis> Probably doesn't warrant more than a head tilt and a sigh.
15:04:20 <mugsie> smcginnis: ++
15:04:29 <dhellmann> mnaser : ++
15:04:57 <dhellmann> yeah, at this point I wouldn't worry about it, but I'm glad to know people were actually reading my emails :-)
15:05:09 <mnaser> other than that, i don't think there was anything from last office hours (afaik), so maybe we can dive into smcginnis subject of goals
15:05:29 <dhellmann> I have something to bring up, too, which may also be long. Maybe we can time-box the goals discussion?
15:05:39 <fungi> sure
15:05:50 <mnaser> any other subjects so we can scope out time?
15:06:00 <dhellmann> oh, good idea
15:06:11 <cdent> I've thought about the att&t contribution thinng a bit  more since making that earlier comment and re-realized there's a danger in perceiving contribution to openstack the project as the same domain as openstack the wider foundation
15:06:14 <dhellmann> so I want to start talking about how we're going to divy up project teams to check in with them
15:06:37 <smcginnis> We don't need to select goals today, but I did want to make sure they were kept fresh in peoples minds as something we need to think about before we get too close to the end of this cycle.
15:06:40 <dhellmann> I don't expect us to actually come up with the split, or groupings, or whatever today, but I want to start thinking about the process
15:07:02 <smcginnis> cdent: Oh, that's a good point. Especially now.
15:07:06 <mugsie> I have one topic that someone brought to me, but I think it will just spin out into a ML thread, so it will be more of "lets think about this"
15:07:41 <mugsie> mainly - do we want to add openstack client to the help wanted list
15:07:51 <dhellmann> that's a good one to consider
15:07:58 <mnaser> cool, so we have: release goals, checking in with teams, (personally, not more than a few minutes) organizational diversity suggestion, openstack client as help wanted
15:08:13 <smcginnis> dhellmann: I wonder if we can get a list of all teams sorted by some sort of size ranking, then just assign TC members in order down the list so we each take on a balances set of teams.
15:08:38 <mnaser> 10 minutes each starting now to leave us a bit of extra time for each subject?
15:08:47 <smcginnis> Start with goals?
15:08:50 <dhellmann> smcginnis : that might work. I want to do the pairing thing, and I didn't assume we'd have the same pair checking with all the same teams, but maybe I'm over thinking it
15:08:54 <dhellmann> yeah, let's start with goals
15:09:01 <mnaser> #topic stein goal selection
15:09:05 <mnaser> #link http://lists.openstack.org/pipermail/openstack-dev/2018-June/131099.html
15:09:13 <smcginnis> OK, wanted to make sure everyone saw that post ^
15:09:27 <smcginnis> Not as much response on it than I thought we might get after the Summit discussion.
15:09:32 <smcginnis> Matt has some good responses.
15:09:34 <mnaser> i made a mental ack of "this makes sense" in my head but never replied
15:09:59 <smcginnis> So that was my assumption about how quiet it was - that I just proposed a good set. :D
15:10:21 <smcginnis> But the cold upgrade vs upgrade checking I could go with either.
15:10:34 <smcginnis> It was a close one for me picking one of the two when I came up with the strawman.
15:10:34 <dhellmann> yeah, mriedem's comments about the python 3 thing were what spurred me to start those tox patches, to try to get a sense of how much work might be involved
15:10:55 <smcginnis> dhellmann: Good to see most of those appear to be mostly painless so far.
15:10:57 <dhellmann> do we want to do more than 2 goals?
15:10:57 <mnaser> so mriedem helped clarify a little bit about the two different things in cold upgrade here
15:11:00 <mnaser> #link http://lists.openstack.org/pipermail/openstack-dev/2018-June/131113.html
15:11:05 <mugsie> yeah - I like cold upgrade as a goal, but we would need to build / update tooling
15:11:06 <dhellmann> smcginnis : yeah, and the ones that failed had relatively minor fixes
15:11:28 <dhellmann> mugsie : would we? we do *have* grenade, even if people don't like it
15:11:45 <mugsie> yes, we need to update the plugin style of grenade
15:11:50 <dhellmann> ok
15:12:02 <mnaser> do we want to see how much work python3 involves to decide if we want to do assert:supports-upgrade OR the upgrade check CLI?
15:12:06 <smcginnis> Grenade doesn't do strictly cold upgrades though, right?
15:12:12 <mugsie> I get that QA supported teams don't see it as an issue, but it is
15:12:19 <dhellmann> I wonder if that's something we can work with the QA team to help with this cycle?
15:12:36 <mugsie> smcginnis: it depends on how you set up the plugin, and what functions you hook into
15:12:40 <dhellmann> maybe the first step is having someone describe what would actually need to change
15:12:46 <smcginnis> ++
15:12:57 <mriedem> grenade is very strict too,
15:13:04 <smcginnis> I get the concept, but admit I am not 100% on the fine details of what needs to happen there.
15:13:05 <mriedem> no one is working on a non-grenade thing for plugin projects,
15:13:08 <mnaser> maybe we can do something like push up a py3 job to nova and see how bad it breaks as a general idea of how things look like?  if it is going to be a lot of work, then maybe asking devs to add py3 support AND build grenade toolong for upgrades.. that's a lot
15:13:20 <mriedem> but at the same time, grenade keeps a very consistent / rigid order on upgrades
15:13:24 <mnaser> s/toolong/tooling/
15:13:25 <mriedem> which i think is a good thing
15:13:50 <mnaser> at the same time, i think for most projects the upgrade is going to be a database sync and a service restart
15:13:53 <smcginnis> mriedem: Yeah, at least we can show a pattern that is known to work.
15:14:00 <dhellmann> yeah, a big piece of feedback was that operators needed to have that order information
15:14:23 <mriedem> right, we don't want the plugin tooling for upgrade testing to be so pluggable that projects can change their upgrade order every release
15:14:25 * mnaser has personally used grenade to see how upgrades worked to help in upgrades
15:14:29 <dhellmann> if the hard part of the upgrade goal is fixing our test tool, that feels like something we ought to do before we start the goal
15:14:31 <mugsie> mnaser: yeah, basically - grenade aslo creates resources, and checks if they exist post upgrade
15:15:02 <mnaser> it's very much a great self-documenting thing to see what is done for the service to upgrade cleanly
15:15:19 <dansmith> mugsie: I meant to catch up with you after that session, but can you summarize what the grenade problem is?
15:15:22 <smcginnis> Thinking about it, I think the upgrade check would have a bigger press "splash" than cold upgrade.
15:15:25 <dhellmann> I have to admit I don't know much about how grenade works, so having more detail about where it is difficult to integrate with would be good
15:15:25 <dansmith> designate has plugins in tree and they seem to run
15:15:47 <smcginnis> "OpenStack added tools to help ensure upgrades will work" sounds like a bigger win than "OpenStack can be upgraded" :)
15:16:08 <mugsie> yeah - and it took us 2-3 weeks of full time dev to get it to even run
15:16:13 <mriedem> https://docs.openstack.org/grenade/latest/readme.html is a good starter
15:16:27 <dansmith> mugsie: that doesn't sound like a fundamental problem to me ;)
15:16:41 <mriedem> once you got it going, is it in maint mode though?
15:16:52 <mnaser> mugsie: would you say it was just harder to get started because of the lack of docs?
15:17:02 <mugsie> mnaser: yup
15:17:11 <dansmith> it's a hard thing to do.. one person for two weeks doesn't seem at all outrageous to me
15:17:13 <mugsie> and it all being opaque bash plugins
15:17:14 <dansmith> regardless of the tool
15:17:34 <mugsie> dansmith - I would for an upgrade goal for small projects
15:17:36 <mriedem> yeah the phase stuff in devstack/grenade isn't super obvious without docs, i think devstack is better on the phase / plugin docs
15:17:56 <mnaser> maybe we can have a very simple drop in skeleton plugin
15:17:57 <mriedem> but the -qa team is also happy to help with questions i think
15:17:57 <dhellmann> do we have enough people who understand the tool and have time to help people with it that we could have a small team listed in the goal document?
15:17:59 <mriedem> i know sdague always was
15:18:00 <dansmith> https://github.com/openstack-dev/grenade/blob/master/PLUGINS.rst
15:18:01 <dims> we tweak grenade stuff at release boundaries, does not take much if i remember right
15:18:02 <mugsie> I am sure someone with 2 -3 weeks could have ripped mox3 out of nova for example
15:18:05 <mnaser> that just does a db sync
15:18:09 <dansmith> that is pretty decent I thought.. it's a flow, with steps
15:18:16 <dhellmann> mnaser : time check?
15:18:17 <fungi> i'd wager that it took longer than a couple weeks to get nova, cinder, glance and so on working in grenade... that just happened to coincide with writing grenade itself
15:18:19 <mnaser> (fyi, 2 minutes more just to keep us in time)
15:18:31 <mriedem> mugsie: "I am sure someone with 2 -3 weeks could have ripped mox3 out of nova for example" heh not really
15:18:44 <dansmith> mugsie: you should take that challenge :P
15:19:01 <mriedem> no one wants to review mox removal
15:19:02 <mnaser> i'd like us to maybe look into some action items out of this.. do we want to maybe reach out and ask devs?
15:19:02 <mugsie> heh - I have enough time scale issues :D
15:19:15 <mnaser> do we want someone to look into investigating grenade and how easy or not it is to implement
15:19:24 <mnaser> to help us decide if we want to do upgrade tooling or actual upgrade jobs
15:19:26 <dansmith> well, I'd like to talk to people that have actual problems with missing things in grenade,
15:19:28 <dhellmann> mnaser : like I said, I think a good first step is to detail what's hard, so we can figure out what to change
15:19:36 <dansmith> I can't promise to fix them or have answers, but I'd like to hear what they are
15:19:37 <mnaser> (my deployer hat sees a lot more value in CI jobs that do upgrades)
15:19:48 <dhellmann> if that means more docs, or 1-on-1 helpers, or whatever
15:19:57 <mriedem> mugsie: i don't suppose there was anything written down or bugs filed about issues with grenade while trying to integrate with it?
15:20:08 <smcginnis> OK, times up on this topic.
15:20:09 <mugsie> eh, I think there was ... let me look
15:20:10 <mriedem> like, "this key thing isn't doc'ed at all"
15:20:17 <mnaser> mugsie: as someone who's first hand dealt with this, could you maybe have a stripped down version to look at?
15:20:17 <dhellmann> it would also be useful to put together a list of the projects that would have to work on this goal
15:20:35 * smcginnis feels like we've given up one meeting now for three meetings
15:20:36 <mriedem> anyone that doesn't run grenade voting
15:20:51 <mnaser> but if mugsie doesn't have the time to do that right now
15:20:59 <mnaser> we can defer decision making to another time
15:21:03 <mnaser> we all have an idea in our mind
15:21:10 <dhellmann> yeah, I think we have a few next steps
15:21:17 <mnaser> but maybe we should dive into dhellmann's topic for now :)
15:21:19 <mugsie> https://github.com/openstack/designate/tree/master/devstack/upgrade
15:21:20 <dhellmann> who's going to drive this one?
15:21:24 <dhellmann> the goal, that is
15:21:42 <dhellmann> if we have a volunteer, maybe that person could report back next week?
15:22:09 <mugsie> I can get a list of the issues we had with grenade together, if that would help
15:22:15 <dhellmann> ++, thanks mugsie
15:22:18 <mriedem> that would be an excellent start
15:22:39 <mnaser> #action mugsie gather list of grenade implementation issues to evaluate upgrade goal
15:22:40 <fungi> "report back next week" definitely makes this not-meeting seem more and more like a meeting ;)
15:22:41 <dhellmann> is there 1 grenade job? or do different projects use different names for that job?
15:22:44 <smcginnis> mugsie: If we could add notes to our goal backlog etherpad, I think that would be good to capture it there.
15:22:50 <mugsie> smcginnis: ++
15:22:54 <dhellmann> fungi : the report could go to the mailing list
15:23:06 <dhellmann> smcginnis : ++
15:23:24 <mnaser> looks like we got something!
15:23:26 <mnaser> onto the next?
15:23:30 <dhellmann> cool
15:23:34 <smcginnis> ++
15:23:42 <dhellmann> so, checking in on project health
15:23:42 * dtroyer reads scrollback…
15:23:44 <fungi> i do wonder whether designate's struggle to get undocumented grenade plugin testing was due to it being the first team to undertake such a challenge
15:23:46 <mnaser> #topic checking in with teams
15:23:52 <dhellmann> fungi : likely
15:23:53 <mriedem> fungi: ironic was first i think
15:23:57 <fungi> ahh
15:23:58 <dhellmann> "early"
15:24:13 <mriedem> dtantsur: would be the person to ask, or jroll
15:24:15 <dims> dhellmann : here's a easy way to find the grenade playbooks - http://codesearch.openstack.org/?q=PROJECTS.*grenade&i=nope&files=.*%2F*.yaml&repos=
15:24:20 <mugsie> yeah, and there is still only 5 or 6 teams who have one now
15:24:21 <dhellmann> dims : thanks
15:24:27 <dtroyer> the fact that Grenade is still useful at all is a miracle to me, and says how much sdague did to get it there…   FIWI, it took over 2 months to get a basic clean run when we wrote it
15:24:29 <mnaser> so
15:24:42 <mnaser> i liked smcginnis idea about splitting projects up across members :)
15:24:56 <dhellmann> do people want me to assign them out? or do we want volunteers?
15:25:02 <smcginnis> Seems like it would be good to spread the load.
15:25:07 <mnaser> not to say we 'pick and choose' but perhaps some of us that are more involved in specific communities can volunteer for specific ones
15:25:10 <dhellmann> we should also talk about exactly what we mean so we're all doing the same sort of checking
15:25:12 <smcginnis> I'm fine with being assigned.
15:25:14 <mnaser> and the leftovers could be split?
15:25:22 <dims> dhellmann : fine with being assigned
15:25:30 * dtantsur appears from the shadows
15:25:32 <fungi> is there a more detailed proposal as to what we'd do with the projects we're each assigned? survey them? hang out in their channels and weekly meetings? something else?
15:25:34 <smcginnis> mnaser: Oh, true. Like I should probably have cinder and probably glance.
15:25:38 <dhellmann> mnaser : yeah, I actually want our PTLs to not be our (only) point of contacts on things, because I want a different perspective
15:25:47 <mnaser> ++
15:25:50 <dhellmann> fungi : good question
15:26:03 <dhellmann> I was thinking at least read the meeting logs. Maybe monitor their major announcement emails.
15:26:05 <mnaser> so when saying check in, just maybe look at meetings? go through their reviews and see if things are healthy.. irc?
15:26:13 <dhellmann> Talk to the PTL about whether they are experiencing any issues we can help with?
15:26:18 <dhellmann> Generally to get a sense of things.
15:26:25 <dtantsur> not sure if it's still important or not, but we have two working grenade plugins in the ironic world
15:26:36 <fungi> your friendly neighborhood tc contact
15:26:37 <zaneb> should we write a script (as in movie script, not python script) or something for the initial contact?
15:26:40 <dhellmann> I had at least 2 cases at the summit where someone mentioned a "long standing" issue between 2 teams. I want us to find those before they become long standing.
15:26:59 <mnaser> i agree
15:27:02 <dims> makes sense dhellmann
15:27:03 <smcginnis> Some things to check - are they still holding regular meetings, are patches getting reviewed and merged, is the PTL aware of any issues.
15:27:09 <mnaser> having more of a presence and being more reachable is important
15:27:11 <dhellmann> fungi : right. like a liaison. :-)
15:27:14 <fungi> aha, so more things like brokering inter-team relationships
15:27:17 <dhellmann> zaneb : a list of questions/topics might be good. it doesn't have to be very formal, but it should be consistent
15:27:22 <smcginnis> And being a known contact point for them if they need help.
15:27:25 <dhellmann> smcginnis : those are good things, too
15:27:26 <mugsie> yeah, knowing that you can reach out to $people seems like a good thing
15:27:35 <zaneb> dhellmann: ++
15:27:37 <dhellmann> we do have this frequent conversation about whether projects are active enough to stay on the official list
15:27:44 <mnaser> and $people is not a group or a mailing list but someoen that you spoke to personally
15:27:49 <dhellmann> right
15:27:50 <mnaser> so they might understand situations much more intimately
15:27:55 <mnaser> i like it
15:28:01 <mugsie> Like back in the old days when teams and PTLs would have a sync with ttx once a week?
15:28:08 <fungi> conversely, we don't want to give teams the impression they can only reach out to their designated tc representative, right?
15:28:12 <mugsie> (maybe not once a week though)
15:28:17 <mugsie> fungi: ++
15:28:20 <mnaser> i also think we should pair up on this
15:28:27 <dhellmann> mugsie : it doesn't have to be that often, but I want to make sure people know they can come to someone if they're experiencing an issue
15:28:35 <dhellmann> fungi : sure
15:28:37 <smcginnis> fungi: Right, but some might not even realize they *can* reach out to someone on issues.
15:28:42 <dhellmann> mnaser : yes, definitely
15:28:54 <mriedem> are we talking about tc guidance counselors?
15:29:00 <smcginnis> Hah!
15:29:03 <dhellmann> smcginnis : yeah, that seems to be the problem in the cases I had at the summit
15:29:32 <smcginnis> Time check
15:29:34 <mnaser> i think we're all in agreement and seem to have a clear idea of really checking health of a team
15:29:39 <mnaser> 3-4 minutes or so
15:29:40 <fungi> i'm all for this kinder, gentler technical committee
15:29:46 <mnaser> do we want to discuss ways to split this up?
15:29:47 <dhellmann> #action dhellmann make a list of project teams and TC member assignments
15:29:48 <smcginnis> I like the idea
15:29:52 <mugsie> and pro-active tc :)
15:30:10 <smcginnis> Maybe we sign up for specific projects, then out of the remaining we divy up assignments?
15:30:18 <dhellmann> sure, we could do that
15:30:20 <dhellmann> #undo
15:30:21 <openstack> Removing item from minutes: #action dhellmann make a list of project teams and TC member assignments
15:30:24 <mriedem> nova wants mnaser then
15:30:30 <mriedem> i'll call it
15:30:30 <dhellmann> #action dhellmann make a list of project teams for TC members to volunteer for
15:30:33 <mriedem> he has candy in his office
15:30:39 <mnaser> :>
15:30:57 <fungi> time to bikeshed what metric we're using to divvy them up "by size"? (number of contributors? amount of code churn? number of deliverables? number of core reviewers? something else?)
15:31:04 <dims> dang! mriedem does not like me anymore
15:31:11 <dhellmann> fungi : I'm not sure the size matters?
15:31:20 <mnaser> fungi: we can bikeshed once we have leftovers?
15:31:32 <smcginnis> ^d^d^d^d
15:31:32 <fungi> oh, sounded like you had initially said something about trying to sort them by some means
15:31:36 <mnaser> i'm sure we all have projects that are within our areas of interest
15:31:56 <dims> mnaser right i am trying to get out of my comfort zone
15:32:11 <dhellmann> fungi : I don't want the same 2 TC members paired for every team, and I don't want the PTL to be the primary contact from the TC. Other than that, I'm open to any other ways to group things.
15:32:12 <mnaser> dims: hence the idea that we get some that we pick, but the rest we'll get assigned :)
15:32:19 <dhellmann> the smaller teams may actually be harder to get in touch with, fwiw
15:32:19 <dims> ++
15:32:26 <dhellmann> that has been my experience from the release team, anyway
15:32:42 <mnaser> i think we've reached a good point, do we want to speak briefly about the next topic now?
15:32:48 <dhellmann> ++
15:33:09 <mnaser> ETIMEOUT no responses other than dhellmann
15:33:10 <mnaser> #topic organizational diversity
15:33:16 <fungi> yeah, i think i misread initially. no worries. was trying to juggle following two meetings and some maintenance at the same time
15:33:28 <mnaser> so, i posted a thread about this which has gathered a lot of interesting feedback
15:33:44 <mnaser> but an idea that has floated around which i was thinking of is linking it to releases
15:34:02 <mnaser> so once a project makes a release, only then does their status gets 're-evaluated'
15:34:15 <mnaser> that prevents having someone work on a big report at the end of cycle when we're all really busy
15:34:32 <mnaser> and we can still somewhat leverage our automation infrastructure, tying into the release process, to have the checks happen
15:34:38 <smcginnis> mnaser: So are you thinking something added to our release automation that would check that?
15:34:46 <smcginnis> Hah, yep.
15:34:48 <mnaser> smcginnis: something in `post` alongside the other jobs
15:34:49 <mnaser> yep
15:34:49 <dhellmann> I like the idea of linking it to the development cycle. There are some technical issues with linking it to the release itself. Principally, a team has many deliverables and they aren't all released at the same time.
15:35:08 <zaneb> does that create an incentive for some projects to never release? :D
15:35:12 <dhellmann> but we do use them all when checking contribution diversity
15:35:22 <mugsie> so for team:diverse-affiliation we could have team:diverse-affiliation:rocky ?
15:35:25 <dhellmann> zaneb : the release team already has a policy of recommending dropping projects that do not release
15:35:38 <mnaser> mugsie: we have not decided that part yet
15:35:43 <mnaser> we could look into that
15:36:02 <mnaser> i was thinking doing this for the 'major' release, but then thought that we can also do this for any milestone releases
15:37:06 <dhellmann> by "major" do you mean "final" or "service"? e.g., cinder has a server and a client. they aren't released together.
15:37:23 <mnaser> sorry, by major i meant when we do our 'openstack release', marketing pages are up, etc
15:37:29 <dhellmann> ok
15:37:31 <mugsie> dhellmann: is the tag not applied to both separatly?
15:37:43 <mnaser> tags are applied to teams afaik, not projects/deliverables
15:37:46 <dhellmann> mugsie : the tags are applied to the team
15:37:52 <dhellmann> at least this tag is
15:38:00 <dhellmann> "team:"
15:38:04 <fungi> yeah, i think syncing up contributor affiliation diversity stats to just be per-cycle values makes sense
15:38:18 <smcginnis> And teams can have cycle based and non-cycle based deliverables.
15:38:25 <dhellmann> yes, that's another good point
15:38:44 <smcginnis> Hasn't ttx been doing these roughly per-cycle until now?
15:38:57 <dhellmann> I need to look into how much this is already automated. Maybe the thing to do is put it on the release schedule, to remind someone on the TC to do it?
15:39:05 <mugsie> we could just time box it - between these 2 date points the team was / was not diverse ?
15:39:10 <mnaser> i'm not too familiar with the intimate details of how all of this works, i volunteered myself to help out
15:39:14 <dhellmann> smcginnis : I think so
15:39:20 <mugsie> but the problem with the actual caluclations still remains
15:39:29 <mnaser> maybe next time we sit down ttx can bring up his knowledge upon us :)
15:39:37 <dhellmann> yes, that's a separate thing and we should talk about that, too, mugsie
15:39:49 <mugsie> e.g. I counted as 3 companies for a while
15:40:07 <mnaser> mugsie: i mean for how much work you put in, don't see whats wrong ;) hah :p
15:40:13 <mugsie> :D
15:40:19 <smcginnis> mugsie: You're just a 3x developer.
15:40:35 <mugsie> 3x the destruction of a normal one? for sure :P
15:40:39 <smcginnis> :)
15:40:48 <mnaser> so that's the overall thing, maybe next time when chat ttx will be around to discuss this more
15:40:50 <dhellmann> for the stats I put together for the meeting in vancouver, I used the affiliation at the time of the contribution. I'm not so sure that works for this meausre.
15:41:19 <mnaser> i just wanted to have a quick updates and it didnt seem like everyone is too wildly opposed to it :)
15:41:32 <fungi> are you relying on the affiliation date ranges provided by the foundation member lookup api?
15:41:39 <fungi> or something else?
15:41:46 <mnaser> that's it for me if anyone has no other comments we can talk about the last thing which is openstack client as help wanted?
15:41:57 <fungi> to map affiliation at the time of the contribution
15:42:01 <dhellmann> fungi : the foundation member api
15:42:05 <mugsie> but we have teams like searchlight, which are down as diverse, and have 8 commits this cycle
15:42:17 <mnaser> #action mnaser post suggestion of tying organizational diversity checks to releases
15:42:29 <dhellmann> right, the question of what to do with those low volume teams is a separate part of this
15:42:34 <mnaser> are they still releasing?
15:42:46 <dhellmann> maybe we should wait to decide anything until we've had the health check?
15:42:46 <mugsie> yeah, afaik they are
15:43:02 <fungi> searchlight is our only listed maintenance mode team at this point
15:43:19 <dhellmann> right, we don't expect lots of activity there
15:43:22 <dhellmann> https://governance.openstack.org/tc/reference/tags/status_maintenance-mode.html
15:43:40 <mnaser> if the team behind it was diverse then it should stay that way if there are no new commits (imho)
15:43:56 <mnaser> because it is still diverse. and commits come from all different organizations
15:44:06 <mnaser> if one company started doing commits to it now, it'll go back to single vendor, which is also ok
15:44:08 <smcginnis> I agree - freeze reporting on maintenance mode projects.
15:44:17 <mnaser> i like that
15:44:24 <fungi> wfm
15:44:30 <mnaser> #undo
15:44:31 <mugsie> yup
15:44:32 <openstack> Removing item from minutes: #link https://governance.openstack.org/tc/reference/tags/status_maintenance-mode.html
15:44:37 <mnaser> er
15:44:41 <mnaser> oh
15:44:43 <mnaser> #undo
15:44:43 <openstack> Removing item from minutes: #action mnaser post suggestion of tying organizational diversity checks to releases
15:45:00 <mnaser> #action mnaser post suggestion of tying organizational diversity checks to releases + freezing reporting on maintenance mode projects
15:45:05 <mnaser> #link https://governance.openstack.org/tc/reference/tags/status_maintenance-mode.html
15:45:21 <mnaser> we have 15 minutes left and maybe it would be good to bring up our last topic that mugsie wanted to talk about
15:45:26 <mnaser> openstack client as help needed afaik?
15:46:03 <mugsie> yup - it kind of a foundational part of our UX, and there seems to be issues with review velocity
15:46:14 <mnaser> #topic openstack client help needed
15:46:24 <dhellmann> yeah, dtroyer is stretched thin and we've mostly lost stevemar
15:46:30 <fungi> i saw some of that bubble up in a recent ml thread
15:46:30 <mugsie> a member of the community pinged me about it last week, and I looked at the backlog
15:46:53 <mugsie> so, if dtroyer is OK with it I think we need to highlight the resource issues there
15:47:00 <smcginnis> Since our unofficial goal has been to migrate to osc, I think it definitely needs more resources.
15:47:09 <smcginnis> Help wanted makes sense to me.
15:47:12 <mugsie> smcginnis: ++
15:47:16 <mnaser> https://review.openstack.org/#/q/(project:openstack/openstackclient+OR+project:openstack/openstacksdk)+is:open
15:47:37 <dhellmann> do we want to remove anything from the existing top 5 list? or do we want to expand it?
15:47:38 <dhellmann> https://governance.openstack.org/tc/reference/help-most-needed.html
15:47:43 <cmurphy> steve isn't totally gone fwiw https://review.openstack.org/#/q/reviewedby:%22Steve+Martinelli+%253Cs.martinelli%2540gmail.com%253E%22
15:47:51 <dhellmann> I did say "mostly"
15:48:05 <mugsie> https://review.openstack.org/#/q/project:openstack/python-openstackclient+is:open is more depressing
15:48:08 <mnaser> https://review.openstack.org/#/q/(project:openstack/python-openstackclient+OR+project:openstack/openstackclient+OR+project:openstack/openstacksdk)+is:open
15:48:29 <mnaser> as a side idea
15:48:34 <mnaser> what about organizing 'review-athons'
15:48:36 <mriedem> i did my part and reviewed one compute osc thing this week :)
15:48:43 <mriedem> adding tags support for servers
15:48:50 <mnaser> im sure a lot of members in the community can do reviews
15:48:54 <mriedem> i think the project teams definitely need to be more involved in reviewing their project-specific stuff in osc
15:48:57 <mriedem> and i'd be happy to help there
15:49:01 <mugsie> mriedem: ++
15:49:06 <mriedem> nova core is alread ydoing this for osc-placement
15:49:18 <dhellmann> ++
15:49:21 <mriedem> we also understand the various microversion implications
15:49:41 <mugsie> but we need people who can also help projects outside the nova + friends group
15:49:44 <mriedem> i just need help at times about things like which type of command parent classes to use and such
15:49:49 <mnaser> forgive this wild suggestion
15:50:03 <mnaser> do we want to add something as part of the release process to push teams to review all their osc changes for their project
15:50:10 <mnaser> and work with the osc team to use topics for this thing
15:50:19 <mugsie> of course - there is another soluton
15:50:35 <mugsie> push all osc interactions to plugins, and make the teams own them
15:50:38 <dims> i suppose we can't ask for all-scenarios-must-work ... may be we can say something like all your devstack and grenade plugins should use osc for sure, anything else is a bonus?
15:50:39 <fungi> i'm not grasping what that would have to do at all with the release process
15:51:11 <mugsie> then the osc team has a lot less surface area to deal with
15:51:12 <dhellmann> mugsie : it was designed to work that way, but we found that most developers did not appreciate the importance of UI consistency *and* we ended up with project teams clashing over the command namespaces
15:51:14 <fungi> how does reviewing topical osc changes relate to release cadence?
15:51:35 <mnaser> fungi: so just like how we have certain expectations by milestones for a project to have all their client-based code be in
15:51:58 <mugsie> dhellmann: its that way for everyone but 4/5 projects already
15:52:00 <dtroyer> mugsie: for context, that is one reason OSC existed in the first place, those teams could not/would not agree on damn near anything…
15:52:07 <zaneb> mugsie: ++
15:52:08 <mriedem> as a data point,i'll say that even with the small number of osc-placement patches up for review, i have a hard time giving those review time
15:52:23 <mugsie> dtroyer: sure - but you did a good job of beating them into shape :)
15:52:26 <mnaser> say.. kinda like requirements freeze time
15:52:46 <dtroyer> for what it's worth, adopting the SDK once it has a 1.0 release opens the door to a lot of the things people want out of OSC, specitifally microversions
15:52:50 <smcginnis> No idea if there is a way to automate it, but a semi-regular report to the ML showing each project and its osc support coverage would be interesting to me.
15:53:04 <mnaser> like the emails smcginnis sends about release countdown
15:53:09 <mnaser> mentioning "development focus"
15:53:25 <mugsie> mnaser: that is a hard thing to gather though
15:53:37 <mugsie> s/mnaser/smcginnis/
15:53:45 <fungi> i guess the unfortunate solution of namespacing commands based on which plugin they're in means that subcommands would end up in nonsensical hierarchies based on which team was responsible for them rather than more intuitive groupings
15:53:47 <smcginnis> mugsie: Yeah...
15:54:06 <mnaser> and maybe if it's not too much of a pain under the general info "these projects have pending changes in their openstack client code"
15:54:08 <mugsie> fungi: not really, we added 2 or 3 top level command
15:54:10 <mugsie> +s
15:54:11 <smcginnis> mugsie: At one point there was a nice spreadsheet of the gaps with Cinder support, but I believe that was all manual.
15:54:18 * dtroyer reading scrollback
15:54:25 <zaneb> fungi: there are non-namespaced plugins now AIUI
15:54:33 <dtroyer> oh, OSC doesn't namespace although it looks like that sometimes
15:54:47 <dhellmann> fungi : the "namespace" in this sense is the resource name. I think "container" was one where swift was using it before we got magnum, for example.
15:54:48 <mugsie> https://github.com/openstack/python-designateclient/blob/master/setup.cfg#L90
15:54:48 <fungi> mugsie: right, you can _currently_ add whatever top-level commands you want, which is what i was saying... that's what leads to collisions between teams
15:54:49 <dtroyer> there is a subtle differece that I can explain to anyone who hasn't heard it offline
15:55:01 <smcginnis> mnaser: Not sure I would want to include that in the release countdown email. Something doesn't feel right about it. But if we had something similar that could work.
15:55:18 <mnaser> are we looking to help with OSC reviews or making it more functional/adding features?
15:55:21 * fungi gives up. this conversation is moving too fast and his points seem to get taken in reverse by the time he can type them
15:55:29 <mnaser> :(
15:55:30 <mriedem> telling project cores "go review osc patches for your resource" is going to end up down a well i think
15:55:51 <dhellmann> mriedem : we don't need project cores to do it.
15:55:52 <smcginnis> mriedem: ++
15:55:54 <mriedem> need to find liaisons or just people that care
15:55:58 <dhellmann> right
15:56:07 <dtroyer> mriedem: as a counter-example, nearly all of the network work was done by the neutron team(s), it is really the only reason it got done
15:56:10 <mugsie> how about "go review osc patches, or your service will be moved out into a plugin" ?
15:56:19 <fungi> much like python-novaclient has (or had) different core reviewers than nova
15:56:34 <mnaser> fungi, mriedem: that's a good point
15:56:39 <mriedem> i've been saying nova needs to move off novaclient for CLI and into OSC
15:56:52 <mriedem> that's why i added te community wide goal to close the gap on the OSC CLIs
15:57:13 <mriedem> i definitely have bought into the unified CLI
15:57:16 <mriedem> and use it as much as possible now
15:57:20 <mriedem> including in new nova docs
15:57:31 <mugsie> mriedem: ++
15:57:33 <mriedem> i want to burn "nova boot" from our lexicon
15:57:51 <mriedem> but, i'm only one person already stretched thin
15:57:52 <mugsie> we removed our cli when we jumped api versions
15:57:59 <fungi> does the always-backward-compatible, non-branching nature of osc provide challenges compared to python-novaclient being tied a bit more closely (via branching, et cetera) to the versions of other services which rely on it for integrating with nova?
15:58:00 <zaneb> presumably if Nova could drop any effort it's putting in to novaclient CLI and redirect it to OSC, it'd be a wash?
15:58:10 <zaneb> so why isn't that happening?
15:58:11 * dtroyer sends mriedem his payola check
15:58:26 <mriedem> zaneb: it's come up, but people get hung up on the "but osc has this 60 micorversion gap"
15:58:32 <zaneb> because the code is owned by the OSC project and not the Nova project?
15:58:40 <zaneb> ah, ok
15:58:41 <mugsie> fungi: does having plugins help that?
15:58:56 <mnaser> we have 2 minutes so maybe figuring out a conclusion would be good, or we can defer to the next discussion :)
15:58:57 <mriedem> no people just want to get their feature into the server, they for the most part don't care about ansillary projects like novaclient, osc, horizon or tempest
15:58:58 <mugsie> when you install stable/pike, and the stable/pike client, you only get the relevent commands?
15:58:59 <fungi> i have no clue
15:59:05 <zaneb> mriedem: so we're waiting for openstacksdk 1.0, really
15:59:10 <mriedem> this is where maintainers have to care and take on the work
15:59:22 <dtroyer> fungi: the challenge has been with removing things from client libs (see recent novaclient).  we solve that with the switch to SDK once we get a 1.0 release of that
15:59:46 <fungi> makes sense
15:59:50 <mnaser> anyone want to propose some sort of action out of this discussion before we wrap up?
15:59:55 <dhellmann> it sounds like it would be useful to have a list of specific things the OSC team could use help with, as a start. we're going to need that to add it to the help-wanted list anyway, right?
16:00:01 <smcginnis> Official times up.
16:00:03 <zaneb> people don't care if they can access their feature with a client??
16:00:07 <dtroyer> mugsie: if you install osc stable/pike you get that snapshot in time, yes.  you should not have to do that though unless you are not running from a venv
16:00:12 * dims heads out for an errand
16:00:20 <mugsie> dhellmann: yeah, we need a list I think
16:00:22 <mriedem> i can figure out what the nova microversion gap is in osc
16:00:27 <mriedem> that's an action i've been meanning to do anyway
16:00:30 <mriedem> sign me up
16:00:38 <dhellmann> #action mriedem figure out the nova microversion gap in osc
16:00:56 <dtroyer> mriedem: remember we don't need to support every microversion, just the ones needed by each command
16:01:03 <dhellmann> dtroyer : do you have time to put together a list of things the OSC team could use help with in more detail than "reviews"?
16:01:08 <dtroyer> and sdk goes a long way in helping do that
16:01:10 <mriedem> dtroyer: sure i know
16:01:30 <mriedem> lots of microversions in nova are on admin stuff that's not in osc
16:01:41 <mriedem> which has been another reason people keep doing them in novaclient
16:01:42 <fungi> i just know that in the past we had this unfortunate dynamic between application developers needing a novaclient which could talk to lots of versions of nova, and other openstack services which needed very specific versions of novaclient for integrating with contemporary versions of nova, and having a separate unified client/sdk for users/application developers was brought up as the way out of that
16:01:44 <fungi> dilemma
16:02:11 <fungi> so that we ended up with the inter-service communication libraries and the application developer sdk not being bound to each other
16:02:21 <clarkb> dtroyer: mriedem that is how shade functioned too fwiw. Basically use the base api for everything unless a specific command needs a newer microversion then use that for that request only
16:02:56 <dhellmann> fungi : that split may make less sense now that we have more work and fewer people
16:03:29 <fungi> right, but if we're going back to one sdk which is used both for inter-service communication and application development, i worry that we'll reintroduce that coupling
16:03:36 <dtroyer> that split was always due to assumptions in the client libs being not suitable for CLI use… mordred thinks this is reversed for the SDK and is not a problem
16:03:47 <mnaser> i think we can continue to discuss within the channel but we can probably close out, fungi i'll leave that up to you :)
16:04:35 <fungi> dtroyer: yeah, i suppose if the sdks are first and foremost written for users/application developers, and the services can also use them for inter-service communication if they want, then perhaps that does solve it
16:04:38 <mugsie> dhellmann: me and a few others (dims TheJulia smcginnis I think) have an action from the meeting in YVR for improving the help wanted listings - should we take OSC as a start case?
16:05:01 <mugsie> as an action to kick off
16:05:12 <dtroyer> fungi: also, keeping the dep list for SDK really small helps a lot for co-installability
16:05:12 <dhellmann> mugsie : it sounds like we need to collect more info first. it might be better to work on the things we've already got on the list?
16:05:48 <dhellmann> mugsie : and don't forget to pull the board member volunteers into that discussion
16:06:05 <mugsie> OK - who is collecting info? all I have is "needs reviewers"
16:06:25 * mordred reading scrollback
16:06:36 <dhellmann> mugsie : we didn't get a volunteer for that. I suspect dtroyer is the best person to talk to, but he may not have time to write it all up
16:07:12 <mordred> yes- I believe because the sdk is end-user/client oriented _first_ rather than service-to-service first the situation is reversed
16:07:31 <mugsie> yeah - I definitely won;t have any extra time in the next 7 days for it either :/
16:07:41 <dtroyer> I will help as much as I can, but I'm totally interrupt-driven these days :(
16:07:42 <mordred> the problem with python-*client is that they are service-to-service first and make life harder for end-users who need to touch more than one version
16:08:18 <mugsie> dtroyer: sure, its the old problem of needing to spend time to get things that give you back time :)
16:09:10 * mugsie has to go AFK for a bit
16:09:17 * mordred is allocating personal time to directly helping getting OSC up and on to the sdk - although post-summit has been extra busy so apologizes that hasn't gotten further
16:09:22 <mordred> but I'll definitely directly work on it
16:09:31 <dhellmann> I added OSC to the tracker: https://wiki.openstack.org/wiki/Technical_Committee_Tracker#finding_help_for_the_unified_CLI_team
16:09:34 <mriedem> you have personal time?
16:09:37 <mriedem> what a luxury
16:09:38 <mordred> mriedem: wel
16:10:31 <dhellmann> are we winding down? should we close out the meeting log?
16:10:43 <smcginnis> Probably, we are over the hour.
16:10:45 <mnaser> ++
16:10:46 <smcginnis> Well over. :)
16:10:48 <fungi> sure, i was just checking to see if the conversation had died down sufficiently
16:10:52 <fungi> #endmeeting