October 2024 - openstack-discuss - lists.openstack.org

Stop bumping major versions when dropping EOL Python versions
by Stephen Finucane 04 Oct '24

04 Oct '24

o/ Python 3.8 is going EOL (upstream, anyway) next month. We've been working to drop support for this from various SDK deliverables, and I'm guessing (though don't yet know for sure) that this will happen across other project deliverables before long (if it hasn't started happening already). One side-effect of this change is that we will be expected to raise the major version of the affected dependencies on our next release. This is annoying for projects like openstacksdk that use the release-with-intermediary release model because it forces us to have a major version release earlier than we would like to. To give a concrete example, we have a RemovedInSDK50Warning deprecation warning that we are using to indicate (as you might guess) things that we plan to remove in openstacksdk 5.0.0. We need to wait 6 months/1 OpenStack release before removing anything flagged with this warning, so this has been mainly applied to legacy deprecation warnings to put a concrete timeline on their removal. However, because we just dropped Python 3.8 support, it is currently expected that our next release be 5.0.0. We last deprecated something new ~2 months ago, so this means we either cannot release a new version of openstacksdk for 3-4 months (to allow 6 months to pass) or we need to either rename RemovedInSDK50Warning to RemovedInSDK60Warning or add a new RemovedInSDK60Warning and move the offending deprecations to this. None of these are nice options and to be honest, I don't think the major version bump really provides all that much value to end-users: they already have a much better signal for the removal of a Python version in the 'python_requires' marker in setup.py/setup.cfg/pyproject.toml/(other build system file). By using this, we ensure that a user simply can't install a version of a package that doesn't support their chosen Python version. I'd be in favour of getting rid of this particular constraint, and instead focusing on API changes when deciding whether to bump the major version. Is this a reasonable suggestion, and if so what would we need to do to tweak our policy to allow it? Cheers, Stephen

4 3

[all][qa][infra] Restore unit tests for intermediate python versions
by Takashi Kajinami 04 Oct '24

04 Oct '24

Hello, As you may know, current master runs unit tests with only Python 3.9 and Python 3.12. My understanding about this set up is that we test the minimum boundary and the maximum boundary and assume the change may work with all the versions between these two. However in some of my recent work I had to introduce the switch in the middle of these two versions. For example https://review.opendev.org/c/openstack/neutron/+/931271 introduces the logic to distinguish Python < 3.10 from Python >= 3.10 , and we don't specifically test that boundary. I'm afraid that this may potentially cause uncaught problems. So my question here is ... Can we test all supported python versions, not only min/max, at least in check jobs ? This would helps us catch any regressions caused by such implementation. I know there could be tradeoffs between test coverage and infra resources, but IMO this is the test coverage we should fill. Thank you, -- Takashi Kajinami irc: tkajinam github: https://github.com/kajinamit launchpad: https://launchpad.net/~kajinamit

3 5

[all] Remove 'python_requires' flag from setup.cfg
by Ghanshyam Mann 04 Oct '24

04 Oct '24

Hi All, As you know, we have a flag 'python_requires' in setup.cfg which is pinned to the minimum python version supported[1]. Every time we upgrade our Python testing, we usually bump the minimum python version in setup.cfg and that prevents the project from being installed on lower Python versions. We do have list of tested and supported Python versions in setup.cfg classifier, which is good and enough information to tell what all Python versions are tested[2]. Flag 'python_requires' creates an issue (which has happened many times in the past) when a dependency like oslo lib bumps the version, and it makes all projects testing old Python versions fail. I know we should remove the old Python versions tested from projects first, but somehow, we all are busy, and a coordinated effort is always missed. IMO, we should remove this flag as it creates more issues than benefits. opinion? It will also help to continue users to install things on old python versions if it is working for them. [1] https://github.com/openstack/nova/blob/8c1a47c9cf6e1001fbefd6ff3b76314e39c8… [2] https://github.com/openstack/nova/blob/8c1a47c9cf6e1001fbefd6ff3b76314e39c8… -gmann

9 21

[kolla] [cinder-backup] max operations and workers problems
by garcetto 04 Oct '24

04 Oct '24

good morning, using all-in-one ubuntt 22 lts kolla openstack 2024.1 version. cinder.conf " [DEFAULT] ... backup_max_operations = 1 backup_workers = 1 ... " despite this, the cinder-backup container is doing more backups of more istance volumes...why? thank you.

2 3

migrating away from neutron-linuxbridge-agent
by Ionuț Bîru 04 Oct '24

04 Oct '24

Hi, Im running openstack 2023.1 and I intent to move away from linuxbridge agent due to being unmaintained and marked as experimental. Is there a documentation on how to migrate away to neutron-openvswitch-agent ? Is the change straightforward, simple as starting neutron-openvswitch-agent container, stopping/starting the servers from that hypervisor? Do you guys suggest to migrate to ovn instead of openvswitch? --- Ionuț Bîru - Hosterion

2 1

Openstack large deployment with network OVN
by Satish Patel 04 Oct '24

04 Oct '24

Folks, I am planning to deploy the latest openstack with OVN on around 300 compute nodes. based on googling I found there are some best practices for setting to scale OVN with many compute nodes. I would like to get some expert opinion on what is the best option I should go for to deploy OVN. What things should I keep in mind?

1 0

[OSSA-2024-004] OpenStack Ironic: Ironic fails to verify checksums of supplied image_source URLs when configured to convert images to raw for streaming (CVE-2024-47211)
by Jay Faulkner 03 Oct '24

03 Oct '24

==================================================================================================================================== OSSA-2024-004: Ironic fails to verify checksums of supplied image_source URLs when configured to convert images to raw for streaming ==================================================================================================================================== :Date: October 03, 2024 :CVE: CVE-2024-47211 Affects ~~~~~~~ - Ironic: <21.4.4, >=22.0.0 <23.0.3, >=23.1.0 <24.1.3, >=25.0.0, <26.1.0 Description ~~~~~~~~~~~ Julia Kreger of Red Hat noticed a vulnerability in image validation for Ironic, in which images may not have their checksum validated before conversion, potentially permitting man-in-the-middle attacks modifying image data. Patches ~~~~~~~ -https://review.opendev.org/c/openstack/ironic/+/931300 (2023.1/antelope(ironic)) -https://review.opendev.org/c/openstack/ironic/+/931299 (2023.2/bobcat(ironic)) -https://review.opendev.org/c/openstack/ironic/+/931295 (2024.1/caracal(ironic)) -https://review.opendev.org/c/openstack/ironic/+/931294 (2024.2/dalmatian(ironic)) -https://review.opendev.org/c/openstack/ironic/+/931293 (2025.1/epoxy (ironic)) -https://review.opendev.org/c/openstack/ironic/+/931298 (Bugfix/24.0 (ironic)) -https://review.opendev.org/c/openstack/ironic/+/931297 (Bugfix/25.0 (ironic)) -https://review.opendev.org/c/openstack/ironic/+/931296 (Bugfix/26.0 (ironic)) -https://review.opendev.org/c/openstack/ironic/+/931305 (Unmaintained/victoria(ironic)) -https://review.opendev.org/c/openstack/ironic/+/931304 (Unmaintained/wallaby(ironic)) -https://review.opendev.org/c/openstack/ironic/+/931303 (Unmaintained/xena(ironic)) -https://review.opendev.org/c/openstack/ironic/+/931302 (Unmaintained/yoga(ironic)) -https://review.opendev.org/c/openstack/ironic/+/931301 (Unmaintained/zed(ironic)) Credits ~~~~~~~ - Julia Kreger from Red Hat (CVE-2024-47211) References ~~~~~~~~~~ -https://launchpad.net/bugs/2076289 -http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-47211 Notes ~~~~~ - No other Ironic-adjacent projects, including Ironic-Python-Agent, require patching to resolve this vulnerability. - As usual, we will provide updated releases off maintained branches, but will not create new releases off bugfix or unmaintained branches. -- Jay Faulkner OpenStack Vulnerability Management Team https://security.openstack.org/vmt.html

1 0

Live Now! OpenStack 2024.2 'Dalmatian' on OpenInfra Live
by Allison Price 03 Oct '24

03 Oct '24

Hi everyone, Right now, OpenInfra Live is hosting several OpenStack PTLs as well as the chair of the Technical Committee chair from the 2024.2 Dalmatian release cycle to talk about the features from OpenStack’s 30th release. Join us on LinkedIn or YouTube and it’s live, so ask any questions you have for our guests! More information is available at openinfra.dev/live. YouTube: https://www.youtube.com/watch?v=6igJNIJ9yFE LinkedIn: https://www.linkedin.com/events/introducingopenstackdalmatian20724476314826… See you there! Allison

1 0

openstack neutron issue binding VIF
by Stepan Vakheta 03 Oct '24

03 Oct '24

Hello team, I am currently experiencing an issue with the Neutron component, specifically with port binding. I am attempting to use Neutron as an external provider for oVirt networks. I have successfully created the networks and imported them, and oVirt is able to see all the information about the network from Neutron. However, when I create a vNIC in oVirt's VM, it appears in Neutron but it shows that the binding_vif_type is "binding_failed" and the VM does not start. It seems that oVirt is not able to create the port from the imported Neutron Network. Additionally, neither the Neutron controller node nor the Neutron compute node shows any errors according to this case. I have attached the network configuration files of the controller node and the config files of the neutron component. Please let me know if there is anything else I can provide you regarding configs, logs, etc. I appreciate any help you can provide. Regards, Stepan Vakheta

1 0

OpenStack 2024.2 Dalmatian is officially released!
by Elõd Illés 02 Oct '24

02 Oct '24

Hello OpenStack community, The official OpenStack 2024.2 Dalmatian release announcement has been sent out: https://lists.openstack.org/archives/list/openstack-announce@lists.openstac… Thanks to all who were a part of the 2024.2 Dalmatian development cycle! This marks the official opening of the openstack/releases repository for 2025.1 Epoxy releases, and freezes are now lifted. stable/2024.2 is now a fully normal stable branch, and the normal stable policy applies from now on. Thanks, Előd Illés on behalf of the Release Management team

3 2