Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2024-10-01
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 bauzas on a rolling upgrade case, you'd then have *some* computes that would fail instance creations while some others not ?
16:36:59 tkajinam yes > full backward compatible.
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 elodilles maybe not merge it before tomorrow final 2024.2 Dalmatian release? :D
16:48:53 bauzas elodilles: this was due to some oslo libs
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 tkajinam I'll submit the bump and see how it goes.
16:53:42 bauzas anyything else then ?
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
16:56:56 bauzas dansmith: fwiw, I trust you on that yet another image backend story
16:57:06 dansmith please trust but verify :)
16:57:17 dansmith anyway, no time to discuss in depth now, I need to run to something else but wanted to point it out
16:57:35 gibi dansmith: thanks for the heads up, I have to read your excellent commit message...
16:58:35 bauzas dansmith: I'll carefully verify your commit msg then
16:58:38 dansmith thanks
16:59:45 gibi bauzas: I feel we are done
16:59:54 bauzas yup, and we're on time
17:00:02 gibi perfect :)
17:00:11 bauzas I was doing some paperwork to add dansmith's patch into the etherpad
17:00:14 bauzas that's his fault
17:00:19 bauzas thanks all
17:00:22 bauzas #endmeeting
17:00:22 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:22 opendevmeet Minutes: https://meetings.opendev.org/meetings/nova/2024/nova.2024-10-01-16.01.html
17:00:22 opendevmeet Minutes (text): https://meetings.opendev.org/meetings/nova/2024/nova.2024-10-01-16.01.txt
17:00:22 opendevmeet Log: https://meetings.opendev.org/meetings/nova/2024/nova.2024-10-01-16.01.log.html
17:00:29 gibi bauzas: thanks
17:00:31 elodilles thanks o/
17:00:32 gibi o/

Earlier   Later