15:00:19 #startmeeting tc 15:00:21 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:00:25 The meeting name has been set to 'tc' 15:00:32 #topic Office Hour 15:00:47 o/ 15:00:51 o/ 15:00:59 o/ 15:01:05 #chair cmurphy smcginnis dims dhellmann mnaser 15:01:06 Current chairs: cmurphy dhellmann dims fungi mnaser smcginnis 15:01:20 Oh good, I was wondering if you could do multiple at once. 15:01:27 yeah, i wanted to find out 15:01:28 o/ 15:01:34 #chair zaneb 15:01:35 Current chairs: cmurphy dhellmann dims fungi mnaser smcginnis zaneb 15:02:27 i'm not sure if this ended up being discussed outside office hours 15:02:39 I was hoping we could discuss some goals - http://lists.openstack.org/pipermail/openstack-dev/2018-June/131099.html 15:02:53 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 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 It's been brought up to me in different contexts since that recap. 15:03:41 That's what I recall. 15:03:44 yeah, jbryce later confirmed there had been no prior discussion of that among the board members 15:03:54 o/ 15:03:56 that is just sort of came flying in out of nowhere 15:04:00 #chair mugsie 15:04:01 Current chairs: cmurphy dhellmann dims fungi mnaser mugsie smcginnis zaneb 15:04:11 (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 Probably doesn't warrant more than a head tilt and a sigh. 15:04:20 smcginnis: ++ 15:04:29 mnaser : ++ 15:04:57 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 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 I have something to bring up, too, which may also be long. Maybe we can time-box the goals discussion? 15:05:39 sure 15:05:50 any other subjects so we can scope out time? 15:06:00 oh, good idea 15:06:11 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 so I want to start talking about how we're going to divy up project teams to check in with them 15:06:37 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 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 cdent: Oh, that's a good point. Especially now. 15:07:06 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 mainly - do we want to add openstack client to the help wanted list 15:07:51 that's a good one to consider 15:07:58 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 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 10 minutes each starting now to leave us a bit of extra time for each subject? 15:08:47 Start with goals? 15:08:50 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 yeah, let's start with goals 15:09:01 #topic stein goal selection 15:09:05 #link http://lists.openstack.org/pipermail/openstack-dev/2018-June/131099.html 15:09:13 OK, wanted to make sure everyone saw that post ^ 15:09:27 Not as much response on it than I thought we might get after the Summit discussion. 15:09:32 Matt has some good responses. 15:09:34 i made a mental ack of "this makes sense" in my head but never replied 15:09:59 So that was my assumption about how quiet it was - that I just proposed a good set. :D 15:10:21 But the cold upgrade vs upgrade checking I could go with either. 15:10:34 It was a close one for me picking one of the two when I came up with the strawman. 15:10:34 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 dhellmann: Good to see most of those appear to be mostly painless so far. 15:10:57 do we want to do more than 2 goals? 15:10:57 so mriedem helped clarify a little bit about the two different things in cold upgrade here 15:11:00 #link http://lists.openstack.org/pipermail/openstack-dev/2018-June/131113.html 15:11:05 yeah - I like cold upgrade as a goal, but we would need to build / update tooling 15:11:06 smcginnis : yeah, and the ones that failed had relatively minor fixes 15:11:28 mugsie : would we? we do *have* grenade, even if people don't like it 15:11:45 yes, we need to update the plugin style of grenade 15:11:50 ok 15:12:02 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 Grenade doesn't do strictly cold upgrades though, right? 15:12:12 I get that QA supported teams don't see it as an issue, but it is 15:12:19 I wonder if that's something we can work with the QA team to help with this cycle? 15:12:36 smcginnis: it depends on how you set up the plugin, and what functions you hook into 15:12:40 maybe the first step is having someone describe what would actually need to change 15:12:46 ++ 15:12:57 grenade is very strict too, 15:13:04 I get the concept, but admit I am not 100% on the fine details of what needs to happen there. 15:13:05 no one is working on a non-grenade thing for plugin projects, 15:13:08 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 but at the same time, grenade keeps a very consistent / rigid order on upgrades 15:13:24 s/toolong/tooling/ 15:13:25 which i think is a good thing 15:13:50 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 mriedem: Yeah, at least we can show a pattern that is known to work. 15:14:00 yeah, a big piece of feedback was that operators needed to have that order information 15:14:23 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 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 mnaser: yeah, basically - grenade aslo creates resources, and checks if they exist post upgrade 15:15:02 it's very much a great self-documenting thing to see what is done for the service to upgrade cleanly 15:15:19 mugsie: I meant to catch up with you after that session, but can you summarize what the grenade problem is? 15:15:22 Thinking about it, I think the upgrade check would have a bigger press "splash" than cold upgrade. 15:15:25 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 designate has plugins in tree and they seem to run 15:15:47 "OpenStack added tools to help ensure upgrades will work" sounds like a bigger win than "OpenStack can be upgraded" :) 15:16:08 yeah - and it took us 2-3 weeks of full time dev to get it to even run 15:16:13 https://docs.openstack.org/grenade/latest/readme.html is a good starter 15:16:27 mugsie: that doesn't sound like a fundamental problem to me ;) 15:16:41 once you got it going, is it in maint mode though? 15:16:52 mugsie: would you say it was just harder to get started because of the lack of docs? 15:17:02 mnaser: yup 15:17:11 it's a hard thing to do.. one person for two weeks doesn't seem at all outrageous to me 15:17:13 and it all being opaque bash plugins 15:17:14 regardless of the tool 15:17:34 dansmith - I would for an upgrade goal for small projects 15:17:36 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 maybe we can have a very simple drop in skeleton plugin 15:17:57 but the -qa team is also happy to help with questions i think 15:17:57 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 i know sdague always was 15:18:00 https://github.com/openstack-dev/grenade/blob/master/PLUGINS.rst 15:18:01 we tweak grenade stuff at release boundaries, does not take much if i remember right 15:18:02 I am sure someone with 2 -3 weeks could have ripped mox3 out of nova for example 15:18:05 that just does a db sync 15:18:09 that is pretty decent I thought.. it's a flow, with steps 15:18:16 mnaser : time check? 15:18:17 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 (fyi, 2 minutes more just to keep us in time) 15:18:31 mugsie: "I am sure someone with 2 -3 weeks could have ripped mox3 out of nova for example" heh not really 15:18:44 mugsie: you should take that challenge :P 15:19:01 no one wants to review mox removal 15:19:02 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 heh - I have enough time scale issues :D 15:19:15 do we want someone to look into investigating grenade and how easy or not it is to implement 15:19:24 to help us decide if we want to do upgrade tooling or actual upgrade jobs 15:19:26 well, I'd like to talk to people that have actual problems with missing things in grenade, 15:19:28 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 I can't promise to fix them or have answers, but I'd like to hear what they are 15:19:37 (my deployer hat sees a lot more value in CI jobs that do upgrades) 15:19:48 if that means more docs, or 1-on-1 helpers, or whatever 15:19:57 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 OK, times up on this topic. 15:20:09 eh, I think there was ... let me look 15:20:10 like, "this key thing isn't doc'ed at all" 15:20:17 mugsie: as someone who's first hand dealt with this, could you maybe have a stripped down version to look at? 15:20:17 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 anyone that doesn't run grenade voting 15:20:51 but if mugsie doesn't have the time to do that right now 15:20:59 we can defer decision making to another time 15:21:03 we all have an idea in our mind 15:21:10 yeah, I think we have a few next steps 15:21:17 but maybe we should dive into dhellmann's topic for now :) 15:21:19 https://github.com/openstack/designate/tree/master/devstack/upgrade 15:21:20 who's going to drive this one? 15:21:24 the goal, that is 15:21:42 if we have a volunteer, maybe that person could report back next week? 15:22:09 I can get a list of the issues we had with grenade together, if that would help 15:22:15 ++, thanks mugsie 15:22:18 that would be an excellent start 15:22:39 #action mugsie gather list of grenade implementation issues to evaluate upgrade goal 15:22:40 "report back next week" definitely makes this not-meeting seem more and more like a meeting ;) 15:22:41 is there 1 grenade job? or do different projects use different names for that job? 15:22:44 mugsie: If we could add notes to our goal backlog etherpad, I think that would be good to capture it there. 15:22:50 smcginnis: ++ 15:22:54 fungi : the report could go to the mailing list 15:23:06 smcginnis : ++ 15:23:24 looks like we got something! 15:23:26 onto the next? 15:23:30 cool 15:23:34 ++ 15:23:42 so, checking in on project health 15:23:42 * dtroyer reads scrollback… 15:23:44 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 #topic checking in with teams 15:23:52 fungi : likely 15:23:53 fungi: ironic was first i think 15:23:57 ahh 15:23:58 "early" 15:24:13 dtantsur: would be the person to ask, or jroll 15:24:15 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 yeah, and there is still only 5 or 6 teams who have one now 15:24:21 dims : thanks 15:24:27 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 so 15:24:42 i liked smcginnis idea about splitting projects up across members :) 15:24:56 do people want me to assign them out? or do we want volunteers? 15:25:02 Seems like it would be good to spread the load. 15:25:07 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 we should also talk about exactly what we mean so we're all doing the same sort of checking 15:25:12 I'm fine with being assigned. 15:25:14 and the leftovers could be split? 15:25:22 dhellmann : fine with being assigned 15:25:30 * dtantsur appears from the shadows 15:25:32 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 mnaser: Oh, true. Like I should probably have cinder and probably glance. 15:25:38 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 ++ 15:25:50 fungi : good question 15:26:03 I was thinking at least read the meeting logs. Maybe monitor their major announcement emails. 15:26:05 so when saying check in, just maybe look at meetings? go through their reviews and see if things are healthy.. irc? 15:26:13 Talk to the PTL about whether they are experiencing any issues we can help with? 15:26:18 Generally to get a sense of things. 15:26:25 not sure if it's still important or not, but we have two working grenade plugins in the ironic world 15:26:36 your friendly neighborhood tc contact 15:26:37 should we write a script (as in movie script, not python script) or something for the initial contact? 15:26:40 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 i agree 15:27:02 makes sense dhellmann 15:27:03 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 having more of a presence and being more reachable is important 15:27:11 fungi : right. like a liaison. :-) 15:27:14 aha, so more things like brokering inter-team relationships 15:27:17 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 And being a known contact point for them if they need help. 15:27:25 smcginnis : those are good things, too 15:27:26 yeah, knowing that you can reach out to $people seems like a good thing 15:27:35 dhellmann: ++ 15:27:37 we do have this frequent conversation about whether projects are active enough to stay on the official list 15:27:44 and $people is not a group or a mailing list but someoen that you spoke to personally 15:27:49 right 15:27:50 so they might understand situations much more intimately 15:27:55 i like it 15:28:01 Like back in the old days when teams and PTLs would have a sync with ttx once a week? 15:28:08 conversely, we don't want to give teams the impression they can only reach out to their designated tc representative, right? 15:28:12 (maybe not once a week though) 15:28:17 fungi: ++ 15:28:20 i also think we should pair up on this 15:28:27 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 fungi : sure 15:28:37 fungi: Right, but some might not even realize they *can* reach out to someone on issues. 15:28:42 mnaser : yes, definitely 15:28:54 are we talking about tc guidance counselors? 15:29:00 Hah! 15:29:03 smcginnis : yeah, that seems to be the problem in the cases I had at the summit 15:29:32 Time check 15:29:34 i think we're all in agreement and seem to have a clear idea of really checking health of a team 15:29:39 3-4 minutes or so 15:29:40 i'm all for this kinder, gentler technical committee 15:29:46 do we want to discuss ways to split this up? 15:29:47 #action dhellmann make a list of project teams and TC member assignments 15:29:48 I like the idea 15:29:52 and pro-active tc :) 15:30:10 Maybe we sign up for specific projects, then out of the remaining we divy up assignments? 15:30:18 sure, we could do that 15:30:20 #undo 15:30:21 Removing item from minutes: #action dhellmann make a list of project teams and TC member assignments 15:30:24 nova wants mnaser then 15:30:30 i'll call it 15:30:30 #action dhellmann make a list of project teams for TC members to volunteer for 15:30:33 he has candy in his office 15:30:39 :> 15:30:57 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 dang! mriedem does not like me anymore 15:31:11 fungi : I'm not sure the size matters? 15:31:20 fungi: we can bikeshed once we have leftovers? 15:31:32 ^d^d^d^d 15:31:32 oh, sounded like you had initially said something about trying to sort them by some means 15:31:36 i'm sure we all have projects that are within our areas of interest 15:31:56 mnaser right i am trying to get out of my comfort zone 15:32:11 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 dims: hence the idea that we get some that we pick, but the rest we'll get assigned :) 15:32:19 the smaller teams may actually be harder to get in touch with, fwiw 15:32:19 ++ 15:32:26 that has been my experience from the release team, anyway 15:32:42 i think we've reached a good point, do we want to speak briefly about the next topic now? 15:32:48 ++ 15:33:09 ETIMEOUT no responses other than dhellmann 15:33:10 #topic organizational diversity 15:33:16 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 so, i posted a thread about this which has gathered a lot of interesting feedback 15:33:44 but an idea that has floated around which i was thinking of is linking it to releases 15:34:02 so once a project makes a release, only then does their status gets 're-evaluated' 15:34:15 that prevents having someone work on a big report at the end of cycle when we're all really busy 15:34:32 and we can still somewhat leverage our automation infrastructure, tying into the release process, to have the checks happen 15:34:38 mnaser: So are you thinking something added to our release automation that would check that? 15:34:46 Hah, yep. 15:34:48 smcginnis: something in `post` alongside the other jobs 15:34:49 yep 15:34:49 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 does that create an incentive for some projects to never release? :D 15:35:12 but we do use them all when checking contribution diversity 15:35:22 so for team:diverse-affiliation we could have team:diverse-affiliation:rocky ? 15:35:25 zaneb : the release team already has a policy of recommending dropping projects that do not release 15:35:38 mugsie: we have not decided that part yet 15:35:43 we could look into that 15:36:02 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 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 sorry, by major i meant when we do our 'openstack release', marketing pages are up, etc 15:37:29 ok 15:37:31 dhellmann: is the tag not applied to both separatly? 15:37:43 tags are applied to teams afaik, not projects/deliverables 15:37:46 mugsie : the tags are applied to the team 15:37:52 at least this tag is 15:38:00 "team:" 15:38:04 yeah, i think syncing up contributor affiliation diversity stats to just be per-cycle values makes sense 15:38:18 And teams can have cycle based and non-cycle based deliverables. 15:38:25 yes, that's another good point 15:38:44 Hasn't ttx been doing these roughly per-cycle until now? 15:38:57 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 we could just time box it - between these 2 date points the team was / was not diverse ? 15:39:10 i'm not too familiar with the intimate details of how all of this works, i volunteered myself to help out 15:39:14 smcginnis : I think so 15:39:20 but the problem with the actual caluclations still remains 15:39:29 maybe next time we sit down ttx can bring up his knowledge upon us :) 15:39:37 yes, that's a separate thing and we should talk about that, too, mugsie 15:39:49 e.g. I counted as 3 companies for a while 15:40:07 mugsie: i mean for how much work you put in, don't see whats wrong ;) hah :p 15:40:13 :D 15:40:19 mugsie: You're just a 3x developer. 15:40:35 3x the destruction of a normal one? for sure :P 15:40:39 :) 15:40:48 so that's the overall thing, maybe next time when chat ttx will be around to discuss this more 15:40:50 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 i just wanted to have a quick updates and it didnt seem like everyone is too wildly opposed to it :) 15:41:32 are you relying on the affiliation date ranges provided by the foundation member lookup api? 15:41:39 or something else? 15:41:46 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 to map affiliation at the time of the contribution 15:42:01 fungi : the foundation member api 15:42:05 but we have teams like searchlight, which are down as diverse, and have 8 commits this cycle 15:42:17 #action mnaser post suggestion of tying organizational diversity checks to releases 15:42:29 right, the question of what to do with those low volume teams is a separate part of this 15:42:34 are they still releasing? 15:42:46 maybe we should wait to decide anything until we've had the health check? 15:42:46 yeah, afaik they are 15:43:02 searchlight is our only listed maintenance mode team at this point 15:43:19 right, we don't expect lots of activity there 15:43:22 https://governance.openstack.org/tc/reference/tags/status_maintenance-mode.html 15:43:40 if the team behind it was diverse then it should stay that way if there are no new commits (imho) 15:43:56 because it is still diverse. and commits come from all different organizations 15:44:06 if one company started doing commits to it now, it'll go back to single vendor, which is also ok 15:44:08 I agree - freeze reporting on maintenance mode projects. 15:44:17 i like that 15:44:24 wfm 15:44:30 #undo 15:44:31 yup 15:44:32 Removing item from minutes: #link https://governance.openstack.org/tc/reference/tags/status_maintenance-mode.html 15:44:37 er 15:44:41 oh 15:44:43 #undo 15:44:43 Removing item from minutes: #action mnaser post suggestion of tying organizational diversity checks to releases 15:45:00 #action mnaser post suggestion of tying organizational diversity checks to releases + freezing reporting on maintenance mode projects 15:45:05 #link https://governance.openstack.org/tc/reference/tags/status_maintenance-mode.html 15:45:21 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 openstack client as help needed afaik? 15:46:03 yup - it kind of a foundational part of our UX, and there seems to be issues with review velocity 15:46:14 #topic openstack client help needed 15:46:24 yeah, dtroyer is stretched thin and we've mostly lost stevemar 15:46:30 i saw some of that bubble up in a recent ml thread 15:46:30 a member of the community pinged me about it last week, and I looked at the backlog 15:46:53 so, if dtroyer is OK with it I think we need to highlight the resource issues there 15:47:00 Since our unofficial goal has been to migrate to osc, I think it definitely needs more resources. 15:47:09 Help wanted makes sense to me. 15:47:12 smcginnis: ++ 15:47:16 https://review.openstack.org/#/q/(project:openstack/openstackclient+OR+project:openstack/openstacksdk)+is:open 15:47:37 do we want to remove anything from the existing top 5 list? or do we want to expand it? 15:47:38 https://governance.openstack.org/tc/reference/help-most-needed.html 15:47:43 steve isn't totally gone fwiw https://review.openstack.org/#/q/reviewedby:%22Steve+Martinelli+%253Cs.martinelli%2540gmail.com%253E%22 15:47:51 I did say "mostly" 15:48:05 https://review.openstack.org/#/q/project:openstack/python-openstackclient+is:open is more depressing 15:48:08 https://review.openstack.org/#/q/(project:openstack/python-openstackclient+OR+project:openstack/openstackclient+OR+project:openstack/openstacksdk)+is:open 15:48:29 as a side idea 15:48:34 what about organizing 'review-athons' 15:48:36 i did my part and reviewed one compute osc thing this week :) 15:48:43 adding tags support for servers 15:48:50 im sure a lot of members in the community can do reviews 15:48:54 i think the project teams definitely need to be more involved in reviewing their project-specific stuff in osc 15:48:57 and i'd be happy to help there 15:49:01 mriedem: ++ 15:49:06 nova core is alread ydoing this for osc-placement 15:49:18 ++ 15:49:21 we also understand the various microversion implications 15:49:41 but we need people who can also help projects outside the nova + friends group 15:49:44 i just need help at times about things like which type of command parent classes to use and such 15:49:49 forgive this wild suggestion 15:50:03 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 and work with the osc team to use topics for this thing 15:50:19 of course - there is another soluton 15:50:35 push all osc interactions to plugins, and make the teams own them 15:50:38 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 i'm not grasping what that would have to do at all with the release process 15:51:11 then the osc team has a lot less surface area to deal with 15:51:12 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 how does reviewing topical osc changes relate to release cadence? 15:51:35 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 dhellmann: its that way for everyone but 4/5 projects already 15:52:00 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 mugsie: ++ 15:52:08 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 dtroyer: sure - but you did a good job of beating them into shape :) 15:52:26 say.. kinda like requirements freeze time 15:52:46 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 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 like the emails smcginnis sends about release countdown 15:53:09 mentioning "development focus" 15:53:25 mnaser: that is a hard thing to gather though 15:53:37 s/mnaser/smcginnis/ 15:53:45 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 mugsie: Yeah... 15:54:06 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 fungi: not really, we added 2 or 3 top level command 15:54:10 +s 15:54:11 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 fungi: there are non-namespaced plugins now AIUI 15:54:33 oh, OSC doesn't namespace although it looks like that sometimes 15:54:47 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 https://github.com/openstack/python-designateclient/blob/master/setup.cfg#L90 15:54:48 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 there is a subtle differece that I can explain to anyone who hasn't heard it offline 15:55:01 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 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 :( 15:55:30 telling project cores "go review osc patches for your resource" is going to end up down a well i think 15:55:51 mriedem : we don't need project cores to do it. 15:55:52 mriedem: ++ 15:55:54 need to find liaisons or just people that care 15:55:58 right 15:56:07 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 how about "go review osc patches, or your service will be moved out into a plugin" ? 15:56:19 much like python-novaclient has (or had) different core reviewers than nova 15:56:34 fungi, mriedem: that's a good point 15:56:39 i've been saying nova needs to move off novaclient for CLI and into OSC 15:56:52 that's why i added te community wide goal to close the gap on the OSC CLIs 15:57:13 i definitely have bought into the unified CLI 15:57:16 and use it as much as possible now 15:57:20 including in new nova docs 15:57:31 mriedem: ++ 15:57:33 i want to burn "nova boot" from our lexicon 15:57:51 but, i'm only one person already stretched thin 15:57:52 we removed our cli when we jumped api versions 15:57:59 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 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 so why isn't that happening? 15:58:11 * dtroyer sends mriedem his payola check 15:58:26 zaneb: it's come up, but people get hung up on the "but osc has this 60 micorversion gap" 15:58:32 because the code is owned by the OSC project and not the Nova project? 15:58:40 ah, ok 15:58:41 fungi: does having plugins help that? 15:58:56 we have 2 minutes so maybe figuring out a conclusion would be good, or we can defer to the next discussion :) 15:58:57 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 when you install stable/pike, and the stable/pike client, you only get the relevent commands? 15:58:59 i have no clue 15:59:05 mriedem: so we're waiting for openstacksdk 1.0, really 15:59:10 this is where maintainers have to care and take on the work 15:59:22 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 makes sense 15:59:50 anyone want to propose some sort of action out of this discussion before we wrap up? 15:59:55 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 Official times up. 16:00:03 people don't care if they can access their feature with a client?? 16:00:07 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 dhellmann: yeah, we need a list I think 16:00:22 i can figure out what the nova microversion gap is in osc 16:00:27 that's an action i've been meanning to do anyway 16:00:30 sign me up 16:00:38 #action mriedem figure out the nova microversion gap in osc 16:00:56 mriedem: remember we don't need to support every microversion, just the ones needed by each command 16:01:03 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 and sdk goes a long way in helping do that 16:01:10 dtroyer: sure i know 16:01:30 lots of microversions in nova are on admin stuff that's not in osc 16:01:41 which has been another reason people keep doing them in novaclient 16:01:42 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 dilemma 16:02:11 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 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 fungi : that split may make less sense now that we have more work and fewer people 16:03:29 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 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 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 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 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 as an action to kick off 16:05:12 fungi: also, keeping the dep list for SDK really small helps a lot for co-installability 16:05:12 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 mugsie : and don't forget to pull the board member volunteers into that discussion 16:06:05 OK - who is collecting info? all I have is "needs reviewers" 16:06:25 * mordred reading scrollback 16:06:36 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 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 yeah - I definitely won;t have any extra time in the next 7 days for it either :/ 16:07:41 I will help as much as I can, but I'm totally interrupt-driven these days :( 16:07:42 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 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 but I'll definitely directly work on it 16:09:31 I added OSC to the tracker: https://wiki.openstack.org/wiki/Technical_Committee_Tracker#finding_help_for_the_unified_CLI_team 16:09:34 you have personal time? 16:09:37 what a luxury 16:09:38 mriedem: wel 16:10:31 are we winding down? should we close out the meeting log? 16:10:43 Probably, we are over the hour. 16:10:45 ++ 16:10:46 Well over. :) 16:10:48 sure, i was just checking to see if the conversation had died down sufficiently 16:10:52 #endmeeting