Thursday, 2022-02-03

clarkb passes CI now (though it doesn't run the gerrit image builds jobs (I think because Dockerfile wasn't udpated) I suppose that is probably good enough00:03
clarkbThanks for all the reviews. Feels good to get that stuff out of my dashboard :)00:04
opendevreviewMerged opendev/system-config master: Add CentOS SIGs for CentOS Stream 9 to AFS mirrors
*** rlandy|ruck is now known as rlandy|out00:22
opendevreviewMerged opendev/system-config master: Switch nb01 to focal in testing
opendevreviewMerged zuul/zuul-jobs master: Add CentOS Stream 9 to configure-mirrors role
opendevreviewMerged zuul/zuul-jobs master: Change RDO train repository for Centos 8 stream
opendevreviewIan Wienand proposed openstack/project-config master: Remove Fedora 34
*** pojadhav|afk is now known as pojadhav03:16
opendevreviewIan Wienand proposed zuul/zuul-jobs master: ensure-sphinx: Use python3
opendevreviewIan Wienand proposed zuul/zuul-jobs master: ensure-virtualenv: Don't support on CentOS 9-stream
opendevreviewMerged opendev/system-config master: Stop building Gerrit 3.3 images
*** marios is now known as marios|ruck06:03
*** anbanerj is now known as frenzyfriday06:04
*** ysandeep|out is now known as ysandeep06:23
*** amoralej|off is now known as amoralej07:26
*** ysandeep is now known as ysandeep|lunch09:23
*** ysandeep|lunch is now known as ysandeep10:30
*** rlandy|out is now known as rlandy|ruck11:13
*** dviroel|out is now known as dviroel11:16
*** pojadhav is now known as pojadhav|brb11:57
*** ysandeep is now known as ysandeep|afk12:08
*** dviroel is now known as dviroel|biab12:10
*** pojadhav|brb is now known as pojadhav12:10
*** dviroel|biab is now known as dviroel12:27
lourotclarkb, re: the git `main` experiment, this repo I'm trying to import is a fork of an existing charm where everything is in place. I don't have the capacity right now to write a dummy new repo. It would probably take me two hours at least to get it straight. Cloning this existing repo just took me 2 minutes. Is this really a problem?12:39
lourotclarkb, would it be a good compromise if I just squash the entire history to one commit?12:41
lourotthere isn't that much code, just a huge history12:43
*** amoralej is now known as amoralej|lunch13:00
*** ysandeep|afk is now known as ysandeep13:01
*** dviroel is now known as dviroel|ruck13:44
*** akahat is now known as akahat|rover13:45
*** dviroel|ruck is now known as dviroel13:48
*** akahat|rover is now known as akahat13:56
*** amoralej|lunch is now known as amoralej14:19
mnasiadkaHello infra-root, would need assistance in holding nodes in kolla-ansible-centos8s-source-cephadm job in change - can't reproduce failure in any environment14:24
* frickler goes to set up a hold14:35
fungifrickler: note that the workaround i found for --change not working with zuul-client autohold was instead to set --ref=refs/changes/de/abcde/f14:36
fungithough i think the rpc cli may still work14:37
fricklerfungi: I've only ever used --ref for that, but thanks for the reminder14:37
fricklermnasiadka: since you just rechecked, those should be ready pretty soon, can you also let me know your ssh public key?14:40
mnasiadkafrickler: sent privately, don't want to spam the channel :)14:42
opendevreviewRodion proposed zuul/zuul-jobs master: Implement  role
opendevreviewRodion proposed zuul/zuul-jobs master: Implement ensure-foreleaser role
opendevreviewRodion proposed zuul/zuul-jobs master: Implement ensure-goreleaser role
fricklerwow, wonder how many iterations it will take for this newcomer to learn about amending patches. I'll try to leave a helpful comment15:25
clarkblourot: if we leave out the upstream then we get a default repo. But I guess that may not be a representative test. As far as the issue, it just means that all the gerrit maintenance tasks like reindexnig will take a little longer.15:45
clarkblourot: compared to weekly work efforts on gerrit it is tiny, but in the past we literally made like 2 extra copies of all of openstack without thinking twice and it bugs me since then :)15:46
lourotclarkb, right now it's 15M with the big history. I think if I squash the entire history it'll be very tiny15:49
clarkblooks like gerrit upstream has abandoned the prior 3.4 into 3.5 merge changes and done one large all encompassing change for that. Including the reload4j and acl fixes I wrote15:54
fungioh, that simplifies matter for us the15:54
frickleroh, if we just want to test importing a project with default branch main, we could use, I've been thinking to do that anyway, and it likely could stay and not be deleted afterwards. I'm just unsure whether to use the x/ namespace or maybe do cirros/cirros?15:58
fungifrickler: i would probably do cirros/cirros, the x/ namespace was mostly an artifact of mass migration for projects who didn't request a namespace of their own15:59
*** dviroel is now known as dviroel|lunch16:02
opendevreviewClark Boylan proposed opendev/system-config master: Add Gerrit 3.5 image builds and testing
opendevreviewClark Boylan proposed opendev/system-config master: Test Gerrit upgrade from 3.4 to 3.5
clarkbfrickler: fungi: ++16:13
clarkbalso I have no idea if ^ those gerrit image updates will function. But we have to start somewhere :)16:13
fungiclarkb: tobias-urdin mentioned running zuul 5.0.0 with gerrit 3.5, so that's a good data point16:20
opendevreviewClark Boylan proposed opendev/system-config master: Upgrade Gitea to v1.15.11
clarkbNoticed that ^ got a new release recently. And then shortly after that it actually got a 1.16.0 release16:24
fungithey're on a roll16:24
clarkbI think we upgrade to latest 1.15.x first. Then can start planning 1.16.0 upgrade for next week maybe16:24
fungisounds reasonable16:24
clarkb1.16.0 changes how they deal with dependencies. I expect we'll need to look carefully at how we are building the project in our containers16:24
clarkbour container is based on upstreams though so we can compare docker files16:25
fricklerfungi: clarkb: I would place cirros into the opendev tenant or is there a reason to prefer openstack?16:26
clarkbthat is a good question. I suspect that it might be easier to do cirros job action triggers openstack action if you want to tie them in closely like that. But I suspect that isn't necessary and the opendev tenant is sufficient16:27
clarkband continue to have devstack consume cirros via an explicit update to its "config"16:27
fungifrickler: probably better to put it in the opendev tenant unless you plan to reuse openstack job definitions which will require adding a bunch of repos to the tenant (e.g. devstack jobs)16:27
fungiso, yes, if the plan is to run devstack jobs on cirros changes, openstack tenant may be easier since it already has all the necessary projects16:28
clarkboh ya good point, you may want to go the other direction and test cirros updates by running them through tempest testing or something16:28
clarkbthat is probably tbe biggest consideration. How tightly do you want to couple cirros to openstack CI as an input16:29
fricklerthat's a good idea, o.k., so openstack instead16:29
*** artom_ is now known as artom16:37
clarkbfrickler: fyi not sure if you saw but I think that is the rough list I'll start with for retirements. Happy for people to look it over and strike out any that are not safe to retire or add those I missed too16:37
*** ysandeep is now known as ysandeep|out16:44
opendevreviewDr. Jens Harbott proposed openstack/project-config master: Add cirros/cirros project
fricklerclarkb: I saw that and while I'm not sure about the list of puppet modules in detail, those looked o.k. to me16:45
*** marios|ruck is now known as marios|out16:45
fungiclarkb: per my earlier comment on it, we can also just take out anything the mediawiki module uses (and the module itself)16:48
funginot sure if you want it in a separate change16:49
clarkbfungi: ya I think for now maybe dealing with wiki things separately makes sense. The wiki is still there just unmanaged and we need to sort that out so can do all of that together16:58
fungiwell, the wiki which is there was never managed with any of that puppetry16:59
fungiit was only used to deploy a dev server which never fully worked16:59
fungibut i'm happy to remove those bits of configuraiotn management in a separate change16:59
*** dviroel|lunch is now known as dviroel17:02
dtantsurhi folks! is there a way to manually trigger a job in the post pipeline?17:14
clarkbdtantsur: not a specific job. We can enqueue buildsets either by merging a change or via admin command to zuul17:15
*** amoralej is now known as amoralej|off17:16
dtantsurI see.. we ended up publishing a broken image, and now need to somehow restart the build17:16
clarkbif the buildset is enqueued for the last merged change is it expected that a working image will be produced?17:18
clarkbif not then the best action is probably to push a fix and land that and have it rebuild17:18
dtantsuryes, the fix was in requirements, not in our repo. but hold on, we may have a suitable patch to approve to trigger the build.17:19
*** sshnaidm is now known as sshnaidm|afk17:30
fricklerwhere did the idea for the default-branch setting come from? I just copied that from the charms patch, but both get an error: ERROR: Unknown keyword 'default-branch' in project cirros/cirros18:13
clarkbfrickler: it is a new config we added to the gitea git repo management role and the jeepyb manage-projects command, but our CI for projects.yaml hasn't been udpated to handle it I think18:16
clarkbfrickler: basically we need to update the little linter tool to accept that key: value pair in projects.yaml18:16
clarkbI think the linter may also git clone the upstream: and check that master is present. That might need to be modified to check for default-branch first then check master if not set18:17
fricklero.k., this becomes more of a rabbit hole than I expected, but I can take a look later or maybe tomorrow18:18
clarkbI can probably push up a change you can base on18:20
clarkbor I can rebase your change18:20
fricklerclarkb: sure, that would be great18:22
opendevreviewClark Boylan proposed openstack/project-config master: Allow default-branch in our projects.yaml checking
opendevreviewClark Boylan proposed openstack/project-config master: Add cirros/cirros project
clarkblets see if that does it18:37
clarkbinfra-root the gitea upgrade as well as new gerrit 3.5 image stuff seems to be happy. I think we can safely approve all of those toay if we like. I'll try to respond to reviewer feedback too18:39
clarkbmy brain feels all over the place though so definitely call out if you see issues.18:40
opendevreviewClark Boylan proposed openstack/project-config master: Add cirros/cirros project
noonedeadpunkhey everyone! I'm trying to find what script does create project in gerrit based on gerrit/projects.yaml but found only part for zuul...18:50
noonedeadpunkCan you kindly point me there?:)18:50
clarkbnoonedeadpunk: opendev/jeepyb/.../manage-projects.py18:50
noonedeadpunkwow, never knew about that repo...18:51
clarkbIt could probably stand to be rewritten to use more of the rest api but its a complicated enough process that I don't know anyone wants to take it on18:51
noonedeadpunkWell why I'm asing as I was thinking if making parented projects is smth that kind of make sense18:53
noonedeadpunkas for us it's whole pita to build a dashboard18:53
clarkbI don't know if gitea would support that18:54
clarkbI think you can use things like openstack/ansible-* though18:54
noonedeadpunkI think from git prespective it's actually same18:54
noonedeadpunkafaik it's just logic inside gerrit18:54
clarkbnoonedeadpunk: but gitea is not git18:54
noonedeadpunkI could, but then I need to exclude all kolla, thales, this and that appears every other month...18:55
clarkbbasically i'm 80% sure that won't work in our current systems18:55
clarkbdue to there being other systems like gitea that would need to support it and I'm fairly sure they do not18:55
clarkb(we can blame everyone copying github)18:56
noonedeadpunkBut it's just acl thing kind of for gerrit, no?
clarkbI think we might be conflating two things18:57
noonedeadpunkit's not about structure or anything?18:57
noonedeadpunkwell structure inside gerrit, yes...18:57
clarkbchanging the project parent in acls is already doable you do not need to change anything18:57
clarkball of openstack is parented to the openstack meta acl now18:57
clarkbjust edit your configs and it works iirc18:57
clarkbI thought you wanted to create projects in nested directories18:58
clarkbwhcih is where gitea will struggle18:58
noonedeadpunknah, I basically wanted to be able to use `parentproject:'PROJECT'` in search :D18:58
clarkbthats already supported. Just update your acls18:58
noonedeadpunkyeah, I agree that for git subtree gitea will strugle for sure18:59
clarkbBut note that all of openstack is expected to parent to the openstack meta acl so you may need a second layer in the middle18:59
noonedeadpunkso I would kind of need define different acl for all projects?18:59
noonedeadpunkor well, another one...19:00
noonedeadpunkI'm not really sure I understand how to define that with ACL...19:01
noonedeadpunkI guess you're reffering to this
clarkbyes that makes openstack/meta-config the parent project of that project19:03
clarkbwhat you are describing would require you to have openstack/osa-meta-config which has parent openstack/meta-config and all your repos can parent to osa-meta-config19:03
fungiand being parented to openstack/meta-config, at least indirectly, is important since it's what grants things like release account permissions to push tags and add/delete branches19:04
clarkbBut no changes to jeepyb are necessary. You can just edit your acls to do this19:04
noonedeadpunkok, yes, I got this now. I thought that extra command would require to run for that for some reason :)19:05
fungiand create a new project for the acl you want to them to parent to, right19:05
noonedeadpunkmy gerrit cudos not so great 19:05
noonedeadpunkI suspesct such project should go through governance as well?19:06
clarkbyes I think you have to record it at least.19:07
fungievery repo in the openstack/ namespace is accounted for in openstack/governance one way or another now19:09
opendevreviewClark Boylan proposed openstack/project-config master: Allow default-branch in our projects.yaml checking
opendevreviewClark Boylan proposed openstack/project-config master: Add cirros/cirros project
opendevreviewDmitriy Rabotyagov proposed openstack/project-config master: Parent OSA roles to openstack-ansible repo
noonedeadpunkdo you think this can do the thing as well ^ ?19:16
clarkbah ya since they already had a common config that should work too19:17
fungiright, you don't necessarily need a separate repo19:17
noonedeadpunkhopefully I didn't make any silly typo there...19:17
fungiopenstack as a whole simply didn't have an appropriate repo for me to do that with (i thought about abusing openstack/openstack for it but quickly realized it has its own acl needs)19:18
noonedeadpunkyes, that's fair19:21
clarkblooks like the gerrit 3.4 into 3.5 merge happened and picked up the outstanding changes we were waiting on19:39
clarkbthat means when we land our 3.5 image addition it should be good to go with the bugs/issues we've managed to fix in 3.3/3.419:40
fungiclarkb: i think the upgrade 2.4->3.5 test addition is working too, do we want to wait for more reviews before merging?19:40
fungier, 3.4->3.519:40
fungii approved the parent, i guess once it gets images properly uploaded to dockerhub it may make sense to recheck19:44
clarkbfungi: Ya I think approving as is is probably fine. I responded to your comment and called out that there is at least one important change we'll want to make to our configs because we trust that too much. But that can be done in a followup19:47
clarkband there are possibly a number of other changes we'll need to make along those lines as we prepare for a future 3.5 upgrade19:47
clarkbin particular we want to set to false explicilty to ensure the behavior for new sites matches what we'll get in production19:48
clarkbwe will apparently have to migrate our front end plugin for zuul to yarn if it isn't yarn already19:49
clarkbBut having images and doing basic upgrades even if not fully where we want them should be fine and a good start19:49
fungimakes sense, thanks19:58
fungioh, also that job will always use an image from the build registry, not the one we upload to dockerhub, right? so i suppose there's no reason to hold off approving it now20:00
noonedeadpunkfungi: would be so great if you could review {โ—• โ—ก โ—•}20:02
fungithat and the default-branch/cirros changes are next up for me20:02
noonedeadpunk(there's merge conflict)20:03
clarkbfungi: yup should use locally built image20:03
fungithere's always a merge conflict20:03
noonedeadpunkwell, yes, I can't say I'm happy with updated version of gerrit. It acts weirdly for rebases... And misses so handy "branch" download command...20:04
noonedeadpunkas well as dot if patch not on latest20:05
noonedeadpunkbut yeah...20:05
fungisome of that may be related to the fact that we haven't turned the merge conflict detection back on yet20:08
fungithe recent upgrade switched it off by default, but in our meeting this week we agreed to try turning it back on20:09
fungianyway, zuul doesn't see a merge conflict, it gave a +1, so it ought to be mergeable20:10
fungiguess we'll find out20:10
ianwthanks for looking at the 3.5 images20:20
ianwinteresting that on the screenshot it doesn't have the grey circle issue20:21
ianwit does in the 3.4 screenshots on the same page, so i guess we can just consider that something that will disappear with upgrade20:22
opendevreviewMerged openstack/project-config master: Parent OSA roles to openstack-ansible repo
opendevreviewMerged openstack/project-config master: Allow default-branch in our projects.yaml checking
clarkbianw: should be a pretty straightfoward gitea upgrade20:33
clarkbianw: re cirros I don't think this is for third party testing. The intent seems to be to host cirros on opendev since the existing upstream is largely dead? Also putting it in the existing openstack tenant simplifies testing between the two since they can easily share jobs20:39
clarkbI think if we were going to setup a new tenant or just include it for lightweight testing rather than completely hosting the project then your suggestion makes sense20:39
clarkbbut probably good for frickler to confirm all that before we proceed20:40
fungiyeah, the only gotcha i can think of is that if the prior cirros maintainers don't see this as a continuation of the project, it might warrant a different name20:41
fungicircos ;)20:41
clarkbgood point20:41
* frickler reads backlog20:42
fricklerI actually had already reserved testos as alternative name on github ;)20:42
opendevreviewMerged opendev/system-config master: Add Gerrit 3.5 image builds and testing
fricklerbut I can also check with smoser, I'm really not sure whether this would end up as fork or as move from the original away from github or only as CI for the latter20:46
frickleralso I'm using my fork only because I renamed the master branch to main there, otherwise it is unchanged20:47
clarkbgot it. I think if we're just doing third party CI was can do more what ianw described. But if we are forking then what we have (with possible name change) seems correct20:47
*** dviroel is now known as dviroel|afk20:50
fricklerso my idea would be to go with what we have now, that would allow me to try to get the CI things working and I would be willing to do any work possibly needed if we want to change the setup or rename the repo later20:52
fricklerbut also no need to rush this, we can discuss more tomorrow, I'm off for now20:54
clarkbgood night!20:54
fungiyeah, i'm fine with what's there. we do have the ability to do renames if it becomes necessary/desirable to do so later20:56
fungimight even be a good test of whether our rename method chokes on default branches other than master20:56
ianwahh, ok if it's a port in, that's fine20:57
opendevreviewIan Wienand proposed zuul/zuul-jobs master: ensure-sphinx: Use python3
opendevreviewIan Wienand proposed zuul/zuul-jobs master: ensure-virtualenv: Don't support on CentOS 9-stream
noonedeadpunknice, it's working! thanks fungi clarkb!21:08
opendevreviewRamil Minishev proposed openstack/diskimage-builder master: Make growvols config path platform independent
noonedeadpunkmmm... another thing. Seems after moving to oftc only infra has access to channels. So how to ask for a channel topic change?:)21:26
clarkbits the same process as before, we just could't do a direct port since nicks may hve changed between networks21:28
clarkbeg you ask an existing chan op to add you21:28
clarkbI can look into that in about half an hour if you like. Its been a while since I did one so may take me a few to sort out the chanserv commands21:29
noonedeadpunksure, no rush! it's about #openstack-ansible jsut in case. And the only thing that needs to be done - replace last symbol in channel topic from `3` to `4` :D21:30
funginoonedeadpunk: we have git for it now actually21:41
fungiadd yourself to the accessbot config in openstack/project-config21:41
funginoonedeadpunk: see the comments at the top of
fungiwe didn't port over the access lists from freenode because we couldn't be positive everyone would have the same nicks on oftc21:42
noonedeadpunkoh, nice21:43
fungiand gerrit provides a stronger assurance that the additions are being requested by the people we think they are, since it's authenticated21:43
noonedeadpunkyeah, that's totally understandable21:43
opendevreviewDmitriy Rabotyagov proposed openstack/project-config master: Add extra operators to #openstack-ansible channel
clarkbfungi: oh even better21:47
opendevreviewRamil Minishev proposed openstack/diskimage-builder master: Add grow_gpt to growvols
fungiyeah, that was one of the "features" i rushed into accessbot during the great exodus21:49
opendevreviewMerged opendev/system-config master: Upgrade Gitea to v1.15.11
clarkbthat is likely to end up behind the hourly deploy buildset. I'll keep an eye on it and monitor gitea though22:00
opendevreviewMerged opendev/system-config master: Test Gerrit upgrade from 3.4 to 3.5
opendevreviewMerged openstack/project-config master: Add extra operators to #openstack-ansible channel
opendevreviewRamil Minishev proposed openstack/diskimage-builder master: Add grow_gpt to growvols
opendevreviewIan Wienand proposed openstack/diskimage-builder master: fedora-container: pull in glibc-langpack-en
clarkbgitea upgrade is starting (none of the backends have updated though)22:30
fungii'm around again if it goes sideways22:34
clarkb01 has updated now and looks fine to me22:35
clarkbI'll check the rest of them as they update. But no issues expected now that the first one is happy22:35
opendevreviewIan Wienand proposed zuul/zuul-jobs master: ensure-virtualenv: Don't support on CentOS 9-stream
clarkbGitea is all done and seems to have run successfully according to zuul and my direct checking.22:54
opendevreviewClark Boylan proposed opendev/system-config master: Force case sensitive Gerrit users in config
clarkbinfra-root ^ deserves careful review and probably a restart on 3.4 once in place just to double check? I'm not in a great position to monitor that today and probably not tomorrow either. But I wanted to get it in my gerrit dashboard todo list so I don't forget23:04
ianwseems straight forward enough, in theory23:09
clarkbianw: ya I think the biggest thing is ensuring that our 3.5 job tests with the same behavior as production once we upgrade23:21
clarkbin theory its entirely a noop outside fo that23:21
opendevreviewMerged zuul/zuul-jobs master: ensure-sphinx: Use python3
*** rlandy|ruck is now known as rlandy|out23:44

Generated by 2.17.3 by Marius Gedminas - find it at!