noonedeadpunk | hey folks! I start thinking about EL10 which is not present in nodepool images becuase there's no CPU compatability in quite some of providers... | 09:23 |
---|---|---|
noonedeadpunk | But then I start thinking, that potentially it should be possible to add CentOS Stream 10 image only to nodesets which do have support? | 09:24 |
noonedeadpunk | Ie raxflex should have it for sure? | 09:24 |
noonedeadpunk | or there is a reason why it's not an option I can't think about right away? | 09:25 |
noonedeadpunk | as OpenStack PTI has dropped EL9 from tested platforms for 2025.2 | 09:26 |
frickler | afaict even support for building images isn't there yet | 09:59 |
frickler | also we don't know yet which providers would actually support these, iirc tonyb wanted to do some test for that? | 10:01 |
noonedeadpunk | well, I'm building fedora 41 with DIB, so it should not be an issue to bring suypport | 10:48 |
noonedeadpunk | and I can look into that as well | 10:48 |
noonedeadpunk | (and anyway I think I need to do that for internal usage anyway) | 10:49 |
noonedeadpunk | but wanted to ask/consult if you think it can be a valid option at all | 10:49 |
mnasiadka | There's a patch for CS10, but the Glean depends-on needs some love | 11:19 |
mnasiadka | I'm planning to have a look this week | 11:19 |
mnasiadka | I think tonyb was planning to have a look on the Zuul providers situation | 11:19 |
fungi | noonedeadpunk: to summarize, yes that's already the plan, feel free to help tonyb and mnasiadka get it across the finish line once you get up to speed on thr progress so far | 12:02 |
opendevreview | Michal Nasiadka proposed opendev/glean master: Add support for CentOS 10 keyfiles https://review.opendev.org/c/opendev/glean/+/941672 | 13:29 |
opendevreview | Jeremy Stanley proposed opendev/git-review master: Add a release note for list by branch https://review.opendev.org/c/opendev/git-review/+/950314 | 13:48 |
fungi | apart from ^ does anyone see anything else in https://paste.opendev.org/show/bOwm4kjp4SlER8Yc6gxP/ (commits since 2.4.0) which needs a release note and is missing from https://docs.opendev.org/opendev/git-review/latest/releasenotes.html still? | 13:50 |
fungi | i'm hoping to tag a 2.5.0 release today or early this week at least. or should it be 3.0.0 since we're dropping the autotopic behavior? | 13:53 |
frickler | fungi: renos lgtm and I'd be fine with 2.5.0 | 14:06 |
fungi | thanks! | 14:07 |
clarkb | noonedeadpunk: frickler: for testing specificly the issue is dib CI runs an image build that it boots. This boot fails when the job runs on a cloud that cannot support the hardware. I think tonyb has a patch up to make qemu emulate the needed cpu features in those cases though whcih should be fine if it isn't too slow to run the job within a reasonable time frame | 14:47 |
clarkb | separately it still isn't clear which clouds can run centos 10 stream and which cannot. tonyb was going to work on getting a definitive answer to that. Then based on that we can decide if we are going to add the images at all. I don't think we should if only raxflex can boot them (but I'm pretty confident that openmetal and vexxhost can as well. OVH is the other big question mark) | 14:48 |
clarkb | infra-root EMS reports the maintenance around authentication updates for our matrix homeserver has been completed | 14:53 |
clarkb | there haven't been any gerrit changes reported to the zuul room since. That may just be coincidence or the bot is indeed unhappy with the change. I'm not sure. If you push something you expect to be reported to that room and don't get a notice from the bot can you let us know here? | 14:54 |
fungi | i remember tristanC[m] mentioned looking into what updates would be needed for it | 14:56 |
clarkb | ya there was some confusion over whether ot not changes were needed? We should know soon :) | 14:56 |
clarkb | I believe the last message here: https://meetings.opendev.org/irclogs/%23zuul/%23zuul.2025-05-19.log.html is after the update so the logging seems to still work | 14:57 |
clarkb | (it uses a popular library so I expect worst case with logging is we just rebuild the image and redeploy it and that will pull in any necessary updates should that stop working) | 14:58 |
clarkb | I'm doing my weekly software updates then a reboot then I need to work on some paperwork type stuff today. Things seem generally quiet so don't anticipate problems | 15:00 |
clarkb | fungi: the git review change has been approved and I think that looks good for a release | 15:00 |
noonedeadpunk | if we can not and not going to have means to test el10 at all, then potentially we should drop it from OpenStack PTI I'd assume | 15:03 |
clarkb | personally I haev machines at home that cannot run it. As a result I've got some very strong opinions :) | 15:05 |
clarkb | I think the suse approach is much much better and strikes a balance between what debian does and what rhel is doing. Basically if the hardware can support it install mix in packages that enables those features | 15:06 |
fungi | i'm going to step out to grab an early lunch and run an errand, will probably be gone for about an hour and then work on doing the git-review 2.5.0 release | 15:07 |
clarkb | we want to talk about environmental friendlyness and certainly replacing inefficient hardware is part of that. But the cost ot throw out perfectly good hardware simply beacuse someone decided compiler flags should update is also not great for the environment. Similar to replacing a gas car with an ev. Sometimes you're better off just using the gas vehicle (depends on miles driven etc | 15:08 |
clarkb | etc) | 15:08 |
frickler | centos/rocky is only listed as optional in the PTI currently fwiw | 15:19 |
noonedeadpunk | clarkb: I totally agree here and I don't find EL approach reasonable either. But SUSE dumped their OpenStack efforts kinda... | 15:27 |
noonedeadpunk | frickler: yes, they are optional, but there is no such option for projects, isn't it? | 15:28 |
frickler | noonedeadpunk: options for projects to test with el10? they could build/use a 3rd party CI like software factory here https://review.opendev.org/c/openstack/devstack/+/950298 | 15:40 |
noonedeadpunk | um. I kinda don't agree here. I don't have own own stack for testing. And suggesting to go and buy one is weird... | 15:43 |
noonedeadpunk | dunno | 15:43 |
noonedeadpunk | I don't think I can go and tell them - add my random project to your CI | 15:43 |
noonedeadpunk | as 3rd party CI is kind of other way around a bit | 15:44 |
noonedeadpunk | if some 3rd party want to ensure that their driver/software works and have interest in testing code path - they add it | 15:44 |
noonedeadpunk | but it's not on projects at all | 15:45 |
noonedeadpunk | so optional for me is that project may or may not add it. And we are in situation that they can not, unless they own some CI resources or get agrrement with another company to get their CI arranged | 15:46 |
opendevreview | Merged opendev/git-review master: Add a release note for list by branch https://review.opendev.org/c/opendev/git-review/+/950314 | 16:22 |
clarkb | infra-root I've started a draft for a summit cfp talk about opendev's ci/cd setup here https://etherpad.opendev.org/p/w1rSGQonbYP5ysn61CSc if you have a moment I'm open to feedback on that | 17:02 |
fungi | lgtm! it's a bit longer than my typical abstract, but as long as it's under whatever word limit the submission form enforces i think that's fine | 18:04 |
fungi | you could elide some of the sausagemaking details if it comes down to that | 18:04 |
fungi | infra-root: i've locally tagged git-review commit a3be713b85919706dcf578736fd04e4ba21ca09d as 2.5.0, let me know if you have any objections and otherwise i'll push it at/after 19:00 utc (in about an hour) | 18:05 |
clarkb | fungi: thanks for the feedback and ya I havne't put it in the submission form. If it complains I'll trim | 18:07 |
clarkb | fungi: that hash and tag name lgtm | 18:07 |
fungi | thanks for confirming! | 18:07 |
opendevreview | Clark Boylan proposed opendev/engagement master: Match closed changes closed time against date range https://review.opendev.org/c/opendev/engagement/+/950350 | 18:38 |
opendevreview | Merged opendev/engagement master: Match closed changes closed time against date range https://review.opendev.org/c/opendev/engagement/+/950350 | 18:58 |
tonyb | fungi: FWIW: No objection on the git-review release from me | 19:02 |
fungi | cool, pushing it now | 19:03 |
fungi | https://pypi.org/project/git-review/ has the new version now | 19:06 |
fungi | #status log Released git-review 2.5.0 | 19:06 |
opendevstatus | fungi: finished logging | 19:06 |
fungi | yay! this may also be the first successful run of opendev-publish-unversioned-nox-docs finally, https://docs.opendev.org/opendev/git-review/latest/releasenotes.html reflects the new tag without needing to merge any new changes after | 19:12 |
tonyb | \o/ | 20:19 |
tonyb | In trying to answer the question "how much x86_64-v3 capacity do we have" I noticed a couple of things. I'm not sure if they're normal | 20:20 |
tonyb | 1) in RAX (traditional) IAD there are a lot of servers in the `server list` in the ERROR state | 20:21 |
tonyb | 2) in RAX (traditional) IAD when trying to do `network list` I get an error about the network not being loaded and looking at grafana we have no network data: https://grafana.openstack.org/d/a8667d6647/nodepool3a-rackspace?orgId=1&from=now-6h&to=now&timezone=utc&var-region=$__all | 20:22 |
tonyb | so are those things "normal" ... they don't seem normal to me | 20:22 |
* tonyb + sudo /usr/launcher-venv/bin/openstack --os-cloud openstackjenkins-rax --os-region IAD server create --network public --key-name infra-root-keys-2024-04-08 --flavor | 20:24 | |
* tonyb performance1-8 --image ubuntu-noble-1747591840 --use-config-drive tonyb13.opendev.org | 20:24 | |
* tonyb Version 2 is deprecated, use alternative version 3 instead. | 20:24 | |
* tonyb Service 'network' is disabled because its configuration could not be loaded. | 20:24 | |
clarkb | there is no network api in rackspace classic so that is normal | 20:24 |
tonyb | Ah okay | 20:24 |
fungi | servers constanting getting stuck in booting/deleting error states in rax classic are common. ig it gets bad we usually ping jamesdenton_ about cleaning them up, i think | 20:24 |
clarkb | for 1) I think that is "normal" in that there are background error rates in various clouds and some of those servers get into error states that don't allow them to be automatically deleted by nodepool | 20:24 |
fungi | wow, me with teh typoz today | 20:24 |
tonyb | Okay I wont worry about the nodes in error and the fact there isn't a network api/service | 20:25 |
tonyb | I guess launch from sstem-config will help me determine the magic args for RAX traditional to boot a server | 20:28 |
* tonyb can also make typos ;P | 20:28 | |
clarkb | tonyb: I think you just drop the --network flag and you should be good | 20:30 |
tonyb | Okay | 20:30 |
tonyb | That does seem better | 20:32 |
opendevreview | Clark Boylan proposed opendev/engagement master: Collect reviewer and maintainer counts per project https://review.opendev.org/c/opendev/engagement/+/950369 | 22:39 |
clarkb | I've started putting our meeting agenda together. Anything else I should add there? | 22:56 |
clarkb | and sent | 23:26 |
Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!