| clarkb | looks like my change to honeypot things is working now. If we want to pursue that further we would need to add some link to the content in a way that normal usage would never navigate it. Then also add it to robots.txt to be explicitly ignored | 00:06 |
|---|---|---|
| clarkb | then we could land those mod security rules to trigger if anything did browse it | 00:06 |
| clarkb | fungi: I'm guessing docs.openstack.org isn't the best place to start doing that. Maybe we should start with docs.opendev.org? | 00:10 |
| clarkb | I also wonder how we could stash the bad link inside sphinx generated content | 00:11 |
| clarkb | it is possible that putting it in robots.txt is enough to get the bad crawlers to trip over it too | 00:11 |
| clarkb | anyway i think I have the technical bits sorted out on the apache side just need to figure out coordinating with the content side | 00:11 |
| *** pabs is now known as Guest33465 | 11:20 | |
| fungi | right, just robots.txt on docs.opendev.org to start with. i think any crawler that not only ignores the disallow rule in robots.txt but actually uses it to decide what might be interesting to retrieve is just asking to get blocked | 13:53 |
| fungi | going to run some errands, back in a bit then i'll put together a quick etherpad maintenance plan for 20z | 15:35 |
| opendevreview | Clark Boylan proposed opendev/system-config master: Add modsecurity waf rules to docs.opendev.org https://review.opendev.org/c/opendev/system-config/+/970674 | 16:01 |
| clarkb | something like that maybe | 16:01 |
| clarkb | fungi: do we have a document for today's planned outage or are you going to reuse the one you found from 2024 or maybe something else? | 16:04 |
| opendevreview | Clark Boylan proposed opendev/system-config master: Add modsecurity waf rules to docs.opendev.org https://review.opendev.org/c/opendev/system-config/+/970674 | 16:57 |
| fungi | clarkb: yeah, i've imported the last one into https://etherpad.opendev.org/p/opendev-project-renames-20251212 and am about to hack it up with today's details | 17:29 |
| clarkb | fungi: I ws going to suggest we add the zuul reporting pause to the process | 17:35 |
| clarkb | it won't be on there yet because that is a relatively new feature but you can grab the details off of the gerrit 3.11 upgrade etherpad: https://etherpad.opendev.org/p/gerrit-upgrade-3.11 | 17:35 |
| fungi | yeah, i was thinking about that earlier, and i agree | 17:39 |
| fungi | granted the gerrit outage will be on the order of a restart | 17:40 |
| fungi | still better safe than sorry | 17:40 |
| clarkb | fungi: I notice that storyboard-dev is already in the emergency fiel. We have a playbook step that operates against it explicitly. Do we think taht will succeed or is the server in the emergency file because the server is down/gone/notworking? | 17:51 |
| fungi | i think i put it in the emergency disable file a long time ago when i was trying to manually test the new attachments feature which needed swift auth configured on it | 17:56 |
| fungi | these days we could just get rid of storyboard-dev, if we wanted to test something we'd do it on a held test node | 17:58 |
| clarkb | ok, seems long enough ago that my current ssh key isn't on it. It would probably be worth a quick sanity chek that the server is expected to be able to run the task in the playbook against it | 17:59 |
| clarkb | otherwise we can remove the task(s) | 17:59 |
| opendevreview | Jeremy Stanley proposed opendev/system-config master: Get rid of storyboard-dev https://review.opendev.org/c/opendev/system-config/+/970879 | 18:05 |
| fungi | if that passes check jobs, i'll go ahead and approve it | 18:11 |
| fungi | and then delete the server from rackspace and the dns records out of cloudflare | 18:12 |
| fungi | clarkb: steps 9 and 24 from https://etherpad.opendev.org/p/gerrit-upgrade-3.11 are what i should incorporate? | 18:54 |
| fungi | added to https://etherpad.opendev.org/p/opendev-project-renames-20251212 as steps 2.9 and 3.1 | 19:01 |
| fungi | #status notice The Gerrit service on review.opendev.org will be offline momentarily at 20:00 UTC (approximately one hour from now) for a project rename maintenance: https://lists.opendev.org/archives/list/service-announce@lists.opendev.org/message/ZPIV7CTPXZUYKUCBYMQ3OKQZDXOSOQGF/ | 19:02 |
| fungi | statusbot is running on eavesdrop but is not in the channel | 19:03 |
| fungi | 2025-12-10 01:44:12 <-- opendevstatus (~opendevst@eavesdrop02.opendev.org) has quit (Ping timeout: 480 seconds) | 19:04 |
| fungi | i'll restart it | 19:04 |
| fungi | #status notice The Gerrit service on review.opendev.org will be offline momentarily at 20:00 UTC (approximately 55 minutes from now) for a project rename maintenance: https://lists.opendev.org/archives/list/service-announce@lists.opendev.org/message/ZPIV7CTPXZUYKUCBYMQ3OKQZDXOSOQGF/ | 19:05 |
| opendevstatus | fungi: sending notice | 19:08 |
| -opendevstatus- NOTICE: The Gerrit service on review.opendev.org will be offline momentarily at 20:00 UTC (approximately 55 minutes from now) for a project rename maintenance: https://lists.opendev.org/archives/list/service-announce@lists.opendev.org/message/ZPIV7CTPXZUYKUCBYMQ3OKQZDXOSOQGF/ | 19:08 | |
| opendevstatus | fungi: finished sending notice | 19:10 |
| clarkb | fungi: yes those are the two commands to pause and unpause zuul | 19:11 |
| fungi | /root/tmp/rename-20251212/20251212.yaml exists on bridge.o.o, copied from 970307 | 19:14 |
| clarkb | I see it looks right | 19:16 |
| fungi | went through just now and renumbered it to be a 12-step program | 19:17 |
| fungi | servers from step 2 are in the emergency list now | 19:20 |
| fungi | tested ssh as root from bridge to all the servers involved too | 19:22 |
| fungi | i have a root screen session open on bridge.o.o | 19:24 |
| clarkb | I have attached to it | 19:25 |
| fungi | i've also got the zuul pause command staged on zuul01, separately per (now) step #4 | 19:30 |
| fungi | 30 minutes to go | 19:30 |
| clarkb | fungi: for step 8 and 10 how are you thinking you want ot handle that? This has always been the weak part of the process imo where we want to ensure things like replication work and that manage-projects doesn't accidentally recreate the old repo | 19:32 |
| clarkb | fungi: I see you struck out the removal of the hosts from the emergency file which means we'll land the change and have it run jobs with hosts in the emergencyfile which means they effectively noop? We can confirm things then reenqueue the jobs after removing the hosts from the emergencyfile? | 19:32 |
| clarkb | or just remove the hosts from the emergency file before forcing merging the change and expect that it will work the first time through and confirm that? | 19:33 |
| fungi | we'll force merge the change, and then expect the next manage-projects run to noop yes | 19:33 |
| clarkb | ok. Then we can confirm things like replication are happy then reenqueue the change? | 19:33 |
| fungi | at least that was the primary method indicated in the previous one | 19:33 |
| fungi | er, reenqueue what change? | 19:34 |
| clarkb | fungi: the one we force merge so that it runs in non noop mode sometime before the daily runs | 19:34 |
| clarkb | I think what has chagned since the last time we do this is that we're no longer running manage-projects hourly. It is once a day or due to triggers from merging changes that update the configs | 19:34 |
| fungi | we don't have a step for that, but can add one i guess | 19:34 |
| clarkb | fungi: I think that is essentially step 12 | 19:35 |
| clarkb | we can wait for ~0200 to do it as part of daily runs or we could run it sooner | 19:35 |
| fungi | yeah, i'm open to doing that | 19:35 |
| clarkb | but the note in step 10 is basically saying "if we didn't already do this as part of force merging the change then do it here" | 19:35 |
| clarkb | so we can approach it both ways I think and I want to say last time we actually removed hosts from the emergency file before force merging under the expectation that everything would work as expected | 19:35 |
| clarkb | the key is that we are careful not to run manage-projects in a way that would recreate the old project | 19:36 |
| fungi | ah, that was listed as optional but seemed to be worded really cagey like we expected zuul to race gerrit's replication | 19:36 |
| clarkb | fungi: yes, I think that is actually a possibility since we deploy project-config from master off of the giteas but zuul is triggering the jobs off of gerrit repo state | 19:37 |
| clarkb | it is an unlikely situation given how long it takes zuul to start running builds vs how long replication typically takes. But if replicatoin were to fail... | 19:37 |
| fungi | well, also compared to last time we have zuul paused when the change is merged | 19:38 |
| clarkb | anyway I think keep things in emergency file, merge change, check for noop and replication as expected, drop hosts from emergency file, reenqueue deployment jobs should be safe | 19:38 |
| clarkb | fungi: that is only pausing zuul reporting to gerrit | 19:38 |
| clarkb | fungi: I think zuul is free to start and run jobs in that state | 19:38 |
| clarkb | (and the unpause occurs before merging the change) | 19:39 |
| clarkb | to summarize I think there are two approaches A) is we rename everything in gerrit and storyboard and gitea and bring gerrit back up. Then we merge the change to reflect this in manage-projects, but don't let it run yet so that we can confirm replication is happy. Once we are happy things are in place we manually enqueue the deployment jobs with hosts removed from emergency file. Or | 19:43 |
| clarkb | B) We remove hosts from the emergecny file before force merging the change under the expectation that our systems will work as expected. Then we simply check the result at the end. | 19:43 |
| clarkb | I want to say B is what we ended up doing last time but it has been a long time | 19:43 |
| fungi | i'm open to either one. i suppose A is the more conservative approach, but more manual work | 19:51 |
| clarkb | fungi: thinking out loud here: if we want to go with B we could land the records keeping change and check that replication wroks for it. If so remove hosts from the emergency file and merge the change that updates projects.yaml under the assumption that generally working replication is a sufficient enough check and let manage-projects run from there | 19:52 |
| clarkb | I like the simplicity of that | 19:53 |
| clarkb | and we don't need to force merge that change either bceause that repo only runs noop jobs | 19:53 |
| fungi | sure, lemme hack that in real quick | 19:53 |
| fungi | we mainly need to be careful not to approve any changes that might run manage-projects, and not have the maintenance straddle the daily run | 19:54 |
| fungi | the commentary on step 8 suggests that may be a poor workflow if we have multiple rename changes though, yeah? (not the case this time) | 19:55 |
| clarkb | yes the problem with multiple rename changes is that they will run deployments in sequence potentially running manage-projects in an intermediate state. Shouldn't be an issue here | 19:56 |
| fungi | #status notice The Gerrit service on review.opendev.org will be offline momentarily for a project rename maintenance: https://lists.opendev.org/archives/list/service-announce@lists.opendev.org/message/ZPIV7CTPXZUYKUCBYMQ3OKQZDXOSOQGF/ | 20:00 |
| opendevstatus | fungi: sending notice | 20:00 |
| -opendevstatus- NOTICE: The Gerrit service on review.opendev.org will be offline momentarily for a project rename maintenance: https://lists.opendev.org/archives/list/service-announce@lists.opendev.org/message/ZPIV7CTPXZUYKUCBYMQ3OKQZDXOSOQGF/ | 20:00 | |
| clarkb | that revised plan looks like my modified B) plan | 20:00 |
| fungi | cool | 20:01 |
| fungi | zuul is paused | 20:01 |
| fungi | status page states "Trigger, Result event queues paused: Gerrit restart in progress" | 20:02 |
| clarkb | yup that looks right | 20:02 |
| fungi | i'm ready to run the rename playbook in the screen session if it looks right | 20:03 |
| opendevstatus | fungi: finished sending notice | 20:03 |
| clarkb | yes I think it loosks correct | 20:03 |
| fungi | running | 20:03 |
| clarkb | now we ewait for gerrit to stop which took like 3 minutes last time? | 20:04 |
| fungi | approximately | 20:04 |
| clarkb | based on timestamps and lock files it is processing gerrit_file_diff.h2.db | 20:05 |
| clarkb | and now git_file_diff.h2.db | 20:06 |
| fungi | and there it goes, (barely) soon enough i don't think the stop timed out? | 20:08 |
| fungi | Unable to use /home/gerrit2/.ansible/tmp as temporary directory, failing back to system: [Errno 13] Permission denied: '/home/gerrit2/.ansible' | 20:09 |
| clarkb | which is weird because I thought this was a privileged process | 20:09 |
| fungi | we certainly ran it as root | 20:09 |
| fungi | though maybe it runs that task as gerrit2? | 20:09 |
| clarkb | fungi: right this si running against review03 but we ssh in as root iirc | 20:10 |
| clarkb | oh that has a become user gerrit2 | 20:10 |
| fungi | looks like it maybe didn't manage to create the /home/gerrit2/.ansible directory | 20:11 |
| clarkb | fungi: looks like /home/gerrit2 is owned by root:root for some reason but tmp/ is ownged by gerrit2:gerrit2 | 20:11 |
| fungi | and yes, my ls confirms your observation | 20:12 |
| fungi | /home/gerrit2 is not writeable by the gerrit2 user | 20:12 |
| clarkb | fungi: I think the issue is ansible must create some tmpdir for its own things but can't create that? | 20:12 |
| clarkb | but I can't remember if the issue was the copy target or an ansible target | 20:12 |
| clarkb | either way I think we can create a copy of the playbook and remove all the bits that already ran and fix this one task | 20:13 |
| fungi | i can create ~gerrit2/.ansible and chown it to gerrit2 then rerun the playbook from that task | 20:13 |
| clarkb | fungi: ya we just have to ensure the playbook is located somewhere it can find the roles and plays it includes | 20:13 |
| clarkb | fungi: might just make a copy of it in the system-config repo on bridge? | 20:13 |
| clarkb | relative paths matter for ansible lookups | 20:14 |
| fungi | oh | 20:14 |
| clarkb | fungi: it also wont' eb able to creat ethat backup | 20:15 |
| clarkb | we need to put the backup in tmp/ | 20:15 |
| fungi | like that? | 20:16 |
| clarkb | yup | 20:16 |
| clarkb | we need the .ansible dir on gerrit03 | 20:16 |
| fungi | d'oh, yep | 20:16 |
| clarkb | sorry review023 | 20:17 |
| clarkb | bah I cannot type | 20:17 |
| fungi | okay, all set i think? | 20:18 |
| clarkb | yes that command loosk correct | 20:18 |
| fungi | running again | 20:18 |
| clarkb | (side note zuul paused more than I thought it would) | 20:18 |
| clarkb | seems like it queues up new builds but doesn't actually start running them | 20:18 |
| fungi | longer term, i wonder whether we simply want ~gerrit2 owned by gerrit2 like the existing playbook seemed to expect | 20:19 |
| fungi | it was presumably that way on the previous review server | 20:19 |
| clarkb | yes I suspect so. I'm wondering if some of our ansible is what sets it to root:root though | 20:19 |
| clarkb | I mentioend this last weekend when we upgraded but I think we have a bunch of really old indexes in the index dir that we could potentially delete at this point | 20:21 |
| clarkb | that would speed up these backup steps | 20:21 |
| clarkb | just a few more changes indexes to copy I think | 20:21 |
| fungi | should be on its way back up now | 20:22 |
| clarkb | web ui loads for me. Still waiting for diffs to load | 20:23 |
| fungi | ready for me to unpause zuul, or should i wait a little bit longer? | 20:23 |
| clarkb | diffs are loading for me (slowly) | 20:25 |
| clarkb | I think the main thing to wait for would be for reindexing to complete? | 20:25 |
| clarkb | projects, accounts ,and groups are done. Only changes are still reindexing | 20:25 |
| clarkb | I suspect we can unpause zuul though | 20:26 |
| clarkb | (just calling out what I think we should consider if we do so and it is changes reindexing) | 20:26 |
| fungi | hah, you spotted my typo just as i was about to fix it ;) | 20:27 |
| clarkb | yup and the gitea redirects seem to work | 20:27 |
| fungi | and yeah, looks right when checking the correct old url | 20:28 |
| clarkb | fungi: I think no chages are listed yet because reindexing of changes isn't complete | 20:28 |
| clarkb | though this repo may have also not had any changes | 20:28 |
| fungi | they hadn't used it | 20:28 |
| fungi | it was just created a couple weeks ago and they realized it had the wrong name | 20:29 |
| fungi | maybe a month ago | 20:29 |
| clarkb | ack. For future renames though it may be the reindexing state too | 20:29 |
| fungi | anyway, i'll go ahead and take servers out of the emergency list | 20:29 |
| fungi | you want to approve changes or shall i? | 20:30 |
| fungi | oh, i need to fix 970307 to not depends-on 968047 | 20:30 |
| clarkb | I think you can. Reindexing is proceeding slowly. I think we don't need to wait for chagnes to reindex before manage-projects runs. I would wait for projects to reindex and it has | 20:30 |
| clarkb | projects and groups since that is what manage-projects touches | 20:31 |
| opendevreview | Jeremy Stanley proposed opendev/project-config master: Add record for planned rename on December 12, 2025 https://review.opendev.org/c/opendev/project-config/+/970307 | 20:31 |
| opendevreview | Merged opendev/project-config master: Add record for planned rename on December 12, 2025 https://review.opendev.org/c/opendev/project-config/+/970307 | 20:32 |
| clarkb | eavesdrop deploy failed due to me putting foo: @status in private vars for eavesdrop and apparently that is invalid yaml | 20:32 |
| fungi | https://opendev.org/opendev/project-config/commit/4f524f3a2d20e75167847bfe6065c39d3b90981f | 20:33 |
| fungi | that's also showing up ast the master branch tip | 20:33 |
| clarkb | agreed replication seems to be working | 20:34 |
| clarkb | I'm going to fix that yaml problem now so that 2100 hourly runs for eavesdrop don't explode too | 20:34 |
| fungi | thanks | 20:34 |
| clarkb | (this is unrelated to the project renaming and I don't expect them to interfere with each other) | 20:34 |
| fungi | ready for me to approve 968047 and monitor the manage-projects run during deploy? | 20:34 |
| clarkb | I think so. change reindexing is at ~26% | 20:37 |
| fungi | done | 20:37 |
| clarkb | the yaml var for eavesdrop should be better now. foo: @status is now foo: '@status' | 20:40 |
| fungi | thanks! | 20:41 |
| opendevreview | Merged openstack/project-config master: Rename Project to Kernel Module Management https://review.opendev.org/c/openstack/project-config/+/968047 | 20:42 |
| fungi | tailing /var/log/ansible/manage-projects.yaml.log in screen | 20:42 |
| clarkb | it looks like the edited playbook has already been cleaned up by zuul machinery too | 20:43 |
| clarkb | (I was going to suggest we delete it but that doesn't appear necessary) | 20:43 |
| fungi | yeah, was on my list of things to check | 20:44 |
| fungi | job is running | 20:45 |
| clarkb | change reindexing is up to 53% | 20:46 |
| clarkb | fungi: manage-projects processed starlingx/app-kernel-module-management which I believe is expected bceause the gruop names changed and the cache for jeepyb wouldn't have an up todate acl hashed in it | 20:49 |
| clarkb | the redirect still works as expected in gitea | 20:50 |
| clarkb | gerrit doesn't show the old project name in the projects list web browser thing | 20:51 |
| clarkb | so I think this is worked as expected | 20:51 |
| fungi | https://review.opendev.org/admin/groups/q/filter:module-manage also shows only the new name not the old | 20:53 |
| clarkb | the old name doesn't show up in the manage-projects ansible lgo either | 20:54 |
| clarkb | so ya I think we only operated on the new name and all of the new name stuff remains in place | 20:54 |
| fungi | yeah, i think this comes as close to our definition of noop as possible anyway | 20:54 |
| clarkb | reindexins is now up to 73% | 20:55 |
| clarkb | as far as followups go: fixing gerrit2's homedir permissions would be good to dig into. Then ensuring service-eavesdrop runs are working with the next hourly runs is also good but unrelated to the project renaming | 20:58 |
| clarkb | and I think the modified B plan seems to have worked well so next time we can follow the process in this etherpad and be happy | 20:58 |
| fungi | yeah, i added the perms to the notes at the bottom of the pad, looking into how that's created now | 20:58 |
| fungi | note that the workflow we used this time wouldn't work with multiple rename changes though | 20:58 |
| fungi | okay, i suspect what's going on is that since /home/gerrit2 is a mountpoint the actual directory on the rootfs was owned by gerrit2 but the root directory of the mounted filesystem was root-owned | 20:59 |
| fungi | since it was manually created, it probably should have gotten its ownership and permissions manually adjusted to match what was on the rootfs, but we missed doing that? | 21:00 |
| clarkb | ya we can either squash them tino a single change (I like the simplicity of this) or have to do a more complicated dance with emergency file contents | 21:01 |
| clarkb | fungi: oh that could be. Though if we just have ansible set it then it should be enforced regardless? | 21:01 |
| clarkb | (as a heads up I detached from the screen and I think you can close it whenever you're done with it) | 21:02 |
| fungi | yeah, what i'm saying is that i don't think ansible is creating the directory directly, so we'll need to add a task to keep it fixed up i suppose? | 21:02 |
| clarkb | fungi: makes sense and yes I think that is a reaosnable solution here | 21:02 |
| clarkb | fungi: ya we only have the user management in ansible which says create the homedir for us | 21:03 |
| clarkb | no explicit then ensure the homedir has the right ownership task so after initial deplyoment when we attach the volume we hit this. Or if the volume is attached already create home may noop if it exists (even if perms are wrong?) | 21:03 |
| fungi | i've closed out the screen session and moved ~root/screenlog.0 to ~root/tmp/rename-20251212/screen.log | 21:04 |
| clarkb | change reindexing is complete. We hit the expected 3 failures and otherwise looks as expected | 21:05 |
| clarkb | service-eavesdrop succeeded after my private vars edit | 21:07 |
| opendevreview | Jeremy Stanley proposed opendev/system-config master: Set perms and ownership on Gerrit's homedir https://review.opendev.org/c/opendev/system-config/+/970919 | 21:07 |
| opendevreview | Clark Boylan proposed opendev/system-config master: Stop collecting manage-projects logs as regular zuul job logs https://review.opendev.org/c/opendev/system-config/+/970920 | 21:12 |
| clarkb | fungi: I need to eat lunch. Is there anything else you think I can help with? I think I'm personally happy with the status of things at this point | 21:13 |
| fungi | nope, i think this is buttoned up. happy lunching! | 21:15 |
| *** darmach37 is now known as darmach3 | 21:18 | |
| cardoe | clarkb: I'm trying to clean up the OSH chart building thing and I'll probably need some pointers. I'm looking at https://opendev.org/openstack/openstack-helm/src/commit/a5670acef08d06b84900a1bac84571b6b478c2a8/zuul.d/base.yaml#L48 which is the publishing of the charts. I figured it would have been a promote job and not a post | 23:05 |
| cardoe | But there's roles references like https://opendev.org/openstack/openstack-helm/src/commit/a5670acef08d06b84900a1bac84571b6b478c2a8/zuul.d/base.yaml#L60 which I don't understand where or what that is. | 23:06 |
| cardoe | I also see all through out there's different values of helm_version for different jobs, playbooks, roles, etc and I think it'd probably be good to figure out a way to set a global default. But I'm just clueless. | 23:07 |
| clarkb | cardoe: the last thing is probably simplest. You can set project level vars in your zuul config that get passed through to jobs | 23:09 |
| clarkb | let me see if I can find a link for docs on that | 23:09 |
| cardoe | I've been prodding a LLM to try and do this and I'm getting slop. | 23:10 |
| clarkb | cardoe: https://zuul-ci.org/docs/zuul/latest/config/project.html#attr-project.vars this is how I would set versions for things globally | 23:10 |
| clarkb | cardoe: your second link is for the openstack-helm-deploy job which I think tests a deployment of openstack using helm. It doesn't deploy your artifacts. The roles: directive there says maybe the roles defined in these repos available to this job even if it runs in some other repo | 23:11 |
| cardoe | oh | 23:12 |
| cardoe | yeah deploy seems to be the "testing" job | 23:12 |
| clarkb | your first link is the job that publishes thigns I think | 23:12 |
| clarkb | it declares that it runs two playbooks https://opendev.org/openstack/openstack-helm/src/commit/a5670acef08d06b84900a1bac84571b6b478c2a8/playbooks/build-chart.yaml and https://opendev.org/openstack/openstack-helm/src/commit/a5670acef08d06b84900a1bac84571b6b478c2a8/playbooks/publish/post.yaml | 23:13 |
| clarkb | (it may run others that it has inherited from parent jobs, but these appear to do the bulk of the work and I suspect it is what we're interested in) | 23:13 |
| clarkb | specifically we need to unflatten https://opendev.org/openstack/openstack-helm/src/commit/a5670acef08d06b84900a1bac84571b6b478c2a8/playbooks/publish/post.yaml#L18-L31 | 23:14 |
| cardoe | Yeah. There's also https://opendev.org/openstack/openstack-helm/src/branch/master/playbooks/publish/run.yaml which I don't think is used but I dunno. | 23:14 |
| clarkb | ya I saw that, but the job doesn't refer to that playbook so it may be bitrot | 23:15 |
| clarkb | looks like helm repo index reads the current directory to build its index so theoretically if we organize things hierarchically before hand then it wuold work? | 23:23 |
| clarkb | there is also the question of how to update the existing index and data. I didn't realize that so much of this is magically handled by helm which probably makes this more difficult to transition (but once sorted out should be fine) | 23:24 |
| cardoe | https://opendev.org/openstack/openstack-helm/src/commit/a5670acef08d06b84900a1bac84571b6b478c2a8/zuul.d/project.yaml#L16 so like I could add right their a key that's "vars" and specify the helm_version and chart_testing_version to be consistent for everything? | 23:30 |
| cardoe | clarkb: yeah I figured I'll first get the new ones into sub directories. I can do something like ironic/ or I can do ironic/2025.2/. The charts are named after the OpenStack release that's current but there's not really a version like that. They just mean they support the stable OpenStack versions that the release does. | 23:31 |
| clarkb | cardoe: re helm_version and other vars yes. Those values would apply to all jobs ran against that project | 23:32 |
| clarkb | so if you have other projects like that plugins repo you may need similar entries there | 23:32 |
| cardoe | I know its friday btw... you can ignore me | 23:33 |
| clarkb | as far as hierarchy goes I think all of the current files have project and version included in them | 23:35 |
| clarkb | which lends itself nicely to organizing things in a way that ext or openafs | 23:36 |
| clarkb | ext4 has a 64k dirent entry limit too iirc | 23:36 |
| cardoe | Is there any kind of variable like git commit that the job was last run at? Or maybe something that triggered this run. Cause I'll be much cleaner if I can only build the charts that need to be built. | 23:36 |
| cardoe | Cause every commit right now I feel like every chart is built. | 23:36 |
| clarkb | https://zuul.opendev.org/t/openstack/build/c1f8756c22db4049b53dad530ff042f4/log/zuul-info/inventory.yaml#109-110 yes you have commit info in there. Note that depending on where the job is running it may be against a speculative state and not one that ever shows up on a published branch | 23:39 |
| clarkb | since this job runs in post that commit should map to something that shows up on a published branch | 23:39 |
| clarkb | in general that inventory.yaml file is going to contain all of the information like this too so you can look there for other info | 23:39 |
| opendevreview | Ivan Anfimov proposed openstack/diskimage-builder master: Drop remaining reference to TripleO https://review.opendev.org/c/openstack/diskimage-builder/+/970927 | 23:40 |
| opendevreview | Ivan Anfimov proposed openstack/diskimage-builder master: Drop remaining reference to TripleO https://review.opendev.org/c/openstack/diskimage-builder/+/970927 | 23:41 |
| clarkb | one interesting side effect of ivan pushing changes like that is we trigger all the builds in zuul against an empty commit. Then we throw them all away when the commit is updated a few minutes later with content | 23:42 |
| opendevreview | Ivan Anfimov proposed openstack/diskimage-builder master: Drop remaining reference to TripleO https://review.opendev.org/c/openstack/diskimage-builder/+/970927 | 23:42 |
| clarkb | I don't know why they edit changes that way. Maybe it is an artifact of using gerrit's web ui to make changes. eg you can't start with content? I'm not sure | 23:42 |
| opendevreview | Ivan Anfimov proposed openstack/diskimage-builder master: Drop remaining reference to TripleO https://review.opendev.org/c/openstack/diskimage-builder/+/970927 | 23:43 |
| cardoe | well looks like the post publishing is busted as well.. I don't quite understand it. | 23:45 |
| clarkb | yes looks like the job started failing recently | 23:46 |
| cardoe | https://opendev.org/openstack/openstack-helm/src/commit/a5670acef08d06b84900a1bac84571b6b478c2a8/playbooks/build-chart.yaml#L24 I'm guessing we cannot do that anymore? | 23:46 |
| clarkb | it is hitting python virtualenv management problems | 23:46 |
| clarkb | ya you need to install it into a virtualenv rather than globally as root due to policy changes on debuntu | 23:46 |
| clarkb | (there is a flag to voerride it and force it to happen but using a virtualenv is better anyway so best to use that) | 23:47 |
| opendevreview | Ivan Anfimov proposed openstack/diskimage-builder master: Drop remaining reference to TripleO https://review.opendev.org/c/openstack/diskimage-builder/+/970927 | 23:48 |
| opendevreview | Ivan Anfimov proposed openstack/diskimage-builder master: Drop remaining reference to TripleO https://review.opendev.org/c/openstack/diskimage-builder/+/970927 | 23:50 |
Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!