Thursday, 2026-05-28

opendevreviewRodolfo Alonso proposed openstack/tempest master: Format license text according to PEP621  https://review.opendev.org/c/openstack/tempest/+/99043608:47
*** jgilaber_ is now known as jgilaber12:02
fricklerelodilles: gmaan: grenade for keystone is broken on 2025.1, do we drop it from the template or does each project need to make it non-voting to unblock their gate? https://zuul.opendev.org/t/openstack/build/99033083e2604780af0331d198219d8513:58
fricklerthis is blocking security backports, so kind of urgent IMO13:58
winiciusallan[m]hello o/ not sure if here is the right place to ask about it14:03
winiciusallan[m]I'd like to know if there is a way to run some custom script before the "install" step 14:04
winiciusallan[m]the context is I need to install a package in advance, but the devstack itself is running in a CI, and an additional step to install these packages would be best approach I believe14:04
winiciusallan[m]sorry, I forgot to mention this ^ is a question about devstack14:11
elodillesfrickler: i think the easiest way is to remove it from keystone, as it is added there explicitly (and don't forget to remove the 'integrated-gate-py3' removal either). otherwise it is defined here: https://opendev.org/openstack/openstack-zuul-jobs/src/commit/aebda82f8822e38db5bbd25ab31ea110792e8c2b/zuul.d/project-templates.yaml#L292914:34
elodilless/removal/template/14:35
clarkbwiniciusallan[m]: you can write a devstack plugin14:48
fricklerwiniciusallan[m]: is this for your own CI or for upstream? adding a job using the devstack role and adding a pre playbook performing your additional setup should be possible, too14:49
winiciusallan[m]is for a downstream project actually14:50
winiciusallan[m]i'm adopting vexxhost/magnum-cluster-api into gophercloud CI to properly test magnum's acceptance tests14:51
winiciusallan[m]but since magnum-cluster-api uses some rust code, it has a build dependency which breaks in Epoxy release14:51
winiciusallan[m]because it uses --no-build-isolation flag14:52
winiciusallan[m]when installing the package14:52
winiciusallan[m]i filled a bug for this https://github.com/vexxhost/magnum-cluster-api/issues/1045 but I was trying to work on a workaround for this14:53
gmaanfrickler: I will say remove the jobs which is same we did in past.15:24
opendevreviewMerged openstack/tempest master: Format license text according to PEP621  https://review.opendev.org/c/openstack/tempest/+/99043618:22
timburkehi! i've got five failing jobs across two stable branches i'd like a bit of help with, all either grenade, grenade-skip-level-always, or tempest-integrated-object-storage-ubuntu-jammy (but curiously *not* tempest-integrated-object-storage)21:28
timburkethree of them fail installing tempest (or old/tempest), complaining "ValueError: invalid pyproject.toml config: `project.license`."21:29
timburkeone fails to install sphinx due to constraints (===9.0.4) not matching requirements (!=2.1.0 and >=2.0.0)21:30
timburkeone one fails installing nova with "AttributeError: module 'setuptools.build_meta' has no attribute 'prepare_metadata_for_build_editable'. Did you mean: 'prepare_metadata_for_build_wheel'?21:30
timburke"21:30
timburkethe patches with the failing jobs are https://review.opendev.org/c/openstack/swift/+/990262 and https://review.opendev.org/c/openstack/swift/+/99035521:31
timburkehmm. looking at the discussion from a couple days ago, i guess the solution for the grenade and grenade-skip-level-always jobs may be to just drop them -- still leaves one project.license error and the sphinx trouble, though21:53
clarkbtimburke: 'one fails to install sphinx due to constraints (===9.0.4) not matching requirements (!=2.1.0 and >=2.0.0)' this usually indicates your python version is too old for the contrained version due to the constrained version having a python requires for newer python22:05
clarkbthe error message is bad because 9.0.4 is >=2.0.0 and not 2.1.0 but when it does the package listing it removes all versions for python versions that don't match the current python22:05
clarkbinvalid pyproject.toml config project.license is I think an indication that your setuptools version is too old to handle the modern pyproject.toml entries like project.license. This too may be due to your older python installing an older setuptools beacuse modern setuptools requires newer python22:07
clarkbso I would start there, determine which version of python was in use for both. Then check if sphinx 9.0.4 can install on that version and check what the newest setuptools can run on that version and see if that supports project.license22:08
timburkeok, so those are both probably due to the job still running on jammy... maybe the solution is to drop all three jobs for those stable branches...22:32
clarkbpossibly. I think stable/2025.1 is still technically a supported release so things should be working there even22:34
timburkewe removed it for master (in part because it was broken) in https://github.com/openstack/swift/commit/c051a0b1 about three months ago... there's a decent chance it would've been broken on the stable branches since then, too (we don't do many backports)22:34
clarkbbut unless people are staying on top of this stuff not surprising that the jobs would regress (and that is likely happening beyond swift too)22:35
opendevreviewMerged openstack/tempest master: Update ImageQuotaTest with force_tenant_isolation  https://review.opendev.org/c/openstack/tempest/+/98853223:26

Generated by irclog2html.py 4.1.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!