| opendevreview | Merged opendev/glean master: Remove debian-stable, add focal/bullseye testing https://review.opendev.org/c/opendev/glean/+/814697 | 00:09 |
|---|---|---|
| *** diablo_rojo_phone_ is now known as diablo_rojo_phone | 02:30 | |
| *** diablo_rojo_phone is now known as Guest3739 | 02:31 | |
| opendevreview | Ian Wienand proposed zuul/zuul-jobs master: ensure-dstat-graph: pull updated branch https://review.opendev.org/c/zuul/zuul-jobs/+/815089 | 05:11 |
| opendevreview | Ian Wienand proposed openstack/diskimage-builder master: Add openEuler jobs back https://review.opendev.org/c/openstack/diskimage-builder/+/815090 | 05:32 |
| opendevreview | Ian Wienand proposed zuul/zuul-jobs master: ensure-dstat-graph: pull updated branch https://review.opendev.org/c/zuul/zuul-jobs/+/815089 | 05:44 |
| opendevreview | Ian Wienand proposed zuul/zuul-jobs master: ensure-dstat-graph: pull updated branch https://review.opendev.org/c/zuul/zuul-jobs/+/815089 | 06:01 |
| opendevreview | Ian Wienand proposed zuul/zuul-jobs master: ensure-dstat-graph: pull updated branch https://review.opendev.org/c/zuul/zuul-jobs/+/815089 | 06:01 |
| *** odyssey4me is now known as Guest3751 | 06:18 | |
| opendevreview | Ian Wienand proposed zuul/zuul-jobs master: ensure-dstat-graph: pull updated branch https://review.opendev.org/c/zuul/zuul-jobs/+/815089 | 06:22 |
| opendevreview | Ian Wienand proposed zuul/zuul-jobs master: ensure-dstat-graph: pull updated branch https://review.opendev.org/c/zuul/zuul-jobs/+/815089 | 07:31 |
| opendevreview | Dr. Jens Harbott proposed opendev/system-config master: Fixup some details in the zuul doc https://review.opendev.org/c/opendev/system-config/+/815094 | 08:07 |
| frickler | infra-root: seems I'm getting 502 on zuul.o.o, will take a closer look in a moment | 08:13 |
| frickler | seems to be the scheduler/kazoo/can't start new thread thing again | 08:23 |
| frickler | that makes me notice that the restart docs still don't mention the sigusr2 debug collection? | 08:24 |
| frickler | I guess with the API also being unreachable, I cannot save queues, the zuul-changes script doesn't seem to make any progress | 08:28 |
| frickler | o.k., got some yappi output, restarting now | 08:32 |
| frickler | #status notice zuul needed to be restarted, queues were lost, you may need to recheck your changes | 08:45 |
| opendevstatus | frickler: sending notice | 08:45 |
| -opendevstatus- NOTICE: zuul needed to be restarted, queues were lost, you may need to recheck your changes | 08:45 | |
| *** ysandeep|out is now known as ysandeep | 09:00 | |
| opendevreview | Merged openstack/project-config master: Move the daily periodic trigger earlier https://review.opendev.org/c/openstack/project-config/+/814794 | 09:11 |
| fungi | frickler: almost exactly one week after the last time too, yeah? | 11:33 |
| frickler | fungi: indeed, though there were a couple of restarts in between, so I don't think it is a Friday thing ... yet | 11:39 |
| fungi | right, possible it's pure coincidence | 11:51 |
| fungi | last time we suspected zk connectivity problems, i think? i need to go back through the discussion | 11:52 |
| *** tosky_ is now known as tosky | 12:07 | |
| artom | o/ Zuul question - is there a way to recheck specific jobs on a patch? So if tempest-foo-py42 fails but everything else passes, just rerun that 1 failing job | 14:56 |
| artom | I guess you can hardcode every job name as a trigger? | 14:56 |
| fungi | artom: nope, zuul enqueues and reports complete buildsets, not individual builds. the risk there is you have a change which passes its jobs 50% of the time, so you selectively rerun each job until you get a passing result to get your broken change to merge | 14:57 |
| artom | fungi, ack | 14:58 |
| fungi | requiring all jobs to pass together makes it much harder to merge a broken change | 14:58 |
| fungi | the goal of zuul is to block broken changes from merging while it's still the patch author's job to fix, rather than catching bugs after merging when they become everyone's problem | 14:59 |
| fungi | but doing that requires reliable jobs | 14:59 |
| fungi | so ideally you'd focus on making the jobs more reliable, rather than trying to find ways to ignore their unreliability | 15:00 |
| artom | fungi, there's a convo around trying to save CI resources in the nova PTG room by using job hierarchies, an idea that came up was only re-running the failing jobs when the failure is unrelated | 15:00 |
| artom | But you make a good point | 15:00 |
| fungi | artom: the most effective ways to save ci resources are: 1. make the jobs more reliable so they don't need to be rerun as often, and 2. make the tests and the software being tested run more quickly on fewer resources | 15:02 |
| artom | fungi, but that's hard ;) It's easier to find Zuul haxx | 15:02 |
| fungi | yeah, that's pretty much i. fixing the real problems correctly is a lot of work, so people would rather pile up workarounds until everything topples under its own weight | 15:03 |
| fungi | er, pretty much it | 15:03 |
| fungi | clarkb might be interested in that nova conversation if he's around (i'm still in the tc rbac discussion) | 15:04 |
| fungi | looks like nova already moved on anyway | 15:06 |
| clarkb | sorry I took this as an opportunity to sleep in a bit compared to the last few days. | 15:15 |
| clarkb | artom: fungi: good news is if you take the time to address those difficult problems you tend to make your software better in the process. As I mentioned with the setuptools pinning discussion we need to get away from this idea that the CI exists to show us a green light and instead to show us where our software has issues so that the issues can be addressed. The green light is a side | 15:15 |
| clarkb | effect not the goal | 15:15 |
| clarkb | frickler: ah sorry I didn't realize the sigusr2 stuff was specifically what we were talking about re debugging zuul. I'll see if I can write something up about that today | 15:17 |
| clarkb | hopefully the updated restart directions were helpful though | 15:17 |
| opendevreview | Merged zuul/zuul-jobs master: ensure-docker: remove Debian Stretch testing https://review.opendev.org/c/zuul/zuul-jobs/+/814695 | 15:19 |
| frickler | clarkb: yes, went pretty smooth with running the playbook | 15:20 |
| clarkb | infra-root I plan to merge https://review.opendev.org/c/opendev/system-config/+/813675 after some breakfast. I'll make copies of the exim config and iptables configs on review02 and we can use that to double check no unexpected changes between before and after due to the group reorg | 15:21 |
| clarkb | just a heads up since this change scares me a bit :) it should be fine I've been over it a couple of times now and haven't found any other uses of the gerrit group | 15:21 |
| frickler | the sigusr2 thing I just used the first process id and it seemed to be fine | 15:21 |
| clarkb | frickler: yup the only other thing to be aware of with sigusr2 is that the first one starts yappi which has a performance impact due to its profiling so if you don't plan to restart the processes you should send a second sigusr2 later to stop yappi and reduce the performance overhead (each sigusr2 is a yappi toggle) | 15:22 |
| clarkb | I'll try to get that all documented today | 15:22 |
| clarkb | in this case you restarted so it is fine | 15:23 |
| frickler | yes, I did it twice and checked that there is some output from yappi after the second signal. hoping corvus can use the logs to gather more insight | 15:23 |
| corvus | frickler: yep, thanks! just started looking at it | 15:23 |
| corvus | frickler, clarkb: wow, the stack dump handler logged zero threads. | 15:26 |
| corvus | right before that is a MemoryError exception | 15:29 |
| clarkb | just thinking out loud here: it is possible that glibc on bullseye is not as happy with python3.8 + zuul as it was on buster? | 15:35 |
| clarkb | we had the thread issue too iirc | 15:35 |
| clarkb | memory stuff would be in glibc. threads are in pthreads though? | 15:36 |
| clarkb | I have approved 813675 after making copies of /etc/alises and /etc/iptables/rules.v4 and /etc/iptables/rules.v6 | 15:42 |
| clarkb | I'll leave my connection to the server open too | 15:42 |
| *** timburke__ is now known as timburke | 15:50 | |
| opendevreview | Merged zuul/zuul-jobs master: ensure-rust: verify cryptography build on Ubuntu https://review.opendev.org/c/zuul/zuul-jobs/+/812273 | 16:13 |
| opendevreview | Merged opendev/system-config master: Remove the gerrit group in favor of the review group https://review.opendev.org/c/opendev/system-config/+/813675 | 16:15 |
| clarkb | the hourly deploy is running now but then deploy jobs for ^ will run. I'm keeping an eye on it | 16:16 |
| clarkb | I think that will run manage-projects.yaml and that will run manage-projects with the gitea always update flag set to true | 16:17 |
| clarkb | we don't expect any issues from that based on real world experience last friday | 16:17 |
| opendevreview | Clark Boylan proposed opendev/system-config master: Document Zuul's SIGUSR2 handler https://review.opendev.org/c/opendev/system-config/+/815134 | 16:26 |
| clarkb | frickler: ^ do you think that is enough info about the the signal hanlder in zuul? | 16:26 |
| frickler | clarkb: could you rebase on top of https://review.opendev.org/c/opendev/system-config/+/755155 ? I did some formatting and nit cleanup | 16:28 |
| fungi | clarkb: i also left a couple of minor comments | 16:29 |
| clarkb | frickler: looks like that change needs a reabse too since my other changes landed. Sorry I didn't notice that one as a conflict. But ya I can rebase both and do the related cleanups | 16:30 |
| frickler | ha, fungi wrote the same comments as I did, just phrased differently, nice ;) | 16:31 |
| fungi | it's good to know i wasn't too off track ;) | 16:32 |
| fungi | 755155 also reminded me that we apparently haven't moved the db out of trove yet? | 16:33 |
| frickler | oh, actually I meant https://review.opendev.org/c/opendev/system-config/+/815094 , not sure where that link came from | 16:34 |
| fungi | though that one's also related, yep | 16:34 |
| clarkb | ah well I'll push an update to 755155 since it is almost doen but rebase the usr2 change on 815094 | 16:38 |
| clarkb | though maybe they overlap so nevermind | 16:39 |
| fungi | yeah, 755155 looks like it'll need some more work to reintegrate now | 16:40 |
| fungi | but also i apparently missed that one getting pushed | 16:41 |
| opendevreview | Clark Boylan proposed opendev/system-config master: Document Zuul's SIGUSR2 handler https://review.opendev.org/c/opendev/system-config/+/815134 | 16:43 |
| clarkb | upadted thanks | 16:43 |
| opendevreview | Merged opendev/system-config master: Fixup some details in the zuul doc https://review.opendev.org/c/opendev/system-config/+/815094 | 16:48 |
| clarkb | manage projects ran in not much time and was successful. We are seeing what we expected there. Always a good sign | 17:06 |
| clarkb | service-review is done and the three files that would've been modified if wires got crossed did not change. I can still ssh into review02 and the gerrit web ui is accessible I think we are good | 17:17 |
| opendevreview | James E. Blair proposed zuul/zuul-jobs master: Update dstat to support bionic and others https://review.opendev.org/c/zuul/zuul-jobs/+/815142 | 17:24 |
| opendevreview | Clark Boylan proposed opendev/system-config master: Document Zuul's SIGUSR2 handler https://review.opendev.org/c/opendev/system-config/+/815134 | 17:37 |
| clarkb | that should actually build now | 17:37 |
| opendevreview | James E. Blair proposed zuul/zuul-jobs master: Update dstat to support bionic and others https://review.opendev.org/c/zuul/zuul-jobs/+/815142 | 17:54 |
| opendevreview | James E. Blair proposed zuul/zuul-jobs master: Update dstat to support bionic and others https://review.opendev.org/c/zuul/zuul-jobs/+/815142 | 17:56 |
| opendevreview | Clark Boylan proposed opendev/system-config master: Refactor infra-prod jobs for parallel running https://review.opendev.org/c/opendev/system-config/+/807672 | 18:25 |
| opendevreview | Clark Boylan proposed opendev/system-config master: infra-prod: clone source once https://review.opendev.org/c/opendev/system-config/+/807808 | 18:25 |
| clarkb | ianw: ^ I resolved the merge conflict I created with those changes and rebased the stack | 18:26 |
| opendevreview | James E. Blair proposed zuul/zuul-jobs master: Update dstat to support bionic and others https://review.opendev.org/c/zuul/zuul-jobs/+/815142 | 19:07 |
| opendevreview | James E. Blair proposed zuul/zuul-jobs master: Update dstat to support bionic and others https://review.opendev.org/c/zuul/zuul-jobs/+/815142 | 19:51 |
| clarkb | I went ahead and approved the sigusr2 docs update since frickler and fungi had both given similar feedback on a prior patchset and I adressed those comments and fungi +2'd | 19:58 |
| clarkb | actually wait fungi had another comment. The new UI doesn't show that very well | 19:58 |
| opendevreview | Clark Boylan proposed opendev/system-config master: Document Zuul's SIGUSR2 handler https://review.opendev.org/c/opendev/system-config/+/815134 | 20:03 |
| clarkb | fungi: ^ how is that? | 20:03 |
| clarkb | separately I wonder if gertty makes the comment render weird in gerrit web ui | 20:03 |
| clarkb | its not a patchset or file level comment | 20:04 |
| corvus | clarkb: which comment is non-obvious for you? | 20:13 |
| corvus | and separately -- a potential zuul fix for the problem frickler observed has merged; i think it'd be good to restart zuul this afternoon. i'll do that soon if no objections. | 20:15 |
| clarkb | corvus: fungi's comment on ps1 at 10:54am pacific. It says "couldn't hurt to say how to identify the daemon's PID accurately." | 20:15 |
| clarkb | corvus: I think there are two things happening there. First is that it was against ps1 and not ps3 (not sure if that was intentional?) but the other is that the comment isn't against a file or the patchset itself so doesn't get the comment icon on it | 20:16 |
| clarkb | the gerrit summary view shows you the speech bubble when you've got comments to address but that didn't happen here so I missed it | 20:16 |
| clarkb | corvus: no objections from me for doing a restart. I'll be around for the most part too. Though I think its shaping up to be a quiet afternoon as everyone is tired post ptg :) | 20:17 |
| corvus | clarkb: so basically, you're inclined to look for the comment bubble and disregard other things in the "change log"? | 20:19 |
| clarkb | corvus: I don't think thats totally accurate. I opened the change and skimmed the log but gerrit just howed me [..] and I skipped over it | 20:21 |
| clarkb | then on a different line it said +2 so I went with it | 20:21 |
| corvus | the "[...]" is literally part of the comment text, so that's probably an unfortunate conicidence that that happened to show up at the beginning... | 20:22 |
| clarkb | ah | 20:22 |
| clarkb | the next bit seems to be quoted too? maybe that is why it renders weird? | 20:23 |
| corvus | it starts collapsed, but so do all the other comments | 20:23 |
| corvus | yeah, that looks like a markdown quote (may be accidental?) | 20:23 |
| clarkb | corvus: if I compare it to other top level comments I see the entire top level comment by default. I think what happened here is gerrit got smart with what it thought was a quote so it collapsed most of the comment | 20:25 |
| corvus | oh interesting | 20:25 |
| clarkb | https://review.opendev.org/c/opendev/infra-specs/+/810990 for example has a top level comment as well as inline comments from me. But you can see all of my top level comment there | 20:26 |
| clarkb | it isn't clear to me if my top level comment had been longer if gerrit would've trimmed it | 20:27 |
| clarkb | but ya I suspect it has to do with the quoting and gerrit treats that as a rendering break and trimmed what is show by default | 20:27 |
| corvus | yeah that seems likely, since it chose to break there and not just after the 1st line | 20:29 |
| fungi | clarkb: i had commented on patchset 1 originally, but didn't see any indication it was acknowledged or addressed in subsequent revisions and thought it might have been missed, so i quoted my prior comment in a new comment as a quick reminder of the suggestion. but yes in order to avoid over-quoting i trimmed the quoted block to just what i meant to point out and put in a [...] line to indicate | 20:32 |
| fungi | i had trimmed out text there | 20:32 |
| clarkb | got it. I guess it would help to add a bit more text because gerrit renders oddly in that case | 20:34 |
| clarkb | fungi: did you quote it and post it as a top level comment? | 20:36 |
| clarkb | That is the other confusing bit since quoting the inline comment should remain an inline comment? I guess I can test that | 20:36 |
| fungi | i used the reply button in gertty. i don't know what a top level comment is. it's just a review comment | 20:36 |
| corvus | "change message" i think is the technical term for what gertty does there | 20:36 |
| corvus | and it's not a gerrit-threaded reply even if you hit the reply button (the gertty reply button predates gerrit-internal threads) | 20:37 |
| clarkb | I just posted a quoted reply to the same comment that fungi repsonded to and you can see the difference between what gertty and gerrit does | 20:37 |
| corvus | so it just copies the text | 20:37 |
| fungi | yeah, i copied the inline comment quote into a change message because i don't think you can quote with inline comment replies | 20:37 |
| fungi | in the future i'll just say "did you see my comment on patchset 1" instead or something | 20:38 |
| clarkb | interestingly gerrit applies it to ps1 | 20:38 |
| clarkb | er ps4 and gerrty to ps1 | 20:38 |
| fungi | interesting | 20:38 |
| clarkb | oh except the inline comment is to ps1 but the top level indicator for it is ps4. That isn't confusing at all :) | 20:38 |
| clarkb | I expected it to be ps1 across the baord given the quote context | 20:39 |
| corvus | i suspect gertty posted the change message to ps1 since fungi hit reply to change message on ps1 to create it | 20:40 |
| fungi | yeah, i assumed it would be to ps1 (gertty shows it that way to me) | 20:40 |
| clarkb | ya the reply to the inlien comment is noted as ps1 but the top level comment is noted as ps4 | 20:42 |
| clarkb | So it seems the speech bubble means "open to see inline comments" and the top level comment is rendered directly possibly in a limited version depending on rendering rules for newlines/quoting etc | 20:43 |
| corvus | ++ | 20:43 |
| fungi | amusingly this is how it ends up showing in gertty for me: https://paste.opendev.org/show/810176/ | 20:43 |
| clarkb | I think gerrit eating the context after the [...] is what created the original confusion | 20:43 |
| fungi | yeah, gertty shows me exactly what i entered, so i was entirely unaware there was anything odd | 20:44 |
| clarkb | they have definitely complicated the expectations around comments with things like attention sets and the like | 20:48 |
| clarkb | and that is true for users of the web UI too (there are new expectations to get the state transitions right) | 20:48 |
| clarkb | one way to deal with this is to hit expand all when reading comments. Unfortauntely it doesn't look like I can tell it to show expanded by default | 20:51 |
| clarkb | but I can probably try to get into the habit of hitting that button first | 20:51 |
| fungi | well, also more generally it was fine if you had just let it merge, i left a +2 on that revision indicating i was already fine with it as-is | 21:04 |
| clarkb | matrix has decided to stop working for me | 21:07 |
| clarkb | seems to affect all the servers I'm talking to | 21:07 |
| clarkb | anyone else experiencing this? | 21:08 |
| clarkb | fungi: when I noticed what I had missed I wanted to fix it :) | 21:17 |
| clarkb | corvus: do you see ^? | 21:24 |
| clarkb | wondering if your matrix client is working | 21:24 |
| clarkb | https://status.matrix.org/ I don't know what I didn't look earlier, maybe because I thought it was more decentralized than that, but my user is a matrix.org user and the oftc bridge is on matrix.org too | 21:26 |
| clarkb | and now it seems to be back | 21:37 |
| clarkb | looks like almost an hour long loss of the oftc matrix bridge. Otherwise stuff is working | 21:38 |
| corvus | i look forward to reading later whatever happened between "20:48:37 clarkb | and that is true for users" and "21:37:47 clarkb | and now it seems to be back" :) | 21:47 |
| clarkb | corvus: I found that hitting expand comments in the gerrit ui works around some of the clunkyness here but there is no way to expand it by default so you have to click the button. And then it was me talking about the matrix outage trying to figure out if it was my end or their end | 21:48 |
| corvus | ah yep. i caught up on https://meetings.opendev.org/irclogs/%23opendev/%23opendev.2021-10-22.log.html | 21:49 |
| corvus | i'm guessing we matrix users won't actually get the missing messages in this case since the bridge is associated with the homeserver that failed | 21:49 |
| clarkb | ya that is my assumption too | 21:50 |
| clarkb | and now fastmail is down. They don't seem to have noticed yet | 22:19 |
| clarkb | fungi: I was going to respond to zigo's latest email pointing out build, but my email provider ^ is not up right now | 22:30 |
| fungi | ahh | 22:31 |
| fungi | i've not seen it yet, i don't think, checking | 22:31 |
| opendevreview | James E. Blair proposed zuul/zuul-jobs master: ensure-zookeeper: eliminate the tmpfs size limit https://review.opendev.org/c/zuul/zuul-jobs/+/815163 | 22:32 |
| fungi | clarkb: also it's already in debian bullseye: https://packages.debian.org/python3-build | 22:32 |
| clarkb | its an interesting problem because I can't open thei rsupport site. I could send them email thorugh another provider but I'm worried they won't get it | 22:35 |
| clarkb | if I had a twitter I could tweet at them Iguess but I don't have that. Things get weird when it is the comms tools that break | 22:35 |
| fungi | replied | 22:40 |
| corvus | imma gonna do that zuul restart thingy now | 23:30 |
| fungi | sounds good! | 23:31 |
| * clarkb is still around | 23:32 | |
| fungi | this gets us the presumptive fix for the zk disconnect issue, as well as version info in the components endpoint, looks like | 23:33 |
| corvus | yep | 23:33 |
| fungi | oh, and the key deletion fix | 23:33 |
| clarkb | the key deletion thing was test only | 23:33 |
| clarkb | it wasn't broken but the testing should've checked a few extr abits | 23:33 |
| corvus | hrm, we have no release notes... i guess i should make one real quick | 23:34 |
| fungi | oh, right, key deletion change landed earlier, so that's just added testing | 23:34 |
| corvus | mostly because i want to have a good rollback release before we land the pipeline series | 23:34 |
| fungi | still new since the last tag though | 23:34 |
| fungi | makes sense, the pipeline stack looked huge | 23:34 |
| clarkb | heh fastmail decided to stop being broken and sent the email draft that I had tried to send earlier but couldn't | 23:35 |
| fungi | nice | 23:36 |
| corvus | https://storage.gra.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_58e/760807/7/check/zuul-build-dashboard-opendev/58e0e86/npm/html/ | 23:38 |
| corvus | if you want to check out the prototype components display | 23:38 |
| fungi | ooh, now *that's* slick! | 23:40 |
| corvus | yeah, this thing's starting to look like a system :) | 23:41 |
| fungi | i guess those git commit ids correspond to the ephemeral merge commits from the gate pipeline still | 23:42 |
| corvus | yep | 23:42 |
| clarkb | fungi: yes since we deploy from the images built in the gate | 23:42 |
| fungi | wish i could think of a good way to remap those | 23:42 |
| clarkb | fungi: if you look at the image in dockerhub it shows you the change | 23:42 |
| fungi | but i suppose "have zuul push" is the real answer | 23:43 |
| clarkb | which manes you cna manually map them at least | 23:43 |
| corvus | zuul push would solve that :/ | 23:43 |
| fungi | right | 23:43 |
| corvus | hrm... | 23:43 |
| corvus | i wonder if there's any chance we could change the image metadata during promote | 23:43 |
| corvus | i guess that would technically make a new image | 23:43 |
| fungi | we could substitute the pbr.json contents though? | 23:44 |
| fungi | oh, right, still it's a new image | 23:44 |
| corvus | hrm, pbr.json.... | 23:44 |
| corvus | so pbr writes a json file when it builds? | 23:45 |
| fungi | pbr.json is where the git commit id is stored, yes | 23:45 |
| fungi | alongside the python package metadata | 23:45 |
| corvus | so we could, in promote, open up the image, update pbr.json with the actual commit id, then push the updated image? [not saying it's a good idea, just physically possible] | 23:46 |
| fungi | you can even use standard python package metadata parsing tools to read it back without needing pbr at runtime | 23:46 |
| fungi | yeah, technically possible, though it will change the image checksum obviously | 23:46 |
| corvus | i think process-wise that really boils down to "build [part of] the image in promote." it would just be a really small part of the image that gets [re]built, so probably doesn't need extra testing | 23:47 |
| clarkb | I think zuul may be up? openstack tenant is loaded at least | 23:47 |
| corvus | all things considered, i don't like like that, so i don't think i want to pursue it. but helps with the brainstorming. | 23:47 |
| corvus | s/like like/like/ | 23:48 |
| corvus | re-enqueueing | 23:48 |
| corvus | maybe during the gate build we should include the change in the pbr.json version | 23:50 |
| corvus | removes one step from the mapping procedure | 23:50 |
| fungi | oh, yep we could do that, or add a zuul.json metadata file | 23:50 |
| corvus | re-enqueue done | 23:50 |
| corvus | #status restarted all of zuul on commit 7c377a93e020f20d4535207d9b22bdc303af4050 for zk disconnect/threadpool fix | 23:51 |
| opendevstatus | corvus: unknown command | 23:51 |
| corvus | #status log restarted all of zuul on commit 7c377a93e020f20d4535207d9b22bdc303af4050 for zk disconnect/threadpool fix | 23:51 |
| opendevstatus | corvus: finished logging | 23:51 |
| corvus | should be a command :) | 23:51 |
| fungi | parsing arbitrary package metadata is fairly trivial, modulo the switch from pkg_resources to importlib circa python 3.8, this is how i've done it elsewhere for reading pbr's metadata without using pbr at runtime: https://mudpy.org/gitweb?p=mudpy.git;a=blob;f=mudpy/version.py;h=d99617e590aa218e640583d312429ec846205cf6;hb=HEAD#l20 | 23:53 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!