15:00:12 #startmeeting releaseteam 15:00:13 Meeting started Fri Jun 22 15:00:12 2018 UTC and is due to finish in 60 minutes. The chair is smcginnis. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:14 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:00:16 The meeting name has been set to 'releaseteam' 15:00:19 Ping list: dhellmann, dims, fungi, tonyb, lbragstad, ttx, armstrong, annabelleB 15:00:20 o/ 15:00:25 o/ 15:00:29 o/ 15:00:41 ohai 15:00:44 o/ 15:01:00 Wow, everyone's quick today. :) 15:01:04 #agenda https://etherpad.openstack.org/p/rocky-relmgt-tracking 15:01:26 * dhellmann is listening to the last few minutes of an all-hands 15:01:27 ~line 331 15:02:05 #topic ACL fixing 15:02:09 I wanted to give a quick status update on the ACL normalization exercise 15:02:17 #link https://storyboard.openstack.org/#!/story/2001831 15:02:22 It's going well, we are down to 3 things to handle 15:02:38 Sorry, I realize now I didn't link the two I did to the story. 15:02:43 o/ 15:02:46 I had a question for dhellmann re: murano-image-elements 15:03:09 So they do (rarely) tag but when they need to they do 15:03:26 The tag triggers legacy-manila-publishimage-generic as a release job 15:03:46 Which makes me think that it would fail tests if we pushed that through openstack/releases 15:03:55 is that assumption correct ? 15:03:56 * elbragstad lingers 15:04:11 probably. we can add a release-type to deal with it. we have custom release jobs for some other projects. 15:04:27 dhellmann: would that be your preffered way to solve it ? 15:04:34 -f+r 15:04:56 if we're going to take on tagging, I think that's the right approach. I guess the alternative is to let them keep tagging on their own? 15:05:00 (the other would be to keep them as exception I guess) 15:05:04 yes 15:05:15 OK, I'll submit something to that effect 15:05:20 it will only take a few minutes to add the release type 15:05:31 s/murano-image-elements/manila-image-elements/ 15:05:48 is that 2 things? or did we get the name wrong? 15:05:53 The second leftover is around Helm, which I'll handle as I do their TC health check next week 15:06:07 The third leftover is smcginnis's around Rally 15:06:13 Just correcting the name from earlier in case their was confusion. 15:06:26 ok 15:06:51 what do we want to do with rally? 15:07:00 smcginnis: any update on that ? Shoudl we wait for a TC health check that would dive into their GitHub partial migration ? 15:07:04 I just left a comment on the ACL patch for Andrey. 15:07:18 He had indicated he just needed a few days before. 15:07:21 There is little point in fixing the ACL if they move dev under GitHub 15:07:38 so an idea of their long term plans could be useful 15:07:48 yes, i feel like if they'd rather relocate to github, more power to them 15:07:59 I was under the impression that was a longer term plan, but yeah, the TC health check might help get a better idea what the plan is there. 15:08:19 assuming they're also looking to exit being an official openstack team, i mean 15:08:22 We'll see what he says on the patch too. 15:08:38 Given what appears to be their broader scope, I suppose that makes sense. 15:08:53 yeah, I think a move to github would necessarily mean dropping them from current governance 15:08:57 ok, last point -- it's good that we limited the exception list, but if we don't test it regularly, I assume new ACL issues will get introduced 15:09:25 if only because new projects get "official" and retain legacy ACLs 15:09:47 So I wanted to discuss the best way to run that as a check regularly 15:10:13 (the script is actually making the fix rather than testing for the need for a fix, but should be able to evolve it easily) 15:10:17 this is where that checklist we were going to put together would help 15:10:32 should it be run as a check against governance changes? 15:10:33 ++ 15:10:41 dhellmann: the checklist won't prevent accidental reintroduction 15:10:59 maybe we need a check in governance and in project-config? 15:11:10 dhellmann: yes, since issues can be introduced from both 15:11:23 although if we're going to have exceptions, writing the test job will be interesting 15:11:58 i suppose i can see the infra team supporting custom approval checks from various stakeholder projects 15:12:00 Maybe we need to move that exception list? 15:12:09 though we'll probably want a bit of formality around that relationship 15:12:21 Alternatively we could just check at every milestone 15:12:21 I think we said we didn't want to block governance changes to add repos, and that's why we didn't want a check there? 15:12:37 can we have a periodic job that sends email? 15:12:38 It's not as if there was urgency to block it 15:12:41 so we don't have to remember to do it? 15:12:47 Or a -nv job? 15:13:19 just remember that if we allow openstack to have special project configuration checks against project-config, then we need to also allow zuul, kata, whoever to do similar things so i want to make sure we think through the policy implications/sla there 15:13:47 For simplicity I would go with periodic/mailing, or some milestone task 15:13:54 fungi : sure. that's another reason a periodic job that is defined somewhere else and reports warnings, rather than causing failures, may be better 15:14:19 basically an interface to say "this project is listed as an official component of and the proposed alterations don't match the policies set forth by governance" 15:14:26 We do already have milestone tasks defined in our process doc. We could easily add a check to be run at one or multiple points too. 15:14:37 dhellmann, smcginnis: how about we keep it as a manual task run around milestones for now. 15:14:41 maybe that's good enough then, if we have it scripted 15:14:41 yeah 15:14:52 And automate it if it ends up being a pain or we miss it too often 15:14:56 ++ 15:15:00 That sounds good for now. 15:15:05 I'll make sure it can run in test mode 15:15:18 we could use the described interface to also check things like whether dco is enforced on kata repos (if they move to our gerrit) but check whether a cla is enforced for openstack repos 15:15:40 so i can see some good arguments for allowing projects to encode policy like that 15:16:03 OK, added tasks 15:16:36 but i thnik that if we do go for a project-config job to that end, we want the various projects to own their policy checks and not have the infra team manitaining those 15:17:04 yeah, if we go through that process it should be for something more critical/valuable 15:17:04 Hmm, but we also want some oversight on those policies I think. 15:17:05 so that we don't insert ourselves in other projects' governance matters 15:17:06 fungi : yeah, that makes sense. 15:17:24 Those ACL fixes are more a samity check 15:17:29 At least for TC governed projects. 15:17:32 saNity 15:17:41 right 15:17:50 so anyway, an option to keep in the back of our minds 15:17:55 ++ 15:18:50 Sorry, for m-i-e, did we decide a new release type is needed for that? 15:18:50 smcginnis: dhellmann: would y'all prefer that the script clones governance and project-config, or takes arguments that point to already checked-out repos ? 15:19:13 the two aren't mutually exclusive 15:19:14 Currently it does the latter, so that it modifies files directly 15:19:24 We have some other automation that just pulls out the files it needs from those repos. Would that work here? 15:19:33 smcginnis : yes, I'll make a note of that 15:19:39 and you'd want to at least support the latter so that you can use zuul depends-on sanely 15:19:53 dhellmann: Thanks 15:20:04 assuming you want to also have the option of making it a periodic job or something later 15:20:42 I'm OK with it either way. I keep a directory full of a bunch of the release-related repos like project-config anyway 15:20:51 right me too. OK 15:20:56 Thanks 15:21:00 15:21:04 #topic Tasks 15:21:17 Just a quick follow up from tasks we put down from last week. 15:21:25 fungi: Any update on the release-tools repo retirement? 15:21:39 nope, i have it up in a terminal and the checklist in a browser tab 15:21:47 so, er, hoping to start shortly 15:22:00 just juggling backlog 15:22:03 OK, I'll move that out a couple weeks for us to follow up on just to make sure. 15:22:07 I know that feeling. 15:22:19 The other task was for me to check in with annabelleB. 15:22:25 Hi annabelleB o/ 15:22:29 yes! i’ve been thinking about this as well so good timing1 15:22:39 annabelleB: Awesome 15:23:00 is that the right place to put a little more info on how people should fill out cycle-highlights? 15:23:08 annabelleB: We can talk later and come up with details. Just wanted to make sure we eventually get something there. 15:23:29 I think a mention there might be good, but we can also look if there is anywhere else that makes more sense to have more details. 15:23:37 sounds good. I can take a stab at a draft and we can go from there 15:23:46 Perfect, thanks! 15:24:00 #topic Finishing python 3 port of tools 15:24:20 #link https://review.openstack.org/#/c/577291/ Last patch in the series 15:24:21 patch 577291 - openstack-infra/project-config - use python3 to run launchpad commenting script 15:24:40 #link https://storyboard.openstack.org/#!/story/2001691 Tracking story 15:24:50 dhellmann: Anything you wanted to discuss, or just bring up for awareness? 15:25:15 I was hoping to get fungi to take a look at that so I could test the results later today or early next week 15:25:28 yeah, i have it pulled up in gertty as we speak 15:25:32 cool, thanks 15:26:19 I believe that was the last remaining step in being able to say the tag-releases job runs under python 3 15:26:42 by any chance, has anyone looked at installing launchpadlib from pypi? looks like it's publishing there recently 15:26:47 Luckily no major surprises with all of that. 15:27:18 fungi : I started to look at it, and realized that job needs to use system packages because of security, so I went that route instead (see the depends-on) 15:27:26 ahh, right 15:27:33 thanks for the reminder ;) 15:27:34 so I may have been waiting for something I didn't need to wait for, all this time :-/ 15:27:57 dhellmann: Hmm, why is it that it needs system packages? 15:28:00 that'll make it interesting to get the storyboard commenting step implemented 15:28:17 i've also (barely) started on that piece, yes 15:28:19 smcginnis : we don't (or try not to) pip install stuff into jobs that have access to secrets 15:28:31 i'll make sure the sb commenting is py3k from the outset 15:28:36 Aahh, that makes sense. 15:28:56 we could move the updating step to a separate job, so we can use pip to install pieces to talk to storyboard 15:29:04 yeah, in theory we get a bit more vetting from distro packages 15:29:25 although I'm not even sure if the storyboard client has been released yet, so we may just want to use requests directly 15:29:43 the api calls we need will be simple, that much i already know 15:29:45 If it's a simple enough rest API, that might be best. 15:30:00 Less dependencies == goodness 15:30:36 That's all for the agenda. Anything else? 15:30:48 I couldn't figure out if there was another way to set up the bindep entry for that job, so I added it to the releases repo since that's what triggers the job. it would be nice if there was a way to add it directly in the job definition. although I guess I could have just used an apt task for that. 15:31:07 that's all I had for today 15:31:33 That's a good point. Ansible's pretty good for things like that I hear. :) 15:31:57 package might be better than apt though. 15:32:11 Not that I see things changing significantly there. 15:32:14 Anyway... 15:32:25 I guess that's all for today. Thanks everyone! 15:32:38 yeah, if you want to add packages directly in a job, using ansible primitives is your best bet 15:33:01 thanks all! 15:33:17 #endmeeting