clarkb | https://review.opendev.org/c/opendev/system-config/+/827561 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 enough | 00:03 |
---|---|---|
clarkb | Thanks for all the reviews. Feels good to get that stuff out of my dashboard :) | 00:04 |
opendevreview | Merged opendev/system-config master: Add CentOS SIGs for CentOS Stream 9 to AFS mirrors https://review.opendev.org/c/opendev/system-config/+/827441 | 00:14 |
*** rlandy|ruck is now known as rlandy|out | 00:22 | |
opendevreview | Merged opendev/system-config master: Switch nb01 to focal in testing https://review.opendev.org/c/opendev/system-config/+/827572 | 00:36 |
opendevreview | Merged zuul/zuul-jobs master: Add CentOS Stream 9 to configure-mirrors role https://review.opendev.org/c/zuul/zuul-jobs/+/826603 | 01:00 |
opendevreview | Merged zuul/zuul-jobs master: Change RDO train repository for Centos 8 stream https://review.opendev.org/c/zuul/zuul-jobs/+/827067 | 01:00 |
opendevreview | Ian Wienand proposed openstack/project-config master: Remove Fedora 34 https://review.opendev.org/c/openstack/project-config/+/816933 | 02:51 |
*** pojadhav|afk is now known as pojadhav | 03:16 | |
opendevreview | Ian Wienand proposed zuul/zuul-jobs master: ensure-sphinx: Use python3 https://review.opendev.org/c/zuul/zuul-jobs/+/827588 | 05:39 |
opendevreview | Ian Wienand proposed zuul/zuul-jobs master: ensure-virtualenv: Don't support on CentOS 9-stream https://review.opendev.org/c/zuul/zuul-jobs/+/827589 | 05:39 |
opendevreview | Merged opendev/system-config master: Stop building Gerrit 3.3 images https://review.opendev.org/c/opendev/system-config/+/827561 | 05:51 |
*** marios is now known as marios|ruck | 06:03 | |
*** anbanerj is now known as frenzyfriday | 06:04 | |
*** ysandeep|out is now known as ysandeep | 06:23 | |
*** amoralej|off is now known as amoralej | 07:26 | |
*** ysandeep is now known as ysandeep|lunch | 09:23 | |
*** ysandeep|lunch is now known as ysandeep | 10:30 | |
*** rlandy|out is now known as rlandy|ruck | 11:13 | |
*** dviroel|out is now known as dviroel | 11:16 | |
*** pojadhav is now known as pojadhav|brb | 11:57 | |
*** ysandeep is now known as ysandeep|afk | 12:08 | |
*** dviroel is now known as dviroel|biab | 12:10 | |
*** pojadhav|brb is now known as pojadhav | 12:10 | |
*** dviroel|biab is now known as dviroel | 12:27 | |
lourot | clarkb, 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 |
lourot | clarkb, would it be a good compromise if I just squash the entire history to one commit? | 12:41 |
lourot | there isn't that much code, just a huge history | 12:43 |
*** amoralej is now known as amoralej|lunch | 13:00 | |
*** ysandeep|afk is now known as ysandeep | 13:01 | |
*** dviroel is now known as dviroel|ruck | 13:44 | |
*** akahat is now known as akahat|rover | 13:45 | |
*** dviroel|ruck is now known as dviroel | 13:48 | |
*** akahat|rover is now known as akahat | 13:56 | |
*** amoralej|lunch is now known as amoralej | 14:19 | |
mnasiadka | Hello infra-root, would need assistance in holding nodes in kolla-ansible-centos8s-source-cephadm job in change https://review.opendev.org/c/openstack/kolla-ansible/+/827298/ - can't reproduce failure in any environment | 14:24 |
* frickler goes to set up a hold | 14:35 | |
fungi | frickler: note that the workaround i found for --change not working with zuul-client autohold was instead to set --ref=refs/changes/de/abcde/f | 14:36 |
fungi | though i think the rpc cli may still work | 14:37 |
frickler | fungi: I've only ever used --ref for that, but thanks for the reminder | 14:37 |
frickler | mnasiadka: since you just rechecked, those should be ready pretty soon, can you also let me know your ssh public key? | 14:40 |
mnasiadka | frickler: sent privately, don't want to spam the channel :) | 14:42 |
opendevreview | Rodion proposed zuul/zuul-jobs master: Implement role https://review.opendev.org/c/zuul/zuul-jobs/+/827682 | 15:01 |
opendevreview | Rodion proposed zuul/zuul-jobs master: Implement ensure-foreleaser role https://review.opendev.org/c/zuul/zuul-jobs/+/827685 | 15:03 |
opendevreview | Rodion proposed zuul/zuul-jobs master: Implement ensure-goreleaser role https://review.opendev.org/c/zuul/zuul-jobs/+/827686 | 15:07 |
frickler | wow, wonder how many iterations it will take for this newcomer to learn about amending patches. I'll try to leave a helpful comment | 15:25 |
clarkb | lourot: 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 |
clarkb | lourot: 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 |
lourot | clarkb, right now it's 15M with the big history. I think if I squash the entire history it'll be very tiny | 15:49 |
clarkb | looks 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 wrote | 15:54 |
fungi | oh, that simplifies matter for us the | 15:54 |
fungi | n | 15:54 |
clarkb | yup. | 15:54 |
frickler | oh, if we just want to test importing a project with default branch main, we could use https://github.com/osfrickler/cirros, 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 |
fungi | frickler: 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 own | 15:59 |
*** dviroel is now known as dviroel|lunch | 16:02 | |
opendevreview | Clark Boylan proposed opendev/system-config master: Add Gerrit 3.5 image builds and testing https://review.opendev.org/c/opendev/system-config/+/827704 | 16:13 |
opendevreview | Clark Boylan proposed opendev/system-config master: Test Gerrit upgrade from 3.4 to 3.5 https://review.opendev.org/c/opendev/system-config/+/827705 | 16:13 |
clarkb | frickler: fungi: ++ | 16:13 |
clarkb | also I have no idea if ^ those gerrit image updates will function. But we have to start somewhere :) | 16:13 |
fungi | clarkb: tobias-urdin mentioned running zuul 5.0.0 with gerrit 3.5, so that's a good data point | 16:20 |
opendevreview | Clark Boylan proposed opendev/system-config master: Upgrade Gitea to v1.15.11 https://review.opendev.org/c/opendev/system-config/+/827710 | 16:23 |
clarkb | Noticed that ^ got a new release recently. And then shortly after that it actually got a 1.16.0 release | 16:24 |
fungi | they're on a roll | 16:24 |
clarkb | I think we upgrade to latest 1.15.x first. Then can start planning 1.16.0 upgrade for next week maybe | 16:24 |
fungi | sounds reasonable | 16:24 |
clarkb | 1.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 containers | 16:24 |
clarkb | our container is based on upstreams though so we can compare docker files | 16:25 |
frickler | fungi: clarkb: I would place cirros into the opendev tenant or is there a reason to prefer openstack? | 16:26 |
clarkb | that 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 sufficient | 16:27 |
clarkb | and continue to have devstack consume cirros via an explicit update to its "config" | 16:27 |
fungi | frickler: 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 |
fungi | so, yes, if the plan is to run devstack jobs on cirros changes, openstack tenant may be easier since it already has all the necessary projects | 16:28 |
clarkb | oh ya good point, you may want to go the other direction and test cirros updates by running them through tempest testing or something | 16:28 |
clarkb | that is probably tbe biggest consideration. How tightly do you want to couple cirros to openstack CI as an input | 16:29 |
frickler | that's a good idea, o.k., so openstack instead | 16:29 |
*** artom_ is now known as artom | 16:37 | |
clarkb | frickler: fyi not sure if you saw https://etherpad.opendev.org/p/opendev-repo-retirements 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 too | 16:37 |
*** ysandeep is now known as ysandeep|out | 16:44 | |
opendevreview | Dr. Jens Harbott proposed openstack/project-config master: Add cirros/cirros project https://review.opendev.org/c/openstack/project-config/+/827719 | 16:45 |
frickler | clarkb: I saw that and while I'm not sure about the list of puppet modules in detail, those looked o.k. to me | 16:45 |
*** marios|ruck is now known as marios|out | 16:45 | |
fungi | clarkb: per my earlier comment on it, we can also just take out anything the mediawiki module uses (and the module itself) | 16:48 |
fungi | not sure if you want it in a separate change | 16:49 |
clarkb | fungi: 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 together | 16:58 |
fungi | well, the wiki which is there was never managed with any of that puppetry | 16:59 |
fungi | it was only used to deploy a dev server which never fully worked | 16:59 |
fungi | but i'm happy to remove those bits of configuraiotn management in a separate change | 16:59 |
*** dviroel|lunch is now known as dviroel | 17:02 | |
clarkb | ah | 17:02 |
dtantsur | hi folks! is there a way to manually trigger a job in the post pipeline? | 17:14 |
clarkb | dtantsur: not a specific job. We can enqueue buildsets either by merging a change or via admin command to zuul | 17:15 |
*** amoralej is now known as amoralej|off | 17:16 | |
dtantsur | I see.. we ended up publishing a broken image, and now need to somehow restart the build | 17:16 |
clarkb | if the buildset is enqueued for the last merged change is it expected that a working image will be produced? | 17:18 |
clarkb | if not then the best action is probably to push a fix and land that and have it rebuild | 17:18 |
dtantsur | yes, 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|afk | 17:30 | |
frickler | where 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/cirros | 18:13 |
clarkb | frickler: 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 think | 18:16 |
clarkb | frickler: basically we need to update the little linter tool to accept that key: value pair in projects.yaml | 18:16 |
clarkb | I 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 set | 18:17 |
frickler | o.k., this becomes more of a rabbit hole than I expected, but I can take a look later or maybe tomorrow | 18:18 |
clarkb | I can probably push up a change you can base on | 18:20 |
clarkb | or I can rebase your change | 18:20 |
frickler | clarkb: sure, that would be great | 18:22 |
opendevreview | Clark Boylan proposed openstack/project-config master: Allow default-branch in our projects.yaml checking https://review.opendev.org/c/openstack/project-config/+/827753 | 18:37 |
opendevreview | Clark Boylan proposed openstack/project-config master: Add cirros/cirros project https://review.opendev.org/c/openstack/project-config/+/827719 | 18:37 |
clarkb | lets see if that does it | 18:37 |
clarkb | infra-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 too | 18:39 |
clarkb | my brain feels all over the place though so definitely call out if you see issues. | 18:40 |
opendevreview | Clark Boylan proposed openstack/project-config master: Add cirros/cirros project https://review.opendev.org/c/openstack/project-config/+/827719 | 18:49 |
noonedeadpunk | hey 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 |
noonedeadpunk | Can you kindly point me there?:) | 18:50 |
clarkb | noonedeadpunk: opendev/jeepyb/.../manage-projects.py | 18:50 |
noonedeadpunk | wow, never knew about that repo... | 18:51 |
noonedeadpunk | thanks! | 18:51 |
clarkb | It 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 on | 18:51 |
noonedeadpunk | Well why I'm asing as I was thinking if making parented projects is smth that kind of make sense | 18:53 |
noonedeadpunk | as for us it's whole pita to build a dashboard | 18:53 |
clarkb | I don't know if gitea would support that | 18:54 |
clarkb | I think you can use things like openstack/ansible-* though | 18:54 |
noonedeadpunk | I think from git prespective it's actually same | 18:54 |
noonedeadpunk | afaik it's just logic inside gerrit | 18:54 |
clarkb | noonedeadpunk: but gitea is not git | 18:54 |
noonedeadpunk | I could, but then I need to exclude all kolla, thales, this and that appears every other month... | 18:55 |
clarkb | basically i'm 80% sure that won't work in our current systems | 18:55 |
noonedeadpunk | hm... | 18:55 |
clarkb | due to there being other systems like gitea that would need to support it and I'm fairly sure they do not | 18:55 |
clarkb | (we can blame everyone copying github) | 18:56 |
noonedeadpunk | But it's just acl thing kind of for gerrit, no? https://gerrit-review.googlesource.com/Documentation/cmd-set-project-parent.html | 18:56 |
clarkb | I think we might be conflating two things | 18:57 |
noonedeadpunk | it's not about structure or anything? | 18:57 |
noonedeadpunk | well structure inside gerrit, yes... | 18:57 |
clarkb | changing the project parent in acls is already doable you do not need to change anything | 18:57 |
clarkb | all of openstack is parented to the openstack meta acl now | 18:57 |
clarkb | just edit your configs and it works iirc | 18:57 |
clarkb | I thought you wanted to create projects in nested directories | 18:58 |
clarkb | whcih is where gitea will struggle | 18:58 |
noonedeadpunk | nah, I basically wanted to be able to use `parentproject:'PROJECT'` in search :D | 18:58 |
clarkb | thats already supported. Just update your acls | 18:58 |
noonedeadpunk | yeah, I agree that for git subtree gitea will strugle for sure | 18:59 |
clarkb | But note that all of openstack is expected to parent to the openstack meta acl so you may need a second layer in the middle | 18:59 |
noonedeadpunk | so I would kind of need define different acl for all projects? | 18:59 |
noonedeadpunk | or well, another one... | 19:00 |
noonedeadpunk | I'm not really sure I understand how to define that with ACL... | 19:01 |
noonedeadpunk | I guess you're reffering to this https://opendev.org/openstack/project-config/src/branch/master/gerrit/acls/openstack/openstack-ansible.config#L2 | 19:02 |
clarkb | yes that makes openstack/meta-config the parent project of that project | 19:03 |
clarkb | what 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-config | 19:03 |
fungi | and 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 branches | 19:04 |
clarkb | But no changes to jeepyb are necessary. You can just edit your acls to do this | 19:04 |
noonedeadpunk | ok, yes, I got this now. I thought that extra command would require to run for that for some reason :) | 19:05 |
fungi | and create a new project for the acl you want to them to parent to, right | 19:05 |
noonedeadpunk | my gerrit cudos not so great | 19:05 |
noonedeadpunk | I suspesct such project should go through governance as well? | 19:06 |
clarkb | yes I think you have to record it at least. | 19:07 |
fungi | every repo in the openstack/ namespace is accounted for in openstack/governance one way or another now | 19:09 |
opendevreview | Clark Boylan proposed openstack/project-config master: Allow default-branch in our projects.yaml checking https://review.opendev.org/c/openstack/project-config/+/827753 | 19:14 |
opendevreview | Clark Boylan proposed openstack/project-config master: Add cirros/cirros project https://review.opendev.org/c/openstack/project-config/+/827719 | 19:14 |
opendevreview | Dmitriy Rabotyagov proposed openstack/project-config master: Parent OSA roles to openstack-ansible repo https://review.opendev.org/c/openstack/project-config/+/827757 | 19:16 |
noonedeadpunk | do you think this can do the thing as well ^ ? | 19:16 |
clarkb | ah ya since they already had a common config that should work too | 19:17 |
fungi | right, you don't necessarily need a separate repo | 19:17 |
noonedeadpunk | hopefully I didn't make any silly typo there... | 19:17 |
fungi | openstack 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 |
noonedeadpunk | yes, that's fair | 19:21 |
clarkb | looks like the gerrit 3.4 into 3.5 merge happened and picked up the outstanding changes we were waiting on | 19:39 |
fungi | perfect | 19:40 |
clarkb | that 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.4 | 19:40 |
fungi | clarkb: 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 |
fungi | er, 3.4->3.5 | 19:40 |
fungi | i approved the parent, i guess once it gets images properly uploaded to dockerhub it may make sense to recheck | 19:44 |
clarkb | fungi: 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 followup | 19:47 |
clarkb | and there are possibly a number of other changes we'll need to make along those lines as we prepare for a future 3.5 upgrade | 19:47 |
clarkb | in particular we want to set https://gerrit-documentation.storage.googleapis.com/Documentation/3.5.0/config-gerrit.html#auth.userNameCaseInsensitive to false explicilty to ensure the behavior for new sites matches what we'll get in production | 19:48 |
clarkb | we will apparently have to migrate our front end plugin for zuul to yarn if it isn't yarn already | 19:49 |
clarkb | But having images and doing basic upgrades even if not fully where we want them should be fine and a good start | 19:49 |
fungi | yep | 19:58 |
fungi | makes sense, thanks | 19:58 |
fungi | oh, 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 now | 20:00 |
noonedeadpunk | fungi: would be so great if you could review https://review.opendev.org/c/openstack/project-config/+/827757 {◕ ◡ ◕} | 20:02 |
fungi | yep | 20:02 |
fungi | that and the default-branch/cirros changes are next up for me | 20:02 |
noonedeadpunk | (there's merge conflict) | 20:03 |
clarkb | fungi: yup should use locally built image | 20:03 |
fungi | there's always a merge conflict | 20:03 |
noonedeadpunk | well, 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 |
noonedeadpunk | as well as dot if patch not on latest | 20:05 |
noonedeadpunk | but yeah... | 20:05 |
fungi | some of that may be related to the fact that we haven't turned the merge conflict detection back on yet | 20:08 |
fungi | the recent upgrade switched it off by default, but in our meeting this week we agreed to try turning it back on | 20:09 |
fungi | anyway, zuul doesn't see a merge conflict, it gave a +1, so it ought to be mergeable | 20:10 |
fungi | guess we'll find out | 20:10 |
ianw | thanks for looking at the 3.5 images | 20:20 |
ianw | interesting that on the screenshot it doesn't have the grey circle issue | 20:21 |
ianw | it does in the 3.4 screenshots on the same page, so i guess we can just consider that something that will disappear with upgrade | 20:22 |
opendevreview | Merged openstack/project-config master: Parent OSA roles to openstack-ansible repo https://review.opendev.org/c/openstack/project-config/+/827757 | 20:23 |
opendevreview | Merged openstack/project-config master: Allow default-branch in our projects.yaml checking https://review.opendev.org/c/openstack/project-config/+/827753 | 20:33 |
clarkb | ianw: https://review.opendev.org/c/opendev/system-config/+/827710 should be a pretty straightfoward gitea upgrade | 20:33 |
ianw | ++ | 20:35 |
clarkb | ianw: 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 jobs | 20:39 |
clarkb | I 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 sense | 20:39 |
clarkb | but probably good for frickler to confirm all that before we proceed | 20:40 |
fungi | yeah, 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 name | 20:41 |
fungi | circos ;) | 20:41 |
clarkb | good point | 20:41 |
* frickler reads backlog | 20:42 | |
frickler | I actually had already reserved testos as alternative name on github ;) | 20:42 |
opendevreview | Merged opendev/system-config master: Add Gerrit 3.5 image builds and testing https://review.opendev.org/c/opendev/system-config/+/827704 | 20:43 |
frickler | but 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 latter | 20:46 |
frickler | also I'm using my fork only because I renamed the master branch to main there, otherwise it is unchanged | 20:47 |
clarkb | got 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 correct | 20:47 |
*** dviroel is now known as dviroel|afk | 20:50 | |
frickler | so 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 later | 20:52 |
frickler | but also no need to rush this, we can discuss more tomorrow, I'm off for now | 20:54 |
clarkb | good night! | 20:54 |
fungi | yeah, i'm fine with what's there. we do have the ability to do renames if it becomes necessary/desirable to do so later | 20:56 |
fungi | might even be a good test of whether our rename method chokes on default branches other than master | 20:56 |
ianw | ahh, ok if it's a port in, that's fine | 20:57 |
opendevreview | Ian Wienand proposed zuul/zuul-jobs master: ensure-sphinx: Use python3 https://review.opendev.org/c/zuul/zuul-jobs/+/827588 | 21:03 |
opendevreview | Ian Wienand proposed zuul/zuul-jobs master: ensure-virtualenv: Don't support on CentOS 9-stream https://review.opendev.org/c/zuul/zuul-jobs/+/827589 | 21:03 |
noonedeadpunk | nice, it's working! thanks fungi clarkb! | 21:08 |
fungi | great! | 21:10 |
opendevreview | Ramil Minishev proposed openstack/diskimage-builder master: Make growvols config path platform independent https://review.opendev.org/c/openstack/diskimage-builder/+/827557 | 21:23 |
noonedeadpunk | mmm... another thing. Seems after moving to oftc only infra has access to channels. So how to ask for a channel topic change?:) | 21:26 |
clarkb | its the same process as before, we just could't do a direct port since nicks may hve changed between networks | 21:28 |
clarkb | eg you ask an existing chan op to add you | 21:28 |
clarkb | I 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 commands | 21:29 |
noonedeadpunk | sure, 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` :D | 21:30 |
fungi | noonedeadpunk: we have git for it now actually | 21:41 |
fungi | add yourself to the accessbot config in openstack/project-config | 21:41 |
fungi | noonedeadpunk: see the comments at the top of https://opendev.org/openstack/project-config/src/branch/master/accessbot/channels.yaml | 21:42 |
fungi | we didn't port over the access lists from freenode because we couldn't be positive everyone would have the same nicks on oftc | 21:42 |
noonedeadpunk | oh, nice | 21:43 |
fungi | and gerrit provides a stronger assurance that the additions are being requested by the people we think they are, since it's authenticated | 21:43 |
noonedeadpunk | yeah, that's totally understandable | 21:43 |
opendevreview | Dmitriy Rabotyagov proposed openstack/project-config master: Add extra operators to #openstack-ansible channel https://review.opendev.org/c/openstack/project-config/+/827768 | 21:46 |
clarkb | fungi: oh even better | 21:47 |
opendevreview | Ramil Minishev proposed openstack/diskimage-builder master: Add grow_gpt to growvols https://review.opendev.org/c/openstack/diskimage-builder/+/827558 | 21:49 |
fungi | yeah, that was one of the "features" i rushed into accessbot during the great exodus | 21:49 |
opendevreview | Merged opendev/system-config master: Upgrade Gitea to v1.15.11 https://review.opendev.org/c/opendev/system-config/+/827710 | 22:00 |
clarkb | that is likely to end up behind the hourly deploy buildset. I'll keep an eye on it and monitor gitea though | 22:00 |
opendevreview | Merged opendev/system-config master: Test Gerrit upgrade from 3.4 to 3.5 https://review.opendev.org/c/opendev/system-config/+/827705 | 22:05 |
opendevreview | Merged openstack/project-config master: Add extra operators to #openstack-ansible channel https://review.opendev.org/c/openstack/project-config/+/827768 | 22:05 |
opendevreview | Ramil Minishev proposed openstack/diskimage-builder master: Add grow_gpt to growvols https://review.opendev.org/c/openstack/diskimage-builder/+/827558 | 22:16 |
opendevreview | Ian Wienand proposed openstack/diskimage-builder master: fedora-container: pull in glibc-langpack-en https://review.opendev.org/c/openstack/diskimage-builder/+/827772 | 22:18 |
clarkb | gitea upgrade is starting (none of the backends have updated though) | 22:30 |
fungi | i'm around again if it goes sideways | 22:34 |
clarkb | 01 has updated now and looks fine to me | 22:35 |
clarkb | I'll check the rest of them as they update. But no issues expected now that the first one is happy | 22:35 |
opendevreview | Ian Wienand proposed zuul/zuul-jobs master: ensure-virtualenv: Don't support on CentOS 9-stream https://review.opendev.org/c/zuul/zuul-jobs/+/827589 | 22:41 |
clarkb | Gitea is all done and seems to have run successfully according to zuul and my direct checking. | 22:54 |
fungi | lgtm | 22:56 |
opendevreview | Clark Boylan proposed opendev/system-config master: Force case sensitive Gerrit users in config https://review.opendev.org/c/opendev/system-config/+/827774 | 23:03 |
clarkb | infra-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 forget | 23:04 |
ianw | seems straight forward enough, in theory | 23:09 |
clarkb | ianw: ya I think the biggest thing is ensuring that our 3.5 job tests with the same behavior as production once we upgrade | 23:21 |
clarkb | in theory its entirely a noop outside fo that | 23:21 |
opendevreview | Merged zuul/zuul-jobs master: ensure-sphinx: Use python3 https://review.opendev.org/c/zuul/zuul-jobs/+/827588 | 23:22 |
*** rlandy|ruck is now known as rlandy|out | 23:44 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!