opendevreview | melanie witt proposed openstack/nova master: DNM try minimalistic imagebackend refactor https://review.opendev.org/c/openstack/nova/+/925635 | 02:35 |
---|---|---|
opendevreview | melanie witt proposed openstack/nova master: DNM try minimalistic imagebackend refactor cont'd https://review.opendev.org/c/openstack/nova/+/925838 | 02:35 |
opendevreview | melanie witt proposed openstack/nova master: libvirt: Move cache filename generation to imagebackend https://review.opendev.org/c/openstack/nova/+/930961 | 02:35 |
opendevreview | melanie witt proposed openstack/nova master: libvirt: Add base image format tracking via file extension https://review.opendev.org/c/openstack/nova/+/930962 | 02:35 |
opendevreview | melanie witt proposed openstack/nova master: libvirt: Handle acceptable but not validatable images https://review.opendev.org/c/openstack/nova/+/930963 | 02:35 |
opendevreview | melanie witt proposed openstack/nova master: db: Add image_type to block_device_mapping table https://review.opendev.org/c/openstack/nova/+/930964 | 02:35 |
opendevreview | melanie witt proposed openstack/nova master: objects: Add image_type to BlockDeviceMapping object https://review.opendev.org/c/openstack/nova/+/930965 | 02:35 |
opendevreview | melanie witt proposed openstack/nova master: virt: Add image_type to relevant DriverBlockDevice https://review.opendev.org/c/openstack/nova/+/930966 | 02:35 |
opendevreview | melanie witt proposed openstack/nova master: WIP libvirt: Add image multi-backend https://review.opendev.org/c/openstack/nova/+/930967 | 02:35 |
opendevreview | melanie witt proposed openstack/nova master: api: Add microversion 2.97 to add image_type to block_device_mapping_v2 https://review.opendev.org/c/openstack/nova/+/930968 | 02:35 |
opendevreview | Rajesh Tailor proposed openstack/nova master: Add support for showing finish_time https://review.opendev.org/c/openstack/nova/+/928933 | 06:57 |
opendevreview | Takashi Kajinami proposed openstack/placement master: Replace py38 job by py311 job https://review.opendev.org/c/openstack/placement/+/931033 | 15:45 |
opendevreview | Takashi Kajinami proposed openstack/placement master: DNM: testing ... https://review.opendev.org/c/openstack/placement/+/931034 | 15:46 |
bauzas | reminder : nova meeting in 12 mins here | 15:49 |
fwiesel | o/ | 16:00 |
bauzas | #startmeeting nova | 16:01 |
opendevmeet | Meeting started Tue Oct 1 16:01:07 2024 UTC and is due to finish in 60 minutes. The chair is bauzas. Information about MeetBot at http://wiki.debian.org/MeetBot. | 16:01 |
opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 16:01 |
opendevmeet | The meeting name has been set to 'nova' | 16:01 |
bauzas | hey everyone | 16:01 |
tkajinam | o/ | 16:01 |
elodilles | o/ | 16:01 |
bauzas | #link https://wiki.openstack.org/wiki/Meetings/Nova#Agenda_for_next_meeting | 16:01 |
dansmith | o/ | 16:02 |
bauzas | ok let's start | 16:02 |
bauzas | #topic Bugs (stuck/critical) | 16:03 |
bauzas | #info No Critical bug | 16:03 |
bauzas | #info Add yourself in the team bug roster if you want to help https://etherpad.opendev.org/p/nova-bug-triage-roster | 16:03 |
bauzas | anything else ? | 16:03 |
bauzas | ok looks not | 16:04 |
bauzas | moving on | 16:04 |
bauzas | #topic Gate status | 16:04 |
bauzas | #link https://bugs.launchpad.net/nova/+bugs?field.tag=gate-failure Nova gate bugs | 16:04 |
bauzas | #link https://etherpad.opendev.org/p/nova-ci-failures-minimal | 16:04 |
bauzas | #link https://zuul.openstack.org/builds?project=openstack%2Fnova&project=openstack%2Fplacement&pipeline=periodic-weekly Nova&Placement periodic jobs status | 16:04 |
bauzas | #info Please look at the gate failures and file a bug report with the gate-failure tag. | 16:04 |
bauzas | #info Please try to provide meaningful comment when you recheck | 16:04 |
Uggla | o/ | 16:05 |
bauzas | about the periodics, we have a failure on the c9s job | 16:05 |
bauzas | #link https://zuul.openstack.org/build/0e3b92cd874e4f29b4b252b6f4acb8e9 | 16:05 |
bauzas | 2024-09-28 08:43:49.610448 | controller | + lib/rpc_backend:install_rpc_backend:61 : sudo systemctl --now enable rabbitmq-server | 16:05 |
bauzas | 2024-09-28 08:43:49.646533 | controller | Failed to enable unit: Unit file rabbitmq-server.service does not exist. | 16:05 |
bauzas | looks like there is a regression | 16:06 |
bauzas | probably something people already know ? | 16:06 |
tkajinam | Is that seen in master ? | 16:07 |
bauzas | https://zuul.openstack.org/build/0e3b92cd874e4f29b4b252b6f4acb8e9/log/job-output.txt#4894 | 16:07 |
bauzas | no, stable/2024.2 | 16:07 |
bauzas | but, sec, checking master | 16:08 |
* gibi joins late | 16:08 | |
elodilles | CentOS9 - Error: Unable to find a match: rabbitmq-server | 16:08 |
elodilles | when installing 'dnf install -y rabbitmq-server' | 16:08 |
tkajinam | I've not seen it in puppet jobs so I guess it's not a general problem. | 16:08 |
bauzas | indeed, that's weird, master job run worked fine | 16:09 |
tkajinam | No match for argument: centos-release-openstack-2024.2 | 16:09 |
bauzas | https://zuul.openstack.org/builds?job_name=tempest-integrated-compute-centos-9-stream&project=openstack%2Fnova&project=openstack%2Fplacement&pipeline=periodic-weekly&skip=0 | 16:09 |
tkajinam | I guess it's not yet created | 16:09 |
tkajinam | I remember there were some discussions about it in #rdo | 16:09 |
tkajinam | I guess we can leave it now until devstack is updated or RDO publishes 2024.2 contents completely | 16:10 |
bauzas | okay, let's then defer this discussion to next week | 16:10 |
bauzas | we'll see whether this fails again | 16:10 |
bauzas | thanks tkajinam for the help | 16:10 |
tkajinam | +1 | 16:10 |
bauzas | moving on | 16:10 |
bauzas | nothing else about our gate stability ? | 16:10 |
bauzas | context : I wasn't around this week | 16:11 |
tkajinam | nothing I'm aware of | 16:11 |
sean-k-mooney | ya it sound like the rdo release has not happend yet | 16:11 |
sean-k-mooney | we might be able to pin to the 2024.1 content as a workaround | 16:12 |
bauzas | okay, then moving to the next topic | 16:12 |
bauzas | sean-k-mooney: this is a periodic job, we can wait until next week | 16:12 |
sean-k-mooney | ah then yes lets move on | 16:12 |
bauzas | #topic Release Planning | 16:12 |
bauzas | #link https://releases.openstack.org/dalmatian/schedule.html | 16:12 |
bauzas | #info Dalmatian GA planned tomorrow | 16:12 |
tkajinam | \o/ | 16:13 |
bauzas | that will probably help RDO ^ | 16:13 |
bauzas | #link https://releases.openstack.org/epoxy/schedule.html | 16:13 |
bauzas | as a reminder, we don't have yet nova deadlines for Epoxy, that will be discussed at the PTG | 16:13 |
bauzas | #topic Review priorities | 16:13 |
bauzas | #link https://etherpad.opendev.org/p/nova-2025.1-status | 16:14 |
bauzas | I need to do some homework and add the already approved blueprints in therre | 16:14 |
bauzas | at least gibi's series on igb is there | 16:15 |
bauzas | sounds like a quickwin | 16:15 |
bauzas | #topic PTG planning | 16:15 |
bauzas | #info as a reminder, we'll meet (virtually) at the PTG on Oct 21-25 2024 | 16:15 |
bauzas | #info Please register yourself to the virtual PTG | 16:16 |
bauzas | #link https://etherpad.opendev.org/p/nova-2025.1-ptg | 16:16 |
bauzas | please add your topics to the above etherpad | 16:16 |
bauzas | the more we have before the PTG, the better we are prepared and I can write some agenda :) | 16:16 |
bauzas | we'll have the Austin room for the week | 16:16 |
bauzas | (but I think I already said that last week) | 16:17 |
bauzas | any questions about the PTG ? | 16:17 |
gibi | bauzas: will we have Asia slot? | 16:17 |
bauzas | for the translations docs thing with ian and sungsoo, there is a TC topic about it | 16:18 |
bauzas | gibi: I don't think so, seongsoo and ian had their topic in the TC etherpad | 16:18 |
bauzas | I'll clarify that tonight during the TC meeting | 16:18 |
gibi | OK, so TC won't have an Asia slot either? | 16:19 |
bauzas | unless of course I see a few topics in the nova PTG etherpad where the owners are in Asian TZ | 16:19 |
bauzas | gibi: that's the question I'll ask tonight :D | 16:19 |
gibi | cool:) | 16:20 |
bauzas | I'm fine with addressing the translation issues as a cross-project discussion | 16:20 |
bauzas | but I can propose nova for some experimental work | 16:20 |
gibi | me too, I just need to know in advance if there is an extra schedule | 16:20 |
bauzas | yeah, I want to prepare my mornings :) | 16:21 |
bauzas | should be hopefully settled next week | 16:21 |
gibi | those sweet lazy mornings of the PTG week :) | 16:21 |
bauzas | for the moment, we stick with the usual slots that are 1300-1700UTC Tues to Fri | 16:21 |
gibi | ack | 16:22 |
bauzas | #topic Stable Branches | 16:22 |
bauzas | elodilles: heya | 16:22 |
elodilles | #info stable/202*.* gates seem to be OK | 16:22 |
elodilles | at least i'm not aware of any issue :) | 16:23 |
elodilles | and some patches merged, so probably OK | 16:23 |
elodilles | #info note, that stable/2023.1 (antelope) will transition to unmaintained/2023.1 in a month | 16:23 |
elodilles | we might want a release in 1 or 2 weeks ^^^ | 16:23 |
bauzas | time flies | 16:23 |
elodilles | *final* stable/2023.1 release | 16:23 |
elodilles | yepp | 16:23 |
elodilles | and that's all from me about stable for now | 16:24 |
bauzas | one open thought | 16:24 |
bauzas | but I don't want to start a flamewar now | 16:24 |
elodilles | :) | 16:24 |
bauzas | once we unmaintain 2023.1, we will only have one SLURP release | 16:25 |
bauzas | that's maintained | 16:25 |
* gibi prepares the torches | 16:25 | |
bauzas | giving an extra month before the flag would help people who *really* follow upstream stable support envelope to have more time to upgrade to C | 16:26 |
* bauzas awaits the tomatoes | 16:27 | |
dansmith | can we move this along? | 16:27 |
* gibi hands a torch to bauzas | 16:27 | |
bauzas | I don't know, that's a blind question | 16:27 |
bauzas | you know what ? that's not the right place to discuss that and I first need to check the releases support envelopes | 16:29 |
bauzas | but honestly, my thought was about the fact that I can imagine a SLURP release having a shortly longer support envelope than a non-SLURP one (and don't think about LTSes, that's not what I'm thinking) | 16:30 |
bauzas | aw, moving on | 16:31 |
elodilles | bauzas: well, now i'm a bit unsure as well. but i'll check the resolution... | 16:31 |
bauzas | #topic vmwareapi 3rd-party CI efforts Highlights | 16:31 |
elodilles | (unmaintained) | 16:31 |
bauzas | fwiesel: around ? | 16:31 |
fwiesel | Not much to update from my side. Still looking into the flakyness of the CI (occasional port failing to get bound) | 16:31 |
fwiesel | dansmith: Gentle reminder about the open comment: https://review.opendev.org/c/openstack/nova/+/910627?tab=comments | 16:32 |
fwiesel | Otherwise, that's from my side. | 16:32 |
bauzas | cool | 16:32 |
bauzas | and thanks for the update, g'luck with the flakyness | 16:33 |
bauzas | #topic Open discussion | 16:33 |
bauzas | (tkajinam): How can we restore https://review.opendev.org/c/openstack/nova/+/845660 ? | 16:33 |
bauzas | tkajinam: your time | 16:33 |
tkajinam | I noticed I left that stale for long and I'm willing to resume that work | 16:33 |
tkajinam | the current problem is that os-brick silently falls back to single path connection in case multipath is not running. os-brick introduce the capability to hard-fail in case mulitpath is not running and that is configurable in cinder and glance, but is not in nova | 16:34 |
dansmith | fwiesel: ack, but it's not blocking anything | 16:34 |
gibi | tkajinam: yeah make sense to pick that up | 16:35 |
tkajinam | my main question here is whether this can be spec-less bp or need spec | 16:35 |
bauzas | would there be an upgrade impact ? | 16:35 |
tkajinam | no. the option is disabled by default so the existing behavior is kept during upgrade. | 16:36 |
gibi | seems like fully backward compatible opt-in behavior | 16:36 |
fwiesel | dansmith: No, the comment not. I assumed you were volunteering for the second required review core review and hoped I addressed everything outsstanding. | 16:36 |
gibi | so for me it is OK to have it as specless | 16:36 |
bauzas | on a rolling upgrade case, you'd then have *some* computes that would fail instance creations while some others not ? | 16:36 |
tkajinam | yes > full backward compatible. | 16:36 |
gibi | bauzas: the compute agent will fail to start up if you opt-in to the new behavior but failed to install multipathd | 16:37 |
bauzas | then a doc would be sufficient | 16:37 |
bauzas | do you plan to change the behaviour in a later cycle ? | 16:38 |
tkajinam | no. I think we can keep the behavior optional. that's consistent with cinder and glance for now. | 16:38 |
bauzas | then I'm indeed cool with a specless BP, provided we document the option correctly (only turn that flag on if you installed multipathd) | 16:39 |
bauzas | any disagreements ? | 16:40 |
bauzas | so, | 16:41 |
bauzas | #agreed https://blueprints.launchpad.net/nova/+spec/enforce-multipath approved as specless | 16:41 |
bauzas | next item | 16:41 |
bauzas | (tkajinam): Python 3.8 support being removed | 16:42 |
tkajinam | sean-k-mooney, in case you have any remaining concerns then please let me know ^^^ | 16:42 |
tkajinam | this is again my topic :-P | 16:42 |
tkajinam | so as I wrote we are removing python 3.8 support from oslo. This is the timeline we agreed earlier and would move the whole projects to drop python 3.8 support | 16:42 |
tkajinam | AFAIK py38 job was removed from most of the nova/placement repos but there are a few remaining in placement I'm trying to replace. if you can review the change and also double-check the other repos, that would be nice | 16:43 |
bauzas | py3.8 upstream support is planned end of Nov, right? | 16:43 |
bauzas | upstream support end* | 16:43 |
tkajinam | https://devguide.python.org/versions/ it's reaching its EOL this month | 16:44 |
bauzas | oh this month | 16:44 |
tkajinam | so py3.8 is already EOL when Epoxy is released | 16:44 |
bauzas | https://governance.openstack.org/tc/reference/runtimes/2025.1.html | 16:45 |
bauzas | that's not in our runtimes, so I'm cool | 16:45 |
bauzas | tkajinam: if that's review support you need for your patches, bug me | 16:45 |
tkajinam | One thing I want to get agreement about is the min version enforced by python_requires in setup.cfg | 16:46 |
bauzas | we can also add your patches in the status etherpad | 16:46 |
tkajinam | which actually defines the min python version during installation | 16:46 |
bauzas | do we have a choice here given the Epoxy runtimes ? | 16:47 |
tkajinam | My own opinion is that we should bump min to 3.9, because we no longer test 3.8 and we don't aim to fix compatibility with it | 16:47 |
gibi | yeah, if we don't test it then it is broken | 16:47 |
gibi | so bump to 3.9 | 16:47 |
elodilles | we had issues in the past when we too early dropped a version and some thing went to error, | 16:48 |
elodilles | but i guess with py38 we are probably beyond that line :) | 16:48 |
bauzas | don't ask me to send you the pypi query that shows the number of "py2.7 supported" projects | 16:48 |
elodilles | maybe not merge it before tomorrow final 2024.2 Dalmatian release? :D | 16:48 |
bauzas | elodilles: this was due to some oslo libs | 16:48 |
tkajinam | py38 removal has been discussed for very long time and it was even removed from testing in 2024.2 . | 16:49 |
bauzas | and this was also happening very late in the development cycle | 16:49 |
elodilles | yepp | 16:49 |
bauzas | how many projects import nova.* ? | 16:49 |
tkajinam | I believe we gave all projects enough time to migrate job and now it's time to force any lagging projects to do their migration. | 16:50 |
elodilles | +1 | 16:50 |
tkajinam | bauzas, I'm aware of none, but I've not checked external projects really. | 16:50 |
bauzas | well, Blazar did that a decade ago :D | 16:50 |
bauzas | anyway | 16:50 |
tkajinam | As I said we may have new releases from oslo in M1 which drops py38 support. that would allow us to catch problems early | 16:50 |
elodilles | +1 | 16:51 |
bauzas | I'd say that oslo librairies should may be the latest to change their min versions | 16:51 |
elodilles | or drop it early in the cycle | 16:51 |
bauzas | but we're way in advance, so we can cut the cord now and see which projects fail the gap | 16:51 |
bauzas | elodilles: sure, and then it will become a TC discussion :D | 16:52 |
bauzas | like, project X CI fails, why ? | 16:52 |
bauzas | anyway | 16:52 |
elodilles | :) | 16:52 |
bauzas | tkajinam: from my sole angle of view which is the Nova project, I'd say you can safely bump our min_version in the descriptor, including os-vif and the clients | 16:53 |
tkajinam | ok | 16:53 |
tkajinam | I'll submit the bump and see how it goes. | 16:53 |
bauzas | anyything else then ? | 16:53 |
tkajinam | no :-) thanks for your time. | 16:53 |
bauzas | tkajinam: and don't hesitate to bug me then | 16:53 |
gibi | tkajinam: thanks for doing the cleanup | 16:54 |
bauzas | yup, thanks indeed | 16:54 |
bauzas | anything else to discuss ? | 16:55 |
dansmith | I just want to point out this patch of mine, which fixes a long-running transgression with us lying to glance about volume snapshots: https://review.opendev.org/c/openstack/nova/+/930754 | 16:55 |
dansmith | as far as I could tell while looking, the snap we create for volumes is not useful for actually booting from and was added for a completely unrelated reason ages ago | 16:55 |
dansmith | so i think we might want to consider not doing that anymore if there is no reason | 16:55 |
dansmith | if there is, then we're going to need to consider what we want to do there when we stop allowing nova to boot from unformatted (i.e. raw) images in the future | 16:56 |
dansmith | but I have a lot of history summarized there with links if anyone wants to have a look | 16:56 |
dansmith | that's blocking glance work because we fail in tempest tests to snapshot BFV instances since glance rejects nova's lies that we're uploading a qcow2 when we're clearly not | 16:56 |
bauzas | dansmith: fwiw, I trust you on that yet another image backend story | 16:56 |
dansmith | please trust but verify :) | 16:57 |
dansmith | anyway, no time to discuss in depth now, I need to run to something else but wanted to point it out | 16:57 |
gibi | dansmith: thanks for the heads up, I have to read your excellent commit message... | 16:57 |
bauzas | dansmith: I'll carefully verify your commit msg then | 16:58 |
dansmith | thanks | 16:58 |
gibi | bauzas: I feel we are done | 16:59 |
bauzas | yup, and we're on time | 16:59 |
gibi | perfect :) | 17:00 |
bauzas | I was doing some paperwork to add dansmith's patch into the etherpad | 17:00 |
bauzas | that's his fault | 17:00 |
bauzas | thanks all | 17:00 |
bauzas | #endmeeting | 17:00 |
opendevmeet | Meeting ended Tue Oct 1 17:00:22 2024 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 17:00 |
opendevmeet | Minutes: https://meetings.opendev.org/meetings/nova/2024/nova.2024-10-01-16.01.html | 17:00 |
opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/nova/2024/nova.2024-10-01-16.01.txt | 17:00 |
opendevmeet | Log: https://meetings.opendev.org/meetings/nova/2024/nova.2024-10-01-16.01.log.html | 17:00 |
gibi | bauzas: thanks | 17:00 |
elodilles | thanks o/ | 17:00 |
gibi | o/ | 17:00 |
tkajinam | thank you | 17:00 |
opendevreview | Takashi Kajinami proposed openstack/nova master: libvirt: Add new option to enforce multipath volume connections https://review.opendev.org/c/openstack/nova/+/845660 | 17:17 |
opendevreview | Takashi Kajinami proposed openstack/nova master: Remove Python 3.8 support https://review.opendev.org/c/openstack/nova/+/931047 | 17:27 |
opendevreview | Takashi Kajinami proposed openstack/nova master: Remove Python 3.8 support https://review.opendev.org/c/openstack/nova/+/931047 | 17:27 |
gmann | tkajinam: I think we should remove the python_requires itself | 17:28 |
sean-k-mooney | currently tkajinam is not modifying it | 17:29 |
sean-k-mooney | or the verions in setup.cfg at all | 17:30 |
sean-k-mooney | there patch is just reverting to using hashlib instead of oslo for md5 | 17:30 |
sean-k-mooney | tkajinam: we shoudl proably update https://github.com/openstack/nova/blob/master/setup.cfg#L13-L23 in the same patch | 17:31 |
sean-k-mooney | wether we remvoe python_requires = >=3.8 or change it to python_requires = >=3.9 i have less opipion on | 17:31 |
sean-k-mooney | but we shoudl drop Programming Language :: Python :: 3.8 | 17:31 |
gmann | yeah and add py3.12 also | 17:31 |
sean-k-mooney | yep | 17:32 |
tkajinam | I though I modified setup.cfg but I somehow reverted that change... | 17:32 |
opendevreview | Takashi Kajinami proposed openstack/nova master: Remove Python 3.8 support https://review.opendev.org/c/openstack/nova/+/931047 | 17:33 |
sean-k-mooney | that explains why v1 and v2 are the same exctp the commit message :) | 17:33 |
sean-k-mooney | gmann: you prefer not to bump python_requires in general yes | 17:33 |
sean-k-mooney | to allow it to install even if its not nessiarly compatible | 17:34 |
gmann | sean-k-mooney: yeah, it create problem more than benefit | 17:34 |
sean-k-mooney | without a downstream patch python once we revert to hashlibg directly it will fail on vanilla py38 | 17:34 |
sean-k-mooney | usedforsecurity does not exist in the upstream python 3.8 hashlib | 17:34 |
gmann | python versions listed in classifier should tell what all python versions are tested and supported and rest all no guarantee | 17:35 |
tkajinam | I'd say classifier is just useless because it does not enforce anything and have been unmantained for very long | 17:35 |
gmann | if it work as long as it is good | 17:35 |
gmann | this is just a info and doc we do not need to enforce things | 17:35 |
sean-k-mooney | gmann: right my point is nova wont work on py38 with this change (unless the distro backported the hashlib change to 3.8) | 17:36 |
tkajinam | what you are saying is equivalent to drop all min version from requirements, IMHO | 17:36 |
tkajinam | I don't know why we should maintain these although we won't maintain compat version for core python. | 17:37 |
sean-k-mooney | so tkajinam we may not be able to do this change this cycle | 17:37 |
sean-k-mooney | we still need ubuntu 22.04 for grenade | 17:37 |
sean-k-mooney | and i belive it uses 3.8 | 17:37 |
sean-k-mooney | this is the release whre we are moving all the ci to 24.04 but 22.04 is kept for smoth upgrades | 17:37 |
sean-k-mooney | 22.04 has alternitive pythons liek 3.9 | 17:38 |
sean-k-mooney | so we could use that instead but its not the default | 17:38 |
tkajinam | 22.04 uses 3.10 afaik | 17:38 |
sean-k-mooney | oh you might be right | 17:38 |
sean-k-mooney | i may have mixed that up | 17:38 |
sean-k-mooney | tkajinam: ah yes your correct | 17:39 |
sean-k-mooney | 20.04 used 3.8 22.04 is alredy 3.10 | 17:40 |
tkajinam | a few projects like cinder, heat, horizon, octavia already removed py38 support but they have survived | 17:40 |
tkajinam | yeah | 17:40 |
sean-k-mooney | so that means the oldest python we have in ci (for master at least) is already 3.9 on centos | 17:40 |
tkajinam | yes. 3.8 has been untested since 2024.2 | 17:41 |
tkajinam | unless the repo contains the job left (eg. placement) | 17:41 |
sean-k-mooney | ack | 17:41 |
sean-k-mooney | oh we missed updatign placement did we not merge the patch to update it for 2024.2? | 17:41 |
sean-k-mooney | https://review.opendev.org/c/openstack/placement/+/881366 ... | 17:42 |
gmann | sean-k-mooney: tkajinam I sent on ML to remove this flag. IMO, it will not hurt anything but avoid our effort to update and coordinate it everytime | 17:42 |
sean-k-mooney | i tought we merged that | 17:42 |
gmann | and coordination is always missing among all openstack project and this flag create issue | 17:43 |
sean-k-mooney | gmann: im ok to remove it but as i said we knwo it wont work this time and ya the cordination is tough | 17:43 |
sean-k-mooney | hopefully less of an issue now that python has a yearly releace cadnace and predicable EOL date | 17:44 |
gmann | yeah, everytime olso bump the min in this flag it fail many projects and it take time for fixing all their CI even fix is very simple | 17:44 |
sean-k-mooney | so im wondering if we should merge https://review.opendev.org/c/openstack/placement/+/881366 before https://review.opendev.org/c/openstack/placement/+/931033 or just go strait to tkajinam's patch | 17:46 |
sean-k-mooney | tkajinam: is there a reaosn you marked that WIP | 17:46 |
tkajinam | we do actually remove compatibilities in some repos. if we remove the min then it appears as wired errors instead of explicit failure during installation | 17:46 |
tkajinam | sean-k-mooney, I tought https://review.opendev.org/c/openstack/placement/+/925648 is the primary way but I'm fine with it... note that 925648 revealed that functional-py39 uses python 3.8 actually which needs to be fixed... | 17:47 |
tkajinam | I mean I'm ok to merge job update and leave min bump for now | 17:47 |
gmann | ++ | 17:48 |
sean-k-mooney | we have several patches for it in placement we just need to choose one to proceed with | 17:48 |
gmann | or merge all in single one, remove py3.8 job + add py301, py311 jobs and leave the min version bump | 17:49 |
sean-k-mooney | placement-perfload by the way is having a wheel build fialure for a missing header | 17:49 |
sean-k-mooney | i think that is unrelated and and existing fialure tha twe shoudl fix in a differnt patch | 17:49 |
sean-k-mooney | it has quite a few failures https://zuul.opendev.org/t/openstack/builds?job_name=placement-perfload&project=openstack%2Fplacement | 17:50 |
sean-k-mooney | im going to finish for today soon | 17:51 |
tkajinam | py311 functional job already exists and pass so I prefer to use it now and then replace it by py312 if needed | 17:51 |
gmann | ah yeah, ++ for py3.12 | 17:51 |
sean-k-mooney | im happy to go with gmann's suggestion fo a single path to do everythin and just test the upper and lower python version i.e. 3.9 and 3.12 for tox jobs | 17:51 |
tkajinam | ok | 17:51 |
sean-k-mooney | by the way 3.12 support is added by https://review.opendev.org/c/openstack/placement/+/919578/3 | 18:00 |
sean-k-mooney | the pre-commit series was all intended to be in 2024.2... | 18:01 |
sean-k-mooney | it would likely be best to merge https://review.opendev.org/c/openstack/placement/+/919578/3 first and then rebase tkajinam change on top | 18:02 |
sean-k-mooney | gmann: if we wanted to avoid the merge conflict merging up to https://review.opendev.org/c/openstack/placement/+/919580/3 before tkajinam's change woudl make sense | 18:02 |
gmann | sean-k-mooney: sure, will check after tc meeting | 18:03 |
sean-k-mooney | no worries | 18:03 |
opendevreview | Takashi Kajinami proposed openstack/placement master: Replace py38 job by py311 job https://review.opendev.org/c/openstack/placement/+/931033 | 18:10 |
opendevreview | Takashi Kajinami proposed openstack/placement master: Move upper functional job to py312 https://review.opendev.org/c/openstack/placement/+/931052 | 18:10 |
opendevreview | Merged openstack/placement master: tox: Simplify functional testenv definitions https://review.opendev.org/c/openstack/placement/+/919578 | 20:39 |
opendevreview | Merged openstack/placement master: Integrate pre-commit https://review.opendev.org/c/openstack/placement/+/919579 | 21:28 |
opendevreview | Merged openstack/placement master: pre-commit: Add autopep8 https://review.opendev.org/c/openstack/placement/+/923490 | 21:30 |
opendevreview | Merged openstack/placement master: pre-commit: Add sphinx-lint https://review.opendev.org/c/openstack/placement/+/919580 | 21:30 |
opendevreview | Merged openstack/placement master: Replace py38 job by py311 job https://review.opendev.org/c/openstack/placement/+/931033 | 21:59 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!