| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2024-10-01 | |||
| 16:24:49 | elodilles | :) | |
| 16:25:17 | bauzas | once we unmaintain 2023.1, we will only have one SLURP release | |
| 16:25:21 | bauzas | that's maintained | |
| 16:26:31 | 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:27:23 | dansmith | can we move this along? | |
| 16:27:40 | bauzas | I don't know, that's a blind question | |
| 16:29:24 | bauzas | you know what ? that's not the right place to discuss that and I first need to check the releases support envelopes | |
| 16:30:31 | 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:31:01 | bauzas | aw, moving on | |
| 16:31:09 | elodilles | bauzas: well, now i'm a bit unsure as well. but i'll check the resolution... | |
| 16:31:18 | elodilles | (unmaintained) | |
| 16:31:18 | bauzas | #topic vmwareapi 3rd-party CI efforts Highlights | |
| 16:31:27 | bauzas | fwiesel: around ? | |
| 16:31:53 | fwiesel | Not much to update from my side. Still looking into the flakyness of the CI (occasional port failing to get bound) | |
| 16:32:16 | fwiesel | dansmith: Gentle reminder about the open comment: https://review.opendev.org/c/openstack/nova/+/910627?tab=comments | |
| 16:32:21 | fwiesel | Otherwise, that's from my side. | |
| 16:32:29 | bauzas | cool | |
| 16:33:00 | bauzas | and thanks for the update, g'luck with the flakyness | |
| 16:33:07 | bauzas | #topic Open discussion | |
| 16:33:13 | bauzas | (tkajinam): How can we restore https://review.opendev.org/c/openstack/nova/+/845660 ? | |
| 16:33:39 | bauzas | tkajinam: your time | |
| 16:33:56 | tkajinam | I noticed I left that stale for long and I'm willing to resume that work | |
| 16:34:42 | 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:49 | dansmith | fwiesel: ack, but it's not blocking anything | |
| 16:35:11 | gibi | tkajinam: yeah make sense to pick that up | |
| 16:35:28 | tkajinam | my main question here is whether this can be spec-less bp or need spec | |
| 16:35:53 | bauzas | would there be an upgrade impact ? | |
| 16:36:18 | tkajinam | no. the option is disabled by default so the existing behavior is kept during upgrade. | |
| 16:36:44 | gibi | seems like fully backward compatible opt-in behavior | |
| 16:36:46 | 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:53 | gibi | so for me it is OK to have it as specless | |
| 16:36:59 | tkajinam | yes > full backward compatible. | |
| 16:36:59 | bauzas | on a rolling upgrade case, you'd then have *some* computes that would fail instance creations while some others not ? | |
| 16:37:35 | 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:52 | bauzas | then a doc would be sufficient | |
| 16:38:14 | bauzas | do you plan to change the behaviour in a later cycle ? | |
| 16:38:36 | tkajinam | no. I think we can keep the behavior optional. that's consistent with cinder and glance for now. | |
| 16:39:18 | 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:40:19 | bauzas | any disagreements ? | |
| 16:41:19 | bauzas | so, | |
| 16:41:44 | bauzas | #agreed https://blueprints.launchpad.net/nova/+spec/enforce-multipath approved as specless | |
| 16:41:59 | bauzas | next item | |
| 16:42:02 | bauzas | (tkajinam): Python 3.8 support being removed | |
| 16:42:03 | tkajinam | sean-k-mooney, in case you have any remaining concerns then please let me know ^^^ | |
| 16:42:20 | tkajinam | this is again my topic :-P | |
| 16:42:51 | 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:43:32 | 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:40 | bauzas | py3.8 upstream support is planned end of Nov, right? | |
| 16:43:57 | bauzas | upstream support end* | |
| 16:44:20 | tkajinam | https://devguide.python.org/versions/ it's reaching its EOL this month | |
| 16:44:29 | bauzas | oh this month | |
| 16:44:43 | tkajinam | so py3.8 is already EOL when Epoxy is released | |
| 16:45:00 | bauzas | https://governance.openstack.org/tc/reference/runtimes/2025.1.html | |
| 16:45:15 | bauzas | that's not in our runtimes, so I'm cool | |
| 16:45:55 | bauzas | tkajinam: if that's review support you need for your patches, bug me | |
| 16:46:20 | tkajinam | One thing I want to get agreement about is the min version enforced by python_requires in setup.cfg | |
| 16:46:32 | bauzas | we can also add your patches in the status etherpad | |
| 16:46:37 | tkajinam | which actually defines the min python version during installation | |
| 16:47:06 | bauzas | do we have a choice here given the Epoxy runtimes ? | |
| 16:47:10 | 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:35 | gibi | yeah, if we don't test it then it is broken | |
| 16:47:41 | gibi | so bump to 3.9 | |
| 16:48:16 | elodilles | we had issues in the past when we too early dropped a version and some thing went to error, | |
| 16:48:34 | elodilles | but i guess with py38 we are probably beyond that line :) | |
| 16:48:37 | bauzas | don't ask me to send you the pypi query that shows the number of "py2.7 supported" projects | |
| 16:48:53 | bauzas | elodilles: this was due to some oslo libs | |
| 16:48:53 | elodilles | maybe not merge it before tomorrow final 2024.2 Dalmatian release? :D | |
| 16:49:06 | tkajinam | py38 removal has been discussed for very long time and it was even removed from testing in 2024.2 . | |
| 16:49:17 | bauzas | and this was also happening very late in the development cycle | |
| 16:49:34 | elodilles | yepp | |
| 16:49:41 | bauzas | how many projects import nova.* ? | |
| 16:50:07 | 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:17 | elodilles | +1 | |
| 16:50:25 | tkajinam | bauzas, I'm aware of none, but I've not checked external projects really. | |
| 16:50:42 | bauzas | well, Blazar did that a decade ago :D | |
| 16:50:49 | bauzas | anyway | |
| 16:50:51 | 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:51:11 | elodilles | +1 | |
| 16:51:17 | bauzas | I'd say that oslo librairies should may be the latest to change their min versions | |
| 16:51:42 | elodilles | or drop it early in the cycle | |
| 16:51:45 | bauzas | but we're way in advance, so we can cut the cord now and see which projects fail the gap | |
| 16:52:07 | bauzas | elodilles: sure, and then it will become a TC discussion :D | |
| 16:52:21 | bauzas | like, project X CI fails, why ? | |
| 16:52:27 | bauzas | anyway | |
| 16:52:39 | elodilles | :) | |
| 16:53:09 | 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:19 | tkajinam | ok | |
| 16:53:42 | bauzas | anyything else then ? | |
| 16:53:42 | tkajinam | I'll submit the bump and see how it goes. | |
| 16:53:50 | tkajinam | no :-) thanks for your time. | |
| 16:53:55 | bauzas | tkajinam: and don't hesitate to bug me then | |
| 16:54:14 | gibi | tkajinam: thanks for doing the cleanup | |
| 16:54:51 | bauzas | yup, thanks indeed | |
| 16:55:04 | bauzas | anything else to discuss ? | |
| 16:55:05 | 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:35 | 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:46 | dansmith | so i think we might want to consider not doing that anymore if there is no reason | |
| 16:56:14 | 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:27 | dansmith | but I have a lot of history summarized there with links if anyone wants to have a look | |
| 16:56:51 | 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 | |