| opendevreview | Merged opendev/system-config master: Add docs for linaro cloud cert renewal process https://review.opendev.org/c/opendev/system-config/+/914109 | 02:32 |
|---|---|---|
| tonyb | A while ago I said I'd look at adding a python3.12 stow into the images we build. I'm assuming that that will look like adding python-stow-versions and appropriate DIB_ envvars into opendev/system-config:nodepool/nodepool.yaml | 03:14 |
| tonyb | To test locally I wanted to update that file and then have diskimage-builder run a build locally. Is there a nice way to to that? | 03:15 |
| ianw | tonyb: i don't think it meets the criteria of "nice" but in project-config there is tools/build-image.sh ... but it possibly hasn't been used in quite a while. | 03:32 |
| tonyb | ianw: That's close enough to nice for my needs :) | 03:34 |
| tonyb | ianw: Thanks | 03:34 |
| noonedeadpunk | fungi: hey! weirdly, I don't see any bots in #openstack-freezer still. You're a channel ops there though | 11:27 |
| frickler | noonedeadpunk: iiuc at least gerritbot would only join on demand? | 11:32 |
| noonedeadpunk | huh, ok, let's me check that then :D | 11:37 |
| noonedeadpunk | I just saw like 3 bots in osa channel, so decided there should be at least one there | 11:37 |
| frickler | IIUC you didn't configure meetbot for freezer | 11:38 |
| noonedeadpunk | yeah, only gerrit bot and generic access for now | 11:38 |
| noonedeadpunk | so you're right | 11:38 |
| jrosser | when does the centos repo syncronise next, I have a bunch of failures like `Status code: 404 for https://mirror-int.ord.rax.opendev.org/centos-stream/9-stream/AppStream/x86_64/os/Packages/systemd-devel-252-32.el9.x86_64.rpm` | 12:16 |
| jrosser | ah it looks like that rpm is present now | 12:57 |
| frickler | jrosser: you can check the logs yourself on any mirror. seems it finished just when you asked https://mirror.dfw.rax.opendev.org/logs/rsync-mirrors/centos-stream.log | 13:16 |
| clarkb | mnaser: guilhermesp: curious if you were able to track down the cause of the review02 shutdown? From our side I think we're hoping that we can understand the problem so that we can take action (if any makes sense) to help prevent it from happening again | 15:02 |
| clarkb | jrosser: frickler: the centos mirrors don't seem to update indexes and packages in a safe order. This is the second time in a month where they've broken us :/ | 15:03 |
| fungi | these are pulling from the official centos primary mirrors now too... they do have a mirroring tool they recommend though i don't know if it has partial mirroring capability nor whether it's smart enough to check indices to avoid mid-update syncing | 15:08 |
| fungi | one trick i've seen elsewhere that we could ask about: some distros touch a flag file when they begin updating and then remove it when the update is done, so we could make our sync script smart enough to check for the presence of that file and then skip the pull if it's there | 15:10 |
| fungi | but again, no clue whether centos observes that practice for their mirrors | 15:10 |
| clarkb | they can also update files in a safe order. New packages go in, update indexes, remove old packages | 15:11 |
| clarkb | then you're never in a state where package files can't be found | 15:11 |
| fungi | right. that's something they (observably) aren't doing though | 15:12 |
| corvus1 | tonyb: ianw another approach might be to use zuul to build the image for you. you can look at https://review.opendev.org/848792 (and feel free to take it over/update/extend it). that might be more or less as easy as the build-image.sh script, and gaining experience with that / keeping it up to date helps prepare us (and contribute to) the future nodepool-in-zuul work. | 16:43 |
| corvus1 | notably as of the last patchset the image build did work, but it robably needs the element files refreshed since it's old. | 16:44 |
| clarkb | based on https://review.opendev.org/q/reviewedby:15670+AND+NOT+project:openstack/cinder Storpool CI is still leaving the comments we asked them to address on proejcts like ozj and project-config. I'm setting that accoutn to inactive now | 16:55 |
| clarkb | #status log Set Storpool CI's Gerrit account (15670) to inactive due to lack of response to our emails asking them to address Zuul configuration issues. | 16:56 |
| opendevstatus | clarkb: finished logging | 16:56 |
| TheJulia | so what is the correct environment variable to know your current branch when in a script running from a zuul job with the launch environment? | 20:31 |
| Clark[m] | TheJulia in your job logs is a zuul info dir. In that dir is the inventory file. You can see all of the zuul Ansible vars there | 20:36 |
| TheJulia | so, at this point... we don't have any of the env vars like we once did | 20:37 |
| Clark[m] | Then if you want to expose that as an env var you would add the zuul bar to the environment of your Ansible tasks | 20:37 |
| TheJulia | yeah | 20:37 |
| TheJulia | and if the tasks themselves, say to run devstack don't do it, I'm SOL or have to figure out some other way | 20:37 |
| TheJulia | hmmmmmmmm | 20:37 |
| clarkb | devstack is branch aware but not sure if it plumbs that through from zuul | 20:40 |
| TheJulia | well, so I started yesterday thinking "good old ZUUL_BRANCH will fix everything", and then I found stuff using TARGET_BRANCH, but only to run my job to find it not set | 20:42 |
| TheJulia | anyway... more digging required | 20:42 |
| JayF | TheJulia: $TARGET_BRANCH | 20:42 |
| JayF | TheJulia: is that not what you want? | 20:43 |
| JayF | e.g. https://opendev.org/openstack/ironic/src/branch/master/devstack/lib/ironic#L66 | 20:43 |
| TheJulia | yeah, basically, just found it in a job with an empty string which has me feeling "table flippy" | 20:43 |
| TheJulia | For the at home audience, it looked like I had a syntax error. :) | 20:51 |
| clarkb | fwiw it doesn't look like devstack sets TARGET_BRANCH directly form the zuul inventory. Instead zuul runs the jobs using a barnch specific version of stackrc that sets a branch specific TARGET_BRANCH | 21:39 |
| clarkb | the end result should be the same though unless you're in a branch fallback case but those seem unlikely based on what we discovered with recent new branches | 21:39 |
| JayF | Ironic does have special things other branches don't -- the bugfix release branches which run CI | 21:41 |
| JayF | but given Julia is fixing a place we have to manually say "use this branch" when we branch, status quo remains for bugfix branches even if we fix the stable branches -- so it's improved even if not perfect (at least given my understanding) | 21:42 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!