19:01:07 #startmeeting infra 19:01:08 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 19:01:11 The meeting name has been set to 'infra' 19:01:16 #link http://lists.openstack.org/pipermail/openstack-infra/2020-January/006568.html Our Agenda 19:01:25 Not a whole lot on the agenda 19:01:36 I think most of us are catching up on things after holidays 19:01:42 #topic Announcements 19:01:53 o/o/ 19:01:59 Happy new year and welcome back! that is all I had for announcements 19:02:10 o/ 19:02:11 #topic Actions from last meeting 19:02:17 #link http://eavesdrop.openstack.org/meetings/infra/2019/infra.2019-12-17-19.01.txt minutes from last meeting 19:02:31 No actions from last meeting. It was pretty low key as I expect today to be. 19:02:36 #topic Priority Efforts 19:02:41 #topic OpenDev 19:03:01 First up on this mordred has a change to upgrade gitea to 1.10.2 ready to go 19:03:12 reading the changelog I don't expect this will fix the weird git bug we've notice 19:03:22 but seems to include a fair number of other bug fixes 19:04:32 The other opendev subject is the governance draft email thread 19:04:35 #link http://lists.openstack.org/pipermail/openstack-infra/2019-December/006537.html Governance email 19:04:59 yah. I don't expect it to be a noticable upgrade 19:05:01 I'd like to bring that up with the openstack TC soon and start moving this process officially 19:05:08 but figure it's best to keep on the latest to keep deltas down 19:05:18 I did check the templates and there are no relevant template changes 19:05:30 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 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 what would the governance change entail? 19:07:19 mordred: ++ on keeping up with them 19:07:42 removing projects from the projects.yaml? 19:07:45 fungi: at the very least we'd edit the governance reference project.yaml file to remove the opdnev bits of infra 19:07:52 yeah, okay, that makes sense 19:08:02 i don't see any reason to delay on proposing that change 19:08:27 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 but also following up with them in one of the office hours (thursdays are the best-attended) can't hurt 19:09:06 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 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 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 #action clarkb push openstack governance change to pull out opendev and start discussion with tc via openstack-discuss 19:11:01 Anything else on opendev before we continue? 19:12:18 #topic Update Config Management 19:12:47 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 mordred: is that still the case or are we automating the containerized deployment of gerrit on -dev now? 19:13:20 no - still the case - I hadn't dug in fully on that yet because holidays 19:13:24 let's get that finished this week 19:13:32 I landed a few more of the patches 19:14:02 #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 mordred: ^ does that capture it? 19:14:36 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 clarkb: yup 19:15:12 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 also unrelated but related, https://review.opendev.org/#/c/690505 needs a 2nd 19:16:33 Are there any other configuration mgmt migration related changes or topics to discuss? 19:18:07 #topic General Topics 19:18:31 fungi: any movement on the wiki? I expect not considering your boat touring 19:19:00 nope 19:19:11 i need to refresh my memory on where i left off 19:19:19 k 19:19:29 For the static.openstack.org migration ianw has some chagnes that need reviewing 19:19:38 #link https://review.opendev.org/#/q/status:open+topic:static.opendev.org Next up on static.o.o migration 19:19:39 i remember i got openid auth working, but i think i needed to do some more with extensions 19:20:21 if others can help review those that will be great. They are on my list along with mordred's now 19:20:48 I think ianw returns next week and would be good to have those changes sorted and ready before that 19:21:59 yay ianw returning! 19:22:05 That takes us to project renames. There is a single project requesting a rename. 19:22:25 any idea on the degree of urgency around it? 19:23:01 oh you know what 19:23:16 I think this ended up being a retire in place then fork if development wanted to continue situation 19:23:18 rather than a true rename 19:23:29 clarkb: that's not a rename, drop it. 19:23:34 AJaeger: thank you for confirming 19:23:35 yeah, if it was a repo move out of the openstack namespace, then it's not a rename 19:23:37 we retired completely - and reimported 19:23:43 ok we don't need to schedule a downtime 19:23:54 so, nothing more for us to do - let me remove from wiki 19:23:55 I'll update our agenda to reflect this 19:23:59 oh go for it AJaeger thank you 19:24:38 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 so they require those projects to fork and the originals retired 19:26:19 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 seems reasonable to me 19:27:26 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 mordred: or the week after looks pretty clear too 19:27:44 no rush! 19:27:46 ++ 19:28:13 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 specifically, i'll be on airplanes the 30th/31st 19:28:56 if that's the proposal 19:29:27 but if others are around to help, that shouldn't be a blocker 19:29:51 ya we'll sort it out once we've got -dev cut over 19:30:00 This takes us to our regularly scheduled agenda 19:30:05 #topic Open Discussion 19:30:15 Do we still need these repos: x/pbrx, x/dox, openstack/js-openstack-lib - or shall I retire one of these? 19:30:57 mordred: ^ i'm pretty sure the 1st 2 are retirable? 19:31:15 x/pbrx and x/dox should both be retirable 19:31:31 ok, will take care of these two 19:31:38 I don't know anything about openstackj/js-openstack-lib - If the horizon team isn't using it 19:31:54 mordred: i noticed pbrx is in the openstackclient requirements.txt 19:31:56 I believe that was written originally as an attempt to be like openstacksdk but in javascript 19:31:56 the js repo is very quiet, but ya double checking with horizon would probably be a good thing 19:32:06 fungi: aroo? 19:32:08 you might want to hunt around for anything using pbrx before retiring 19:32:11 oh - I think it's using ... yeah 19:32:15 wait - don't retire it 19:32:26 there's two things in pbrx - the container stuff which we stoppped using 19:32:38 and the siblings logic - so that people can do a siblings install locally 19:32:57 so maybe pbrx just becomes the latter bits? 19:33:11 yeah - maybe that's the best idea 19:33:21 according to codesearch nobody uses js-openstack-lib 19:33:29 But I can ask amotoki 19:33:50 so, no retiring of pbrx - ok 19:33:53 AJaeger: yeah. my hunch is that it's fine 19:34:08 (to retire js-openstack-lib) 19:34:14 but asking amotoki sounds great 19:34:25 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 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 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 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 clarkb: which cloud? 19:35:40 Shrews: I believe it would be a private cloud run by one of their interested parties 19:35:44 (not a public cloud) 19:35:50 ah 19:35:58 i was about to have objections :) 19:36:32 you can still have objections 19:36:43 fungi: i object to that 19:36:49 clarkb: obviously it would be better if they could provide two clouds 19:37:21 mordred: yup! they did mention that could potentially be a possibility :) but sounded like not part of their day one planning 19:37:22 but - given seems worthwhile to at least have a call about it 19:37:28 obviously it would be better if they could provide two clouds into the aggregate pool and just use normal resources 19:37:45 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 tripleo-ci cloud syndrome 19:38:26 the fact that these would be unavailable to other tenants of the system is a concern 19:38:27 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 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 sounds like the call will be useful in hammering stuff out 19:39:31 yeah 19:39:55 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 fungi: correct 19:40:19 any restrictions there would have to be via convention at this point I think 19:41:13 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 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 but also maintaining connections to environments exclusive to specific projects is a lot of administrative overhead which only benefits that project 19:43:27 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 Things like gpu enabled hardware 19:44:32 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 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 now i just need to try to remember those points so we don't forget to raise them on the call ;) 19:47:47 Anything else? 19:47:55 if not I'll probably call the meeting early 19:48:36 i've got nothing 19:49:12 #endmeeting