| @mnasiadka:matrix.org | Clark: there is also GreptimeDB which is an alternative to Thanos (claiming to be more lightweight) - but it’s getting to 1.0 version at the moment | 05:00 |
|---|---|---|
| @mnaser:matrix.org | I'm at KubeCon this week, I had a follow up addressing the reviews done but forgot to hit git review before leaving home so that's sitting waiting at home :) | 09:30 |
| -@gerrit:opendev.org- Mohammed Naser proposed: [zuul/zuul-jobs] 982064: Pass --upgrade-deps when creating venvs with python -m venv https://review.opendev.org/c/zuul/zuul-jobs/+/982064 | 09:55 | |
| -@gerrit:opendev.org- Bennet Benny proposed: [zuul/zuul-jobs] 982065: Fix build>=1.4 incompatibility with older pip in ensure-python-command https://review.opendev.org/c/zuul/zuul-jobs/+/982065 | 09:56 | |
| @harbott.osism.tech:regio.chat | arnaudm: did you get any feedback regarding the swift issues? I'm wondering whether we should just try re-enabling the upload or whether more testing would be helpful | 10:59 |
| -@gerrit:opendev.org- Bennet Benny proposed: [zuul/zuul-jobs] 982083: Pass --upgrade-deps to venv creation on Python >= 3.9 https://review.opendev.org/c/zuul/zuul-jobs/+/982083 | 13:03 | |
| @fungicide:matrix.org | Jens Harbott: we should simply be able to check a dnm change that uses base-test | 13:53 |
| @fungicide:matrix.org | at least to verify that it's not completely failing right now | 13:53 |
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/zuul-jobs] 982092: Pass --upgrade-deps to venv creation on Python >= 3.9 https://review.opendev.org/c/zuul/zuul-jobs/+/982092 | 13:55 | |
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/zuul-jobs] 982092: Pass --upgrade-deps to venv creation on Python >= 3.9 https://review.opendev.org/c/zuul/zuul-jobs/+/982092 | 13:57 | |
| -@gerrit:opendev.org- Jason Paroly proposed: [openstack/diskimage-builder] 982098: Add unused argument linting https://review.opendev.org/c/openstack/diskimage-builder/+/982098 | 14:39 | |
| -@gerrit:opendev.org- Zuul merged on behalf of Michal Nasiadka: [opendev/zone-opendev.org] 981956: Drop mirror01.iad3.openmetal https://review.opendev.org/c/opendev/zone-opendev.org/+/981956 | 15:48 | |
| -@gerrit:opendev.org- Clark Boylan proposed: [opendev/system-config] 982125: Explicitly enable Gerrit robot comments https://review.opendev.org/c/opendev/system-config/+/982125 | 15:57 | |
| @clarkb:matrix.org | another change to land before we upgrade to 3.12 | 15:58 |
| @mnasiadka:matrix.org | Clark: I've got some flu or something similar, I'm happy to delete the mirror01.iad3.openmetal server, but it might need to wait for my better day :) | 16:31 |
| @fungicide:matrix.org | i don't think there's any urgency | 16:32 |
| @jim:acmegating.com | yes, don't sudo or operate heavy machinery on cold medication :) | 16:40 |
| @clarkb:matrix.org | ++ get better and we'll get back to this | 16:44 |
| @arnaudm:matrix.org | hey harbott.osism.tech I still dont have news from the team, so for now, better to stay like this | 16:52 |
| @fungicide:matrix.org | thanks for following up arnaudm! | 16:54 |
| @arnaudm:matrix.org | the team is asking you to create a ticket from your account, this will trigger a request to check. I am sorry about this, I am not managing swift directly | 16:57 |
| @clarkb:matrix.org | I'm currently working through my gerrit upgrade prep doc and one of the items I want to followup on us the use of the lucene `~` operator. Gerrit 3.12 has updated lucene to a version that drops this `~` operator. Does anyone know if it is in use? I'm also trying to think how I might formulate a codesearch query to look for it, but that seems error prone and likely incomplete | 17:45 |
| @clarkb:matrix.org | I guess this was a performance related change | 17:46 |
| @clarkb:matrix.org | the lucene documentation suggests you use `[^xyz]` instead of `~(xyz)` | 17:48 |
| @clarkb:matrix.org | My guess is that this is unlikely to be a common query operator and that queries can be updated in many cases if this was used at all | 17:49 |
| @fungicide:matrix.org | i guess the contexts where it might have been used are change queries and custom dashboards? | 17:49 |
| @clarkb:matrix.org | yup or just people who manually type things in occasionally | 17:50 |
| @clarkb:matrix.org | I guess the main thing to check is our submit requirements | 17:50 |
| @fungicide:matrix.org | i'm not directly aware of any use, but it's innocuous enough that i probably wouldn't have committed it to memory if i'd seen it | 17:50 |
| @clarkb:matrix.org | since we rely on those for merge behaviors. I will check submit-requirements | 17:50 |
| @clarkb:matrix.org | I don't see any ~'s in our openstack/project-config acls (via `git grep '\~' gerrit/`) and the All-Projects rules in system-config also appear fine. I'm going to consider this good enough | 17:57 |
| @fungicide:matrix.org | concur | 17:58 |
| @clarkb:matrix.org | Gerrit currently allows users to delete their own accounst apparently. Gerrit 3.12 allows us to disable this functionality. I believe that these are always soft deletes (removing identifying info but keeping the account number and some minimal info around so that change ownership and reviews can be attributed to something). Do we want to disable this functionality as part of the upgrade? I'm thinking it hasn't been a problem so far so I think I'm ok with allowing people to opt into this | 18:00 |
| @clarkb:matrix.org | eg keep the current behavior of allowing self deletion for your own account | 18:00 |
| @fungicide:matrix.org | i'm in favor of keeping it unless there's a good reason to disable | 18:01 |
| @fungicide:matrix.org | while account deletion requests don't come up often, it's a feature that users in jurisdictions governed by gdpr and similar regulations are increasingly expecting, and one less thing for us to have to do for them | 18:02 |
| @clarkb:matrix.org | ++ | 18:03 |
| @jim:acmegating.com | i don't see any use of ~ in zuul's gerrit driver | 18:06 |
| @jim:acmegating.com | i mean, for searches. :) it does show up in change id construction | 18:07 |
| @clarkb:matrix.org | thank you for checking | 18:24 |
| @clarkb:matrix.org | fungi: corvus: line 104 of https://etherpad.opendev.org/p/gerrit-upgrade-3.12 describes a new feature in Gerrit that allows us to mark email domains as having case insensitive email addresses. I think the idea there is hosts like gmail are insensitive so informing gerrit of this can help avoid "collisions". Is that something you think is important? I don't think any of our current notedb issues are related to this email behavior quirk so I think I'm inclined to just leave it as is. But ya'll deal with email far more than I do and may have other opinions | 18:28 |
| @fungicide:matrix.org | i wouldn't worry about it | 18:29 |
| @fungicide:matrix.org | in e-mail the user part (what comes before the @) is assumed to be case-sensitive per standard, software making nonstandard assumptions is an ugly hack i'd rather avoid unless we discover we need it | 18:31 |
| @jim:acmegating.com | yeah, and presumably we shouldn't rely on that for security (i mean, we can't possibly curate an exhaustive list). so we'd expect the usual email validation routines to stop those collisions. | 18:32 |
| @clarkb:matrix.org | fungi: I think the issue is that gmail for example is case insensitive | 18:32 |
| @clarkb:matrix.org | so people could potentially have two conflicting accounts with the same email address using different case. But I agree I'm not sure that is a situation we really need to worry about? | 18:33 |
| @clarkb:matrix.org | the existing verification process should ensure that the same human control both accounts. If you want two accounts that way have at it? | 18:33 |
| @fungicide:matrix.org | right | 18:34 |
| @jim:acmegating.com | yeah, i think so | 18:34 |
| @fungicide:matrix.org | and just because gmail doesn't allow alternate-case versions of addresses to go to different mailboxes today, that's not to say they can't change their minds in the future | 18:35 |
| @fungicide:matrix.org | in fact they'd be entirely standard-compliant in their choice to do so, if they wanted | 18:36 |
| @clarkb:matrix.org | ok cool. This is less work on our part too | 18:36 |
| @clarkb:matrix.org | I do wish that more of these gerrit changes included the motivation for the update | 18:36 |
| @clarkb:matrix.org | like did someone have problems we should know about? maybe but that isn't recorded anywhere that I can see | 18:36 |
| @fungicide:matrix.org | "motivation: google says so" | 18:36 |
| @clarkb:matrix.org | it looks like some of the issue they are trying to address is on the query side iwthin gerrit. searching for user:foo@example.com vs user:Foo@example.com | 18:37 |
| @clarkb:matrix.org | but that hasn't been a problem for us so ya I think we can keep this as is | 18:37 |
| @clarkb:matrix.org | I suspect features like this make more sense at a single company where everyone has the same email domain in their accounts | 18:41 |
| @clarkb:matrix.org | ok I think I'm through most of what I can address before I actually start working with the newer version. I'll plan to do a test upgrade after lunch today and take notes on that process | 18:53 |
| @clarkb:matrix.org | fungi: did you ever test the held lists server with anubis configured? Thoughts on whether or not we want to proceed with that? In theory it has no effect on the openstack release process so should be safe right? But also the server seems responsive right now so may not be urgent | 18:56 |
| @fungicide:matrix.org | oh! not yet, thanks for the reminder, i'll try it out now | 18:56 |
| @fungicide:matrix.org | seems to be working fine for me in a webkit-based browser too. switching between mailman domains kicks anubis checks in again the first time i hit a new one but not thereafter (stashes a cookie i guess?) | 18:59 |
| @fungicide:matrix.org | i see that we still have the default anubis waifu mascot. did they make that configurable/disableable? | 19:00 |
| @clarkb:matrix.org | Yes you get a cookie so as long as you are on the same domain you shouldn't be asked to recalculate hashes until the cookie is no longer valid. Re the mascot I think that may be part of the paid update? You might be able to bind mount over the asset in the container or something | 19:03 |
| @clarkb:matrix.org | https://anubis.techaro.lol/docs/admin/botstopper/ | 19:04 |
| @fungicide:matrix.org | "paid update" huh? | 19:12 |
| @fungicide:matrix.org | i guess helping mitigate the ai goldrush has created some open-core-like business opportunities too | 19:22 |
| @clarkb:matrix.org | I just completed my first manual upgrade of gerrit 3.11 to 3.12. I noticed during the init step that lucene seems to trigger some warning about possibly wanting to use an incubated vector api implementation. I tested running with the flag enabling that api enabled for init only (not the running gerrit) and the output changes indicating that it is using floating point vectors with a preferred size of 128 bits | 21:24 |
| @clarkb:matrix.org | I'll go read up on lucene and this java vector thing next | 21:24 |
| @clarkb:matrix.org | but other than that I would say the process went about how I expected it to | 21:25 |
| @clarkb:matrix.org | https://lucene.apache.org/core/9_9_1/core/org/apache/lucene/util/VectorUtil.html this implies that it may be hardware specific so the held node environment may be influencing things | 21:28 |
| @clarkb:matrix.org | this is interesting the production server does support fma instructions according to cpuinfo but the test node does not. So it must be optional which I guess makes sense after reading those messages | 21:32 |
| @clarkb:matrix.org | I'll ask on Gerrit's discord if this is a jvm flag people are setting or if being in incubator is more risk than reward | 21:33 |
| @clarkb:matrix.org | I suspect that this would provide some performance benefits for our indexes in Gerrit. But we'll see if there is anyone else with feedback either because they already tried it or just with better jvm knowledge than me | 21:36 |
| @clarkb:matrix.org | readnig more about the incubator modules it seems like the apis themselves are what are incubating. It doesn't seem like the issues are to do wit hstability? | 21:44 |
| -@gerrit:opendev.org- Jeremy Stanley https://matrix.to/#/@fungicide:matrix.org proposed: | 22:20 | |
| - [openstack/project-config] 982178: Temporarily remove release docs semaphores https://review.opendev.org/c/openstack/project-config/+/982178 | ||
| - [openstack/project-config] 982179: Revert "Temporarily remove release docs semaphores" https://review.opendev.org/c/openstack/project-config/+/982179 | ||
| -@gerrit:opendev.org- Clark Boylan proposed: [opendev/system-config] 982180: Add python 3.14 python images https://review.opendev.org/c/opendev/system-config/+/982180 | 22:25 | |
| @clarkb:matrix.org | Ubuntu Resolute will apparently have python3.14. Thinking ahead a bit we can avoid some extra work by skipping the step through 3.13 and just target 3.14. This idea is why i've pushed ^ | 22:34 |
| @clarkb:matrix.org | This is also a good reminder that the next ubuntu release is somethign we should have in mind for adding into zuul as a test image. I think that we should drop xenial from our mirrors and add resolute. maybe that is safe enough to do after the openstack release? | 22:35 |
| @jim:acmegating.com | do we have room to start populating the resolute mirrors now, or do we need to drop xenial first? | 22:35 |
| @clarkb:matrix.org | I'm pretty sure I've removed xenial from opendev related stuff at this point. But there is a long tail of under or non maintained stuff that will likely break. At this point I think that is acceptible as it has been long enough | 22:35 |
| @clarkb:matrix.org | corvus: I think it would be tight but just fit right now | 22:36 |
| @clarkb:matrix.org | based on what I see in afs. We may need to increase the afs volume size a bit, but we're under the 2TB max for ubuntu currently with enough room for resolute to likely fit as well as for things to fit into the cluster overall | 22:36 |
| @jim:acmegating.com | ok. or it may be safer to experimentally add the resolute image without mirrors at first. | 22:36 |
| @jim:acmegating.com | if we decide to drop xenial after release anyway, it won't be long. | 22:37 |
| @clarkb:matrix.org | yup I think that is an option too | 22:37 |
| @clarkb:matrix.org | fungi: I don't think openstack proper has relied on xenial for a while. Do you think we need to communicate this to them? Or maybe just send a note to service-announce? | 22:38 |
| @clarkb:matrix.org | oh wait we already removed xenial? its bionic that I'm thinking of | 22:40 |
| @clarkb:matrix.org | I removed bionic from opendev and we've been threatening to drop it entirely due to ansible updates in zuul. But I think now is the time | 22:40 |
| @clarkb:matrix.org | and I think it has been long enough for bionic too | 22:40 |
| @fungicide:matrix.org | i don't think so, no | 22:40 |
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [opendev/zuul-providers] 982182: Add Ubuntu resolute image build job https://review.opendev.org/c/opendev/zuul-providers/+/982182 | 22:40 | |
| @fungicide:matrix.org | yeah, both can go at this point, probably | 22:41 |
| @jim:acmegating.com | Clark: ^ not sure if we need to do special pre-release stuff for the image build, but that should tell us | 22:41 |
| @clarkb:matrix.org | ya I mixed up xenial and bionic but I don't think the approach changes | 22:41 |
| @jim:acmegating.com | (anyone feel free to update that change) | 22:41 |
| @fungicide:matrix.org | the oldest openstack branch at this point is unmaintained/yoga and https://governance.openstack.org/tc/reference/runtimes/yoga.html supported ubuntu 20.04 lts (focal), so xenial and bionic are old news from openstack's perspective | 22:43 |
| @fungicide:matrix.org | buhbye | 22:43 |
| @clarkb:matrix.org | I'll send a notice tomorrow to service-announce that we are going to begin the process of dropping bionic from our mirrors and then zuul itself | 22:49 |
| @fungicide:matrix.org | thanks! | 22:52 |
Generated by irclog2html.py 4.1.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!