- openstack-discuss - lists.openstack.org

[oslo.messaging] Heartbeat in pthread
by Arnaud Morin 05 Oct '24

05 Oct '24

Hello, I completely miss the deprecation of heartbeat_in_pthread in oslo.messaging [1]. We heavily rely on this parameter downstream and our opinion is that it should be set to True by default. We use it for both wsgi services and agents (nova-compute, neutron agents, etc.). I understand that eventlet will be dropped in the future, but should we set heartbeat_in_pthread to True by default until then? Regards, Arnaud. [1] https://review.opendev.org/c/openstack/oslo.messaging/+/925778

5 12

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

05 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 05 Oct '24

05 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 05 Oct '24

05 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 04 Oct '24

04 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 03 Oct '24

03 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

Kubernetes cluster on top of OpenStack with kops
by Jaime Ibar 02 Oct '24

02 Oct '24

Hi all, anyone is using kops for deploying a kubernetes cluster on top of Openstack? Thanks Jaime -- Jaime

2 1

[all][tc][ptl][ptg] TC Discussions at the PTG - Sign Up and Suggest Topics
by Goutham Pacha Ravi 02 Oct '24

02 Oct '24

Hello Stackers, I'd like to highlight the Technical Committee's PTG planning etherpad [1], where we're organizing our discussions for the upcoming PTG. Over the next week, I aim to finalize time slots and prioritize discussion topics. Since TC discussions are cross-project, we'll do our best to avoid scheduling conflicts with project team meetings. To help with this, I encourage all interested parties to sign up or vote on the topics listed in the etherpad. Feel free to add any additional topics you'd like to discuss as well. Thank you! Best regards, Goutham Pacha Ravi (gouthamr) OpenStack TC Chair [1] https://etherpad.opendev.org/p/oct2024-ptg-os-tc

1 0

[all] [security] [ptls] Please review core security teams
by Jay Faulkner 02 Oct '24

02 Oct '24

Hi all, I'm writing on behalf of the Vulnerability Management Team (VMT). We often use the ${project}-coresec teams to determine who is best to help triage initial issues. These groups do not appear to be universally up to date. If you are in charge of a repo managed by the VMT ( https://security.openstack.org/repos-overseen.html#repositories-overseen ) please ensure the associated launchpad ${project}-coresec group has active, trusted members of your community -- or otherwise reach out to the VMT in #openstack-security to arrange other contacts if needed. For example, https://launchpad.net/~ironic-coresec/+members contains four longtime Ironic cores and former PTLs. (I'll note: I likely need to audit the equivalent group for Ironic-adjacent repos, and will do that after hitting send). This is extremely important! If we can't get an issue triaged and dealt with in time, it gets opened to the public. If there's any questions, feel free to respond here or reach out in #openstack-security on OFTC. Thanks, Jay Faulkner

1 0

[ironic] Postgres CI job broken
by Julia Kreger 02 Oct '24

02 Oct '24

Greetings folks, We had a little bit of a discussion on this subject in #openstack-ironic IRC earlier today[0], but the tl;dr is it appears the postgres integration CI job Ironic has had as a "canary" of support is now failing. This time it appears to be rooted in keystone[1]. Like our prior times of raising awareness, we're sending this email to the mailing list. Given the overall deprecation of postgres support many years ago, and the decline in postgres CI jobs in OpenStack, we believe it is time for us to remove this CI job. That being said, if someone wants such support to be fixed and rejuvenated, please consider this email your call to action. Thanks, -Julia [0]: https://meetings.opendev.org/irclogs/%23openstack-ironic/%23openstack-ironi… [1]: https://7d12977942ed9fbb75e4-56d2480851ef91de1634aa83a3abd804.ssl.cf1.rackc…

2 1

[Kolla-Ansible] [Ironic] Node Deploy Failed with MissingAuthPlugin
by Ali Hussain 02 Oct '24

02 Oct '24

Hi Kolla and Ironic folks, While playing with stable/kolla release to fix the No VIF found error. Looks like adding Readers role to ironic user fixed it. But run into Missing Auth plugin [2] issue while image is being deployed to ironic node. Openstack endpoint list command [1] shows the correct IP of the controller. My question is: 1. Kolla-Ansible needs explicite Ironic keystone configuration in Ironic.conf? Following this link <https://docs.openstack.org/kolla-ansible/yoga/reference/bare-metal/ironic-g…> which does not seems to need any keystone configurations. This issue is observed when 1. --boot-interface redfish-virtual-media 2. --deploy-interface ramdisk 3. --driver-info deploy_iso= 4. -instance-info kernel & ramdisk 2. My passwords.yaml has 1. ironic_database_password: 2. ironic_inspector_database_password: 3. ironic_inspector_keystone_password: 4. ironic_keystone_password: Any suggestions please. Thank you. Ali [1] openstack endpoint list | grep ironic | <ID> | <Region> | ironic-inspector | baremetal-introspection | True | internal | http://<IP>:5050 | | <ID> | <Region> | ironic | baremetal | True | public | http://<IP>:6385 | | <ID> | <Region> | ironic-inspector | baremetal-introspection | True | public | http://<IP>:5050 | | <ID> | <Region> | ironic | baremetal | True | internal | http://<IP>:6385 [2] *Error: *Detected change in error condition on node Node1. Deploy step deploy.deploy failed with MissingAuthPlugin: An auth plugin is required to determine endpoint URL.. An unhandled exception was encountered while aborting. More information may be found in the log file.

2 6

Automating Network VLAN Reconfiguration Post-Bare Metal Provisioning with OpenStack Ironic
by Hajasolo 02 Oct '24

02 Oct '24

Hello OpenStack Community, I am currently working with OpenStack Ironic for provisioning bare metal servers and facing a specific challenge related to network security and automation. I would appreciate any insights or experiences you could share! We use Ironic to provision bare metal servers, which involves utilizing a management VLAN during the PXE boot and initial OS installation process. Post-provisioning, the server’s management interface remains accessible, posing a security risk as it can potentially access the management network. I need to ensure that once a server is provisioned and handed over to a user, it cannot access the management VLAN until it is deprovisioned. 1. How can we automate the process of removing the management VLAN from the server’s network interface post-provisioning to prevent unauthorized access to the management network? 2. Upon server deprovisioning, how can we automatically re-enable the management VLAN to allow for server re-provisioning? 3. Are there any built-in OpenStack tools or common practices within the Ironic or larger OpenStack community to handle such scenarios? Our goal is to maintain a high level of automation and self-service capability in our OpenStack environment while ensuring rigorous network security standards. Solutions that integrate seamlessly with OpenStack’s existing architecture would be ideal. Thank you for your time and help! Best regards, Haja, Joel

2 1

[largescale-sig] Next meeting: September 18, 9utc
by Thierry Carrez 01 Oct '24

01 Oct '24

Hi everyone, The Large Scale SIG will be meeting this Wednesday in #openstack-operators on OFTC IRC, at 9UTC. You can doublecheck how that UTC time translates locally at: https://www.timeanddate.com/worldclock/fixedtime.html?iso=20240918T09 Feel free to add topics to the agenda: https://etherpad.opendev.org/p/large-scale-sig-meeting Regards, -- Thierry Carrez

3 3

[Glance] Weekly Meeting Cancelled (OCT 3)
by Pranali Deore 01 Oct '24

01 Oct '24

Hi All, As discussed during last week's meeting[1], the meeting for 3rd OCT has been cancelled. See you all next week!! [1]: https://meetings.opendev.org/irclogs/%23openstack-meeting/%23openstack-meet… Thanks, Pranali

1 0

[tc][all] OpenStack Technical Committee Weekly Summary and Meeting Agenda (2024.2/R-0)
by Goutham Pacha Ravi 01 Oct '24

01 Oct '24

Hello Stackers, After 26 weeks of effort across the community, we're finally at the release week for the 2024.2 release [1], codenamed 'Dalmatian'. I'll cue "Who Let the Dogs Out" for 2024-10-02 and toast the successful delivery of the 30th release of OpenStack with all of you. Congratulations, and thank you for your contributions in making this yet another on-time release. Please tune into the OpenInfra Live episode at 1400 UTC on 2024-10-03 [2], where you'll hear from a few Project Team Leads about the new and exciting things included in this release. Over the past week, the OpenStack TC assisted the release team in tagging a few deliverables, and on its behalf, I'd like to commend the release team for pulling out all the stops to ensure yet another on-time release. It takes a village, as Jeremy Stanley (fungi) noted on IRC — the happy, buzzing Stackerton village. We also merged some governance changes in the meantime. Notably, we adopted a community goal to move all existing Ubuntu testing to the latest LTS [3], and we retired several charms repositories after their consolidation into the Sunbeam-charms project [4]. I am pleased to welcome Dmitriy Rabotyagov (noonedeadpunk) as the Vice Chair for the TC, and I thank the outgoing Vice Chair, Dr. Jens Harbott (frickler), for his contributions during the 2024.2 release cycle. Next week, as we step into the 2025.1 ("Epoxy") release cycle formally [5], we'll switch into PTG and planning mode and chart out the remaining release priorities early. === Weekly Meeting === The Technical Committee's weekly meeting was held over IRC on 2024-09-24 [6]. We began the meeting by welcoming new members and thanking outgoing ones. We appointed a TC Chair (me) and a Vice Chair (noonedeadpunk) for the 2025.1 release cycle. We then worked through several 2024.2 release issues. We were presented with a peculiar, but familiar problem involving release deliverables that couldn't proceed without help from project maintainers who were unavailable during the release crunch. The release team prepares release candidate patches a week before the RC1 deadline and encourages project maintainers to vote on them. They also submit changes to the respective repositories to verify the state of the CI system to prevent releasing broken code. However, when a project team doesn't respond, there's a risk to the coordinated release. We brainstormed strategies to deal with the current conundrum. Thanks to noonedeadpunk and the attentiveness of project maintainers in Zun and Barbican, we were able to fix broken CI jobs and tag release candidates for some projects. However, we couldn't determine the state of "kuryr-kubernetes" and "kuryr-tempest-plugin." These projects, flagged earlier as unmaintained, are expected to be retired soon, so there are no releases from these projects in the 2024.2 release stream. If you depend on these projects, please let us know. We are looking for maintainers who can commit to reviving the CI and furthering these projects. The next OpenStack TC meeting is on 2024-10-01 at 1800 UTC. This meeting will be held simultaneously via video and IRC. Please find the agenda and other meeting details in our meeting wiki [7]. I hope you'll be able to join us. Remember, you can always edit the agenda and propose new topics! === Governance Proposals === ==== Merged ==== - Retire all single charm repositories | https://review.opendev.org/c/openstack/governance/+/903490 - Select community-wide goal: migrate CI/CD jobs to Ubuntu Noble | https://review.opendev.org/c/openstack/governance/+/929703 - Add 2025.1 TC chair and vice-chair | https://review.opendev.org/c/openstack/governance/+/930376 - Add chair nomination folder for 2025.1 | https://review.opendev.org/c/openstack/governance/+/929970 - Add GouthamR nomination for 2025.1 TC chair | https://review.opendev.org/c/openstack/governance/+/929971 ==== Open for Review ==== - Appoint Tim Burke as PTL for Swift | https://review.opendev.org/c/openstack/governance/+/928881 - Add Axel Vanzaghi as PTL for Mistral | https://review.opendev.org/c/openstack/governance/+/927962 - Mark kuryr-kubernetes and kuryr-tempest-plugin as Inactive | https://review.opendev.org/c/openstack/governance/+/929698 - Retire kuryr-kubernetes and kuryr-tempest-plugin | https://review.opendev.org/c/openstack/governance/+/922507 === Upcoming Events === - 2024-10-02: OpenInfra Live - Introducing OpenStack Dalmatian 2024.2 [2] - 2024-10-08: OpenInfra Monthly Board Meeting: https://board.openinfra.dev/ - 2024-10-15: OpenInfra Days NA, Indianapolis: https://ittraining.iu.edu/explore-topics/titles/oid-iu/ - 2024-10-21: OpenInfra Project Teams Gathering https://openinfra.dev/ptg/ === How to Contact the TC === You can reach the TC in several ways: 1. Email: send an email with the tag [tc] on this mailing list. 2. Ping us using the 'tc-members' keyword on the #openstack-tc IRC channel. 3. Join us at our weekly meeting: The Technical Committee meets every week on Tuesdays at 1800 UTC [7]. Thank you very much for reading! On behalf of the OpenStack TC, Goutham Pacha Ravi (gouthamr) OpenStack TC Chair [1] 2024.2 "Dalmatian" Release Schedule: https://releases.openstack.org/dalmatian/schedule.html [2] Introducing OpenStack Dalmatian 2024.2: https://openinfra.dev/live/ [3] Goal: migrate CI/CD jobs to Ubuntu Noble: https://review.opendev.org/c/openstack/governance/+/929703 [4] Retire all single charm repositories: https://review.opendev.org/c/openstack/governance/+/903490 [5] 2025.1 "Epoxy" Release Schedule: https://releases.openstack.org/epoxy/schedule.html [6] TC Meeting IRC Log, 2024-09-24: https://meetings.opendev.org/meetings/tc/2024/tc.2024-09-24-17.59.log.html [7] TC Meeting Agenda, 2024-10-01: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee

1 0

Nova placement
by engineer2024 01 Oct '24

01 Oct '24

Is there a way to get back the correct used resources allocation data, in case of loosing the db ? Does placement update the allocation details after restarting the compute nodes to get the latest resources usage for that node ? Thanks elinux

2 2

[neutron] Proposing Ihar Hrachyshka as neutron stable core reviewer
by Brian Haley 01 Oct '24

01 Oct '24

Hello Neutrinos, I would like to nominate Ihar Hrachyshka for Neutron stable core reviewer (again). Ihar previously led the neutron stable core reviewer team a number of years ago, and I think he'd be a great re-addition to the team. Please vote with a +1/-1. Thanks, -Brian, Neutron PTL

6 6

[kolla] Proposing Matt Crees for Kayobe core
by William Szumski 30 Sep '24

30 Sep '24

Greetings Kayobians, I would like to propose Matt Crees as a core reviewer for Kayobe. With Mark Goddard stepping back from Kayobe maintenance duties, we have a slot to fill in the core team. In my opinion, Matt Crees is the strongest candidate for the position, having provided numerous reviews and contributions over the past few cycles. Please register any objections to this decision before the kolla meeting on 25th of September, otherwise I will proceed with making formal arrangements to get him added. Thanks Will Szumski will(a)stackhpc.com

6 6

[neutron] Bug Deputy report Sep 23 - 29th
by Oleg Bondarev 30 Sep '24

30 Sep '24

Hello Team, Nothing critical this week, 3 High bugs need assignees, 1 RFE to review by Drivers team. Full report for the week of Sep 23 is below: High: - https://bugs.launchpad.net/neutron/+bug/2081868 - LoggingDBApiTestCase.test_get_logs_bound_sg fails - Confirmed - unassigned - https://bugs.launchpad.net/neutron/+bug/2081870 - TestProcessMonitor.test_respawn_handler failed - Confirmed - unassigned - https://bugs.launchpad.net/neutron/+bug/2081871 - TestHAL3Agent.test_ha_router failed - Confirmed - unassigned - https://bugs.launchpad.net/neutron/+bug/2081945 - [postgresql] AttributeError: 'NoneType' object has no attribute 'id' - In progress: https://review.opendev.org/c/openstack/neutron/+/930408 - assigned to Rodolfo Alonso Medium: - https://bugs.launchpad.net/neutron/+bug/2082066 - Logging not supported in unmaintained branches - In progress: https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/930546 - assigned to Rodolfo Alonso - https://bugs.launchpad.net/neutron/+bug/2082070 - [unmaintained] Errors in the "neutron-tempest-plugin-scenario-ovn" job - In progress: https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/930548 - assigned to Rodolfo Alonso - https://bugs.launchpad.net/neutron/+bug/2082344 - [unmaintained] ``NetworkWritableMtuTest`` test don't work in ML2/OVN - In progress: https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/930594 - assigned to Rodolfo Alonso - https://bugs.launchpad.net/neutron/+bug/2082880 - [ovn-octavia-provider] config registration hit DuplicateOptError - In progress: https://review.opendev.org/c/openstack/ovn-octavia-provider/+/930670 - assigned to Rico Lin Low: - https://bugs.launchpad.net/neutron/+bug/2082883 - neutron-tempest-plugin: KeyError caused by missing 'previous' ref Edit - Confirmed - unassigned RFEs: - https://bugs.launchpad.net/ironic/+bug/2081847 - [RFE] Implement a new DHCP backend for Ironic and Neutron Edit - New - unassigned Thanks, Oleg

1 0

[kolla] [kolla-ansible]
by dariusz.bursztynowski＠pw.edu.pl 30 Sep '24

30 Sep '24

Hello, Are there plans for kolla-ansible to support Ubuntu 24.04 / ARM64 (to have LTS support for Raspberry Pi 5)? Best regards, Dariusz Bursztynowski

4 3