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