| *** ykarel_ is now known as ykarel | 07:35 | |
| opendevreview | Merged opendev/system-config master: Update zuul_reboot package upgrade error conditions https://review.opendev.org/c/opendev/system-config/+/968270 | 15:06 |
|---|---|---|
| fungi | looking at the latest task timeouts in post-run for https://review.opendev.org/966200 i think we should be increasing the wait for image checksums to be returned by the api. does that make sense? | 15:19 |
| clarkb | fungi: I think that checksum is calculated locally not the cloud api. But maybe I misunderstand what you mean? | 15:49 |
| clarkb | looking at https://zuul.opendev.org/t/opendev/build/839501858a3647a885bc0d9ec02cab9e/console we appear to start the hashing then about 31.5 minutes later check if they are done find that they are not and discover we are past our timeout | 15:52 |
| clarkb | I thought we were setting that timeout to a much longer value I seem to recall a change for that. Maybe that didn't have the effect we anticipated? | 15:53 |
| fungi | oh, got it. i was trying to figure out why the task only ran for 1 second and then timed out | 15:56 |
| fungi | i wonder why we called it "Wait for sha256" if we're generating it locally rather than polling the api | 15:57 |
| clarkb | fungi: it is an asynchronous ansible task that is waiting for the previuosly started hash summing task to complete | 15:59 |
| clarkb | fungi: the idea is we can do the swift upload which is network io concurrently with the hashing which is local io and cpu computation and not suffer performance impacts I think. But maybe that assumption is wrong and they are impacting one another | 15:59 |
| clarkb | https://codesearch.opendev.org/?q=upload_image_swift_hash_timeout&i=nope&literal=nope&files=&excludeFiles=&repos= maybe the chnage didn't merge yet? that seems to still be set to 10 minutes | 16:01 |
| fungi | oh, huh or it was a different one i changed to 20 minutes | 16:06 |
| clarkb | fungi: oh was it only 20 minutes? that is still shorter than the time it took there so maybe my query is insufficient to find it and it is 20 minutes but that is still too short | 16:07 |
| fungi | or maybe i'm thinking of https://review.opendev.org/968259 that increased the boot-timeout for osuosl | 16:07 |
| fungi | yeah, that was changed from 2 minutes to 10 | 16:08 |
| fungi | the other timeout change was that we upped the job to 3 hours | 16:08 |
| clarkb | ack so we probably just need a change to bump this additional timeout value to 60 minutes or even higher so that we can determine how much time is necessary | 16:09 |
| opendevreview | Clark Boylan proposed opendev/zuul-providers master: Increase upload_image_swift_hash_timeout https://review.opendev.org/c/opendev/zuul-providers/+/969271 | 16:47 |
| clarkb | fungi: ^ something like that maybe | 16:47 |
| corvus | i seem to recall suggesting that maybe we should just set the timeout in the role to a very big number or maybe disable it completely if possible? | 17:06 |
| clarkb | corvus: oh that works too. I think if we drop the retries value entirely then we'll wait for the until: clause to evaluate to true | 17:08 |
| clarkb | and then we can let the job timeout handle things | 17:08 |
| clarkb | I'll write that change momentarily | 17:08 |
| corvus | yeah i was just looking up the docs to try to confirm that | 17:08 |
| clarkb | oh wait async takes a timeout value too | 17:09 |
| corvus | i think using a big number may be the only way. so maybe we should just change the default for that variable in the role | 17:11 |
| corvus | 24h or something :) | 17:11 |
| clarkb | ya I can't find any indication that async: takes a "no timeout" value | 17:11 |
| opendevreview | Clark Boylan proposed zuul/zuul-jobs master: Set image upload hash timeout to 24 hours https://review.opendev.org/c/zuul/zuul-jobs/+/969275 | 17:15 |
| clarkb | corvus: ^ I think that should do it | 17:15 |
| corvus | clarkb: yep except readme doc update | 17:17 |
| opendevreview | Clark Boylan proposed zuul/zuul-jobs master: Set image upload hash timeout to 24 hours https://review.opendev.org/c/zuul/zuul-jobs/+/969275 | 17:19 |
| clarkb | readmes now updated too | 17:19 |
| corvus | +3 | 17:36 |
| clarkb | I abandoned the other change | 17:41 |
| opendevreview | Merged zuul/zuul-jobs master: Set image upload hash timeout to 24 hours https://review.opendev.org/c/zuul/zuul-jobs/+/969275 | 17:48 |
| fungi | pithon adds another digit: https://www.python.org/downloads/release/python-3141/ | 18:18 |
| fungi | though 3.14.15 won't come until early 2028 | 18:20 |
| corvus | #status log statusbot functional check | 19:25 |
| opendevstatus | corvus: finished logging | 19:25 |
| clarkb | does anyone remember if creating users for the oepndev.org matrix server happens through the ems management console? I think it must? | 19:50 |
| clarkb | looks like the gerrit bot is gerrit:opendev.org so status:opendev.org is probably what we want for that account | 19:54 |
| corvus | yes and sgtm | 20:24 |
| fungi | seems right, yep | 21:07 |
| clarkb | hrm adding a new user says an email address is required. Looking at the eavesdrop and gerritbot accounts neither appear to have an email address assoicated with them. I guess this is a new requirement? | 21:56 |
| clarkb | fungi: do you know if you can do infra-root+matrixstatus type email addresses with the email host for that address? Thinking that might be the simplest solution here | 21:57 |
| clarkb | I guess I can just send email to that address and see if it works | 21:58 |
| clarkb | hrm in the hosts configuration infra-root is the only email address listed as a valid address to register from. I feel like the way we've been trying to use this server is a bit of a corner case for them and in the past it didn't matter until they updated web forms? Anyway this implies to me that maybe I should just use infra-root but I worry that without unique addresses other | 22:03 |
| clarkb | things might get angry | 22:03 |
| clarkb | but also my test email hasn't arrived yet so thinking +matrixstatus won't work either | 22:04 |
| clarkb | https://element.io/en/help says `It's ultimately up to the administrator of the server to decide whether or not you need to use an email address when creating a Matrix account.` but I can't find a toggle to make it optional in the user creation for our server via the service | 22:08 |
| clarkb | https://docs.element.io/latest/element-cloud-documentation/element-matrix-services/add-users/ seems to show that it did indeed work without an email address at one time | 22:09 |
| clarkb | Beginning to wonder if this is worth a support ticket | 22:10 |
| clarkb | I'll pause here so that others can sanity check me (pebkac wouldn't surprise me) and switch over to figuring out the necessary configuration management updates for when we do have an account | 22:12 |
| clarkb | but if we think a support ticket makes sense I can submit one later | 22:12 |
| fungi | yeah, sounds like a new setting/default we'll need to override? | 22:12 |
| fungi | maybe it's hidden in the server options? | 22:13 |
| clarkb | I did look at the server config which is where I found the limit on which email addresses and domains we would accept registrations from | 22:13 |
| clarkb | but I couldn't find anything that indicated "allow registration without email" | 22:13 |
| fungi | yeah, i guess a support ticket is in order then | 22:18 |
| opendevreview | Clark Boylan proposed opendev/system-config master: Add matrix config support to statusbot deployment https://review.opendev.org/c/opendev/system-config/+/969328 | 22:51 |
| clarkb | I based ^ on the existing irc configuration. Will be interesting to see if things just explode due to not having valid auth in testing | 22:52 |
| clarkb | I think IRC servers will just accept the connection even if auth fails so things mostly work on the irc side? anyway we shall soon know | 22:52 |
| clarkb | oh I need to edit the hashtag | 22:52 |
| clarkb | just to followup on the +emailsubcategory thing I still don't see my email so either it got eaten by a spam filter, it got sorted into an unxpected folder or it doesn't work | 23:04 |
| clarkb | for some reason I thought we had tested this in the past and it did work but seems not to | 23:04 |
| corvus | clarkb: note on 328 | 23:05 |
| clarkb | corvus: yes, I think that value is in system-config so that testing works. Maybe the best thing to do here is move the username and password combo for both irc and matrix into the zuul template for the eavesdrop group to cover testing and then also expect it to be on bridge in a similar private group var setup | 23:07 |
| clarkb | corvus: but I agree getting it out of the role as a default when the default doesnt' work is a good idea | 23:07 |
| fungi | Subject: Testing from clarkb | 23:07 |
| corvus | yeah, that matches my mental model for how we do most things | 23:08 |
| fungi | it got delivered to INBOX.matrixstatus | 23:08 |
| clarkb | fungi: oh does it automatically sort into subfolders? | 23:08 |
| fungi | the delivery rules make new subfolders for any +extension yes | 23:08 |
| clarkb | fungi: ok and I'm guessing thunderbird doesn't automatically add new folders so I may need to ask imap to look again or something | 23:09 |
| clarkb | but good to know that is a potential solution to this problem | 23:09 |
| clarkb | once I get ci results back I'll work on a new patchset (just want to make sure I don't need to fix anything else ci may catch) | 23:10 |
| opendevreview | Merged opendev/zuul-providers master: Add trixie-arm64 https://review.opendev.org/c/opendev/zuul-providers/+/966200 | 23:21 |
| corvus | it ran the gauntlet! | 23:24 |
| opendevreview | Clark Boylan proposed opendev/system-config master: Add matrix config support to statusbot deployment https://review.opendev.org/c/opendev/system-config/+/969328 | 23:25 |
| opendevreview | Clark Boylan proposed opendev/system-config master: Move test IRC statusbot config into test specific vars file https://review.opendev.org/c/opendev/system-config/+/969330 | 23:25 |
| clarkb | corvus: ^ and that is the promised update. I decided to split the irc refactor into a parent change as I think that will make historical undersatnding better | 23:25 |
| clarkb | in theory that irc var location refactor is safe to alnd any time. But we don't have secret vars for the matrix config update yet so that one should hold off until I sort ou the account there | 23:31 |
| corvus | clarkb: you moved the server var; was that intentional? (i think it could stay in defaults or public hostvars)... | 23:35 |
| corvus | i feel like anything in playbooks/zuul/templates is something we're saying comes from bridge, and i don't think we want to make that private? | 23:37 |
| clarkb | corvus: oh yes good point. I moved it beacuse I put the homeserver value in there as part of the user for matrix but that isn't an equivalent setup for irc | 23:37 |
| clarkb | corvus: do you think the homeserver value should be a default value too? or do you think we should define that on bridge alongside the user id? | 23:39 |
| clarkb | (just to amke sure I understand the matrix side expectation) | 23:39 |
| opendevreview | Clark Boylan proposed opendev/system-config master: Move test IRC statusbot config into test specific vars file https://review.opendev.org/c/opendev/system-config/+/969330 | 23:42 |
| opendevreview | Clark Boylan proposed opendev/system-config master: Add matrix config support to statusbot deployment https://review.opendev.org/c/opendev/system-config/+/969328 | 23:42 |
| clarkb | that is irc fixed with my interpretation above. Happy to update the matrix change if we think the homeserver should go in defaults | 23:42 |
Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!