19:01:07 <clarkb> #startmeeting infra
19:01:08 <openstack> Meeting started Tue Jan  7 19:01:07 2020 UTC and is due to finish in 60 minutes.  The chair is clarkb. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:01:09 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:01:11 <openstack> The meeting name has been set to 'infra'
19:01:16 <clarkb> #link http://lists.openstack.org/pipermail/openstack-infra/2020-January/006568.html Our Agenda
19:01:25 <clarkb> Not a whole lot on the agenda
19:01:36 <clarkb> I think most of us are catching up on things after holidays
19:01:42 <clarkb> #topic Announcements
19:01:53 <zbr|rover> o/o/
19:01:59 <clarkb> Happy new year and welcome back! that is all I had for announcements
19:02:10 <AJaeger> o/
19:02:11 <clarkb> #topic Actions from last meeting
19:02:17 <clarkb> #link http://eavesdrop.openstack.org/meetings/infra/2019/infra.2019-12-17-19.01.txt minutes from last meeting
19:02:31 <clarkb> No actions from last meeting. It was pretty low key as I expect today to be.
19:02:36 <clarkb> #topic Priority Efforts
19:02:41 <clarkb> #topic OpenDev
19:03:01 <clarkb> First up on this mordred has a change to upgrade gitea to 1.10.2 ready to go
19:03:12 <clarkb> reading the changelog I don't expect this will fix the weird git bug we've notice
19:03:22 <clarkb> but seems to include a fair number of other bug fixes
19:04:32 <clarkb> The other opendev subject is the governance draft email thread
19:04:35 <clarkb> #link http://lists.openstack.org/pipermail/openstack-infra/2019-December/006537.html Governance email
19:04:59 <mordred> yah. I don't expect it to be a noticable upgrade
19:05:01 <clarkb> I'd like to bring that up with the openstack TC soon and start moving this process officially
19:05:08 <mordred> but figure it's best to keep on the latest to keep deltas down
19:05:18 <mordred> I did check the templates and there are no relevant template changes
19:05:30 <clarkb> maybe give it until next week for further feedback and for people to return from holidays on both our side and the TC side then bring it up in an office hour there?
19:05:46 <clarkb> fungi: ^ you probably have a good read on the best way to reach out to them. Would starting with a governance change be better?
19:07:19 <fungi> what would the governance change entail?
19:07:19 <clarkb> mordred: ++ on keeping up with them
19:07:42 <fungi> removing projects from the projects.yaml?
19:07:45 <clarkb> fungi: at the very least we'd edit the governance reference project.yaml file to remove the opdnev bits of infra
19:07:52 <fungi> yeah, okay, that makes sense
19:08:02 <fungi> i don't see any reason to delay on proposing that change
19:08:27 <fungi> the official way to "reach out" to the openstack tc is to send e-mail to the openstack-discuss mailing list with [tc] in the subject
19:08:52 <fungi> but also following up with them in one of the office hours (thursdays are the best-attended) can't hurt
19:09:06 <clarkb> k, I guess I can propose the change then send email pointing to the change and our thread on the subject and take it from there
19:09:19 <clarkb> I'll put that on my list of things for next week to give anyone last chance at further input on our thread
19:09:20 <fungi> and there's a scheduled monthly irc meeting for next week you could get some announcement on the agenda for if you wanted, there's time
19:09:47 <clarkb> #action clarkb push openstack governance change to pull out opendev and start discussion with tc via openstack-discuss
19:11:01 <clarkb> Anything else on opendev before we continue?
19:12:18 <clarkb> #topic Update Config Management
19:12:47 <clarkb> mordred: I think there has been some movement on review-dev's containerization. The change to switch it over merged but wasn't applied when I last looked (pre holiday) beacuse the hsot was in the emergency file
19:13:01 <clarkb> mordred: is that still the case or are we automating the containerized deployment of gerrit on -dev now?
19:13:20 <mordred> no - still the case - I hadn't dug in fully on that yet because holidays
19:13:24 <mordred> let's get that finished this week
19:13:32 <mordred> I landed a few more of the patches
19:14:02 <clarkb> #action mordred finish up switch to automated container deployment of Gerrit on review-dev. Changes are landing but need to remove -dev from the emergency file.
19:14:12 <clarkb> mordred: ^ does that capture it?
19:14:36 <mordred> https://review.opendev.org/#/c/691800/ https://review.opendev.org/#/c/692003 and https://review.opendev.org/#/c/691777/ could each use one more reviewer
19:14:42 <mordred> clarkb: yup
19:15:12 <clarkb> heh they have three different reviewers too. I've pulled them up and will try to get to the two I haven't read yet
19:15:14 <mordred> also unrelated but related, https://review.opendev.org/#/c/690505 needs a 2nd
19:16:33 <clarkb> Are there any other configuration mgmt migration related changes or topics to discuss?
19:18:07 <clarkb> #topic General Topics
19:18:31 <clarkb> fungi: any movement on the wiki? I expect not considering your boat touring
19:19:00 <fungi> nope
19:19:11 <fungi> i need to refresh my memory on where i left off
19:19:19 <clarkb> k
19:19:29 <clarkb> For the static.openstack.org migration ianw has some chagnes that need reviewing
19:19:38 <clarkb> #link https://review.opendev.org/#/q/status:open+topic:static.opendev.org Next up on static.o.o migration
19:19:39 <fungi> i remember i got openid auth working, but i think i needed to do some more with extensions
19:20:21 <clarkb> if others can help review those that will be great. They are on my list along with mordred's now
19:20:48 <clarkb> I think ianw returns next week and would be good to have those changes sorted and ready before that
19:21:59 <mordred> yay ianw returning!
19:22:05 <clarkb> That takes us to project renames. There is a single project requesting a rename.
19:22:25 <fungi> any idea on the degree of urgency around it?
19:23:01 <clarkb> oh you know what
19:23:16 <clarkb> I think this ended up being a retire in place then fork if development wanted to continue situation
19:23:18 <clarkb> rather than a true rename
19:23:29 <AJaeger> clarkb: that's not a rename, drop it.
19:23:34 <clarkb> AJaeger: thank you for confirming
19:23:35 <fungi> yeah, if it was a repo move out of the openstack namespace, then it's not a rename
19:23:37 <AJaeger> we retired completely - and reimported
19:23:43 <clarkb> ok we don't need to schedule a downtime
19:23:54 <AJaeger> so, nothing more for us to do - let me remove from wiki
19:23:55 <clarkb> I'll update our agenda to reflect this
19:23:59 <clarkb> oh go for it AJaeger thank you
19:24:38 <fungi> openstack tc policy is that once a repository is an official deliverable, it can't ever move out of the openstack namespace because consumers of the source code may not discover that it's ceased being part of openstack otherwise
19:25:14 <fungi> so they require those projects to fork and the originals retired
19:26:19 <clarkb> I was going to suggest the week ending january 24 as a good gerrit downtime option but that doesn't seem necessary now. That said depending on how mordred's gerrit container work goes that may still be a good opportunity for a downtime to siwtch things over then
19:26:31 <fungi> seems reasonable to me
19:27:26 <mordred> clarkb: I will be on PTO the week ending jan 24 - but depending on how the conatiner work is before then maybe?
19:27:40 <clarkb> mordred: or the week after looks pretty clear too
19:27:44 <clarkb> no rush!
19:27:46 <mordred> ++
19:28:13 <fungi> i'll be transiting to/from fosdem at the end of the month, so may not be around depending on the day
19:28:48 <fungi> specifically, i'll be on airplanes the 30th/31st
19:28:56 <fungi> if that's the proposal
19:29:27 <fungi> but if others are around to help, that shouldn't be a blocker
19:29:51 <clarkb> ya we'll sort it out once we've got -dev cut over
19:30:00 <clarkb> This takes us to our regularly scheduled agenda
19:30:05 <clarkb> #topic Open Discussion
19:30:15 <AJaeger> Do we still need these repos: x/pbrx, x/dox, openstack/js-openstack-lib - or shall I retire one of these?
19:30:57 <corvus> mordred: ^ i'm pretty sure the 1st 2 are retirable?
19:31:15 <mordred> x/pbrx and x/dox should both be retirable
19:31:31 <AJaeger> ok, will take care of these two
19:31:38 <mordred> I don't know anything about openstackj/js-openstack-lib - If the horizon team isn't using it
19:31:54 <fungi> mordred: i noticed pbrx is in the openstackclient requirements.txt
19:31:56 <mordred> I believe that was written originally as an attempt to be like openstacksdk but in javascript
19:31:56 <clarkb> the js repo is very quiet, but ya double checking with horizon would probably be a good thing
19:32:06 <mordred> fungi: aroo?
19:32:08 <fungi> you might want to hunt around for anything using pbrx before retiring
19:32:11 <mordred> oh - I think it's using ... yeah
19:32:15 <mordred> wait - don't retire it
19:32:26 <mordred> there's two things in pbrx - the container stuff which we stoppped using
19:32:38 <mordred> and the siblings logic - so that people can do a siblings install locally
19:32:57 <fungi> so maybe pbrx just becomes the latter bits?
19:33:11 <mordred> yeah - maybe that's the best idea
19:33:21 <AJaeger> according to codesearch nobody uses js-openstack-lib
19:33:29 <AJaeger> But I can ask amotoki
19:33:50 <AJaeger> so, no retiring of pbrx - ok
19:33:53 <mordred> AJaeger: yeah. my hunch is that it's fine
19:34:08 <mordred> (to retire js-openstack-lib)
19:34:14 <mordred> but asking amotoki sounds great
19:34:25 <clarkb> unrelated, the airship team is trying to figure out how to run their testing on our CI system. The avenue they seem to be pushing for is to add an airship specific cloud to nodepool that can run jobs on very large (60GB ram?) test nodes. They need a lot of memory to run large nested VMs which I've tried to point out is often unreliable and with a single cloud backend would result in lots of
19:34:26 <clarkb> flakyness. Better instead to run multinode jobs to spread the load on smaller test nodes and then they can run in many clouds. But to get a better understanding of their actual requirements set up a call at 1600UTC thursday with them. I suggested we use room 6001 on pbx
19:34:30 <AJaeger> So, my proposal: I'll check with amotoki about js-openstack-lib and then send email to retire x/dox and js-openstack-lib.
19:34:49 <clarkb> others are more than welcome to join the call. If they can't get pbx working my plan was to try meet.jit.si as an alternative
19:35:12 <Shrews> clarkb: which cloud?
19:35:40 <clarkb> Shrews: I believe it would be a private cloud run by one of their interested parties
19:35:44 <clarkb> (not a public cloud)
19:35:50 <Shrews> ah
19:35:58 <Shrews> i was about to have objections  :)
19:36:32 <fungi> you can still have objections
19:36:43 <Shrews> fungi: i object to that
19:36:49 <mordred> clarkb: obviously it would be better if they could provide two clouds
19:37:21 <clarkb> mordred: yup! they did mention that could potentially be a possibility :) but sounded like not part of their day one planning
19:37:22 <mordred> but - given seems worthwhile to at least have a call about it
19:37:28 <fungi> obviously it would be better if they could provide two clouds into the aggregate pool and just use normal resources
19:37:45 <mordred> yeah - it's hard to fund two clouds when there isn't a POC of the system running on the first on eyet I could imagine
19:38:24 <fungi> tripleo-ci cloud syndrome
19:38:26 <corvus> the fact that these would be unavailable to other tenants of the system is a concern
19:38:27 <clarkb> in any case sounds like they may have the testing running internally already but they want to push it upstream if possible and so we need to sort out where the balance is between existing test methods and existing upstream ci resources (that may be augmentable)
19:38:54 <clarkb> and I'm hoping the phone call gives us a better understanding of their side so that we can propose more valuable solutions
19:38:57 <mordred> sounds like the call will be useful in hammering stuff out
19:39:31 <corvus> yeah
19:39:55 <fungi> we already don't have the ability to prevent other users from running jobs on an environment attached to our nodepool, right?
19:40:05 <clarkb> fungi: correct
19:40:19 <clarkb> any restrictions there would have to be via convention at this point I think
19:41:13 <fungi> i'm fine with taking a hard line that tenant-scoped resources (whether enforced or merely unadvertised) is unacceptable for opendev's nodepool
19:42:31 <fungi> companies and private individuals are already donating a lot of resources which they generously allow to be used by all projects in opendev
19:43:19 <fungi> but also maintaining connections to environments exclusive to specific projects is a lot of administrative overhead which only benefits that project
19:43:27 <clarkb> ya I lean that way too. That said I can contrive some examples in my head where restricting access comes with a reasonable argument.
19:43:41 <clarkb> Things like gpu enabled hardware
19:44:32 <fungi> i think we can ask people not to abuse access to resources, and reach out to them about augmenting those resources if they have a need for them on a regular basis
19:46:22 <clarkb> yup. Seems reasonable to set guidelines for access to more spceial resources, but then allow anyone that shows a need for the special stuff and follows the guidelines to participate
19:46:56 <fungi> now i just need to try to remember those points so we don't forget to raise them on the call ;)
19:47:47 <clarkb> Anything else?
19:47:55 <clarkb> if not I'll probably call the meeting early
19:48:36 <fungi> i've got nothing
19:49:12 <clarkb> #endmeeting