March 2025 - openstack-discuss - lists.openstack.org

[all][tc][ptl][qa] Migrating upstream CI/CD jobs to Ubuntu Noble (24.04)
by Ghanshyam Mann 15 Mar '25

15 Mar '25

Hello Everyone, As per the 2025.2 cycle testing runtime, we need to run upstream CI/CD jobs on Ubuntu Noble (24.04) [1]. For better tracking and speeding up this work, it is the community-wide goal for this cycle[2]. This is the etherpad which has the migration plan and will be used for the tracking: - https://etherpad.opendev.org/p/migrate-to-noble I have prepared the change(WIP) for base jobs migration on Noble (openstack tox jobs, devstack, and tempest) which will migrate most of the projects jobs. Tempest change[3] include dependency on openstack tox, devstack base jobs changes so testing project gate using the the tempest change will test the complete set. Refer to the etherpad for the complete migration plan/steps. * Deadline: Nov 29th 2024 (R18) is the deadline to test/fix the projects jobs and to merge the base jobs running on Noble (openstck tox, devstack, and tempest). [1] https://governance.openstack.org/tc/reference/runtimes/2025.1.html [2] https://governance.openstack.org/tc/goals/selected/migrate-ci-jobs-to-ubunt… [3] https://review.opendev.org/c/openstack/tempest/+/932156 -gmann

2 9

[release] Release countdown for week R-2
by Thierry Carrez 14 Mar '25

14 Mar '25

Development Focus ----------------- At this point we should have release candidates (RC1 or recent intermediary release) for all the 2025.1 Epoxy deliverables. Teams should be working on any release-critical bugs that would require another RC or intermediary release before the final release. Actions ------- Early in the week, the release team will be proposing stable/2025.1 branch creation for all deliverables that have not branched yet, using the latest available 2025.1 Epoxy release as the branch point. If your team is ready to go for creating that branch, please let us know by leaving a +1 on these patches. If you would like to wait for another release before branching, you can -1 the patch and update it later in the week with the new release you would like to use. By the end of the week the release team will merge those patches though, unless an exception is granted. Once stable/2025.1 branches are created, if a release-critical bug is detected, you will need to fix the issue in the master branch first, then backport the fix to the stable/2025.1 branch before releasing out of the stable/2025.1 branch. After all of the cycle-with-rc projects have branched we will branch devstack, grenade, and the requirements repos. This will effectively open them up for 2025.2 Flamingo development, though the focus should still be on finishing up 2025.1 Epoxy until the final release. Opening up the new development cycle is also a good opportunity to teams to revise their zuul jobs and used nodesets and clean up all unnecessary ones. For projects with translations, watch for any translation patches coming through and merge them quickly. A new release should be produced so that translations are included in the final 2025.1 Epoxy release. Finally, now is a good time to finalize release notes. In particular, consider adding any relevant "prelude" content. Release notes are targeted for the downstream consumers of your project, so it would be great to include any useful information for those that are going to pick up and use or deploy the 2025.1 Epoxy version of your project. Upcoming Deadlines & Dates -------------------------- Final RC deadline: March 28th, 2025 (R-1 week) Final 2025.1 Epoxy release: April 2nd, 2025 Project Teams Gathering (virtual): April 7th-11th, 2025 -- Thierry Carrez (ttx)

1 0

[neutron] Drivers meeting canceled Friday, March 14th
by Brian Haley 14 Mar '25

14 Mar '25

Hello Neutrinos: I'm going to cancel tomorrow's drivers meeting as there is currently nothing listed in the agenda and we should be focusing on getting last-minute changes for RC1 merged. Just a reminder there are still open specs that need review, list is at [0]. Have a nice weekend! -Brian [0] https://review.opendev.org/q/status:open+project:openstack/neutron-specs

1 0

weighing compute nodes by real memory available when filtering
by Jiatong Shen 14 Mar '25

14 Mar '25

Hello Experts, I would like to ask if there is an available implementation to achieve filtering or weighing compute nodes by the real memory usage. From my observation, nova filters the compute-nodes by computing the summation of all instances' flavor ram and reserved ram. But since reserved ram is only an empirical value, sometimes compute nodes could potentially use more ram. Making things even worse is the ram allocation ratio could be more than 1. So I would like to know if there is an available implementation such that when the real memory available (from procfs) is low, the compute-node could be given a smaller weight or simply filtered out. Thank you. -- Best Regards, Jiatong Shen

2 2

Building a test cluster with openstack ansible
by Sarah Thompson 13 Mar '25

13 Mar '25

Hi all, I've been experimenting with openstack through a devstack instance, but I need to start looking at a more realistic deployment architecture. I have a 5 node Proxmox cluster available, so I've created 6 VMs, one to serve as a deployment host for Ansible etc, one as a controller node, and four compute nodes. These are all currently set up with Ubuntu 22 LTS and configured with 128GB of disk, 20GB of RAM and 12 cores. I've verified that Ansible works, LXC works correctly, etc. I'm getting a failure when I'm running openstack-ansible openstack.osa.setup_infrastructure Specifically I get errors like: PLAY [Gather repo facts] ******************************************************************************************************* TASK [Gathering Facts] ********************************************************************************************************* [WARNING]: Unhandled error in Python interpreter discovery for host openstack-controller-repo-container-e44299d5: unexpected output from Python interpreter discovery fatal: [openstack-controller-repo-container-e44299d5]: FAILED! => ansible_facts: {} changed: false failed_modules: ansible.legacy.setup: ansible_facts: discovered_interpreter_python: /usr/bin/python3 failed: true module_stderr: |- lxc-attach: openstack-controller-repo-container-e44299d5: attach.c: get_attach_context: 405 Connection refused - Failed to get init pid lxc-attach: openstack-controller-repo-container-e44299d5: attach.c: lxc_attach: 1469 Connection refused - Failed to get attach context module_stdout: '' msg: |- MODULE FAILURE See stdout/stderr for the exact error rc: 1 warnings: - Platform unknown on host openstack-controller-repo-container-e44299d5 is using the discovered Python interpreter at /usr/bin/python3, but future installation of another Python interpreter could change the meaning of that path. See https://docs.ansible.com/ansible-core/2.17/reference_appendices/interpreter… for more information. msg: |- The following modules failed to execute: ansible.legacy.setup Inspecting the openstack-controller node manually with lxc-ls, there are no containers present. (I have manually created one and tested it successfully, so it's definitely not something weird with not being able to create/run containers). Thank you in advance for your insights. :-) Sarah PS: When I have this working, next step is to put this on bare metal in a colo, assuming I can get it working.

3 8

[infra][tc][trove] Freeing the reddwarf project on PyPI
by Jeremy Stanley 13 Mar '25

13 Mar '25

I've received a request from a representative of The Computational Democracy Project (pol.is) who have a project named red-dwarf and would like to release software to PyPI under that name. For those of you who have been around long enough to remember, the Trove project was called Red Dwarf during incubation, but was renamed roughly 12 years ago owing to trademark concerns. The https://pypi.org/p/reddwarf project was reserved but no release files were uploaded to it. I don't expect our community has any reason to continue holding onto that name as I don't see that we would ever actually use it, but I'm posting this for the sake of transparency. Does anyone object to letting go of the reddwarf project on PyPI so that it can be reused by another open source community effort? -- Jeremy Stanley

2 3

[kolla] [nova] API flags ignored in Wallaby
by Albert Braden 13 Mar '25

13 Mar '25

After rebuilding our Train clusters on Wallaby we are seeing some API issues. It appears that flags that work in Train are still documented in Wallaby, but are ignored. Do we have something setup wrong, or are we encountering bugs? The first thing is the “locked” list: Train: openstack server list --all-projects --locked --os-compute-api-version 2.73 <empty list because nothing is locked> openstack server list --all-projects --unlocked --os-compute-api-version 2.73 <list of every VM in the cluster> Wallaby (locked flag is ignored): openstack server list --all-projects --locked --os-compute-api-version 2.73 <list of every VM in the cluster> openstack server list --all-projects --unlocked --os-compute-api-version 2.73 <list of every VM in the cluster> The second problem is the hypervisor list. We can’t get “long” output in Wallaby: Train: openstack hypervisor list --long | ID | Hypervisor Hostname | Hypervisor Type | Host IP | State | vCPUs Used | vCPUs | Memory MB Used | Memory MB | Wallaby (long flag is ignored): openstack hypervisor list --long | ID | Hypervisor Hostname | Hypervisor Type | Host IP | State |

6 14

[keystone] Keystone tries to get project by selecting user_id
by İzzettin Erdem 12 Mar '25

12 Mar '25

Hi, I faced to an odd issue; while migrating some servers, keystone threw an exception and migration aborted - Could not find project: 6008439893ca4d80ab933cf3b0b5fef0 When I checked, a project with this ID does not exist, but the key point is it's not a project ID, it's an ID of a user. I googled this problem but couldn't find more information except this [1] <https://bugs.launchpad.net/keystone/+bug/2062247>. PS: _ mysql logs were fine, didn't see weird queries _ keystone works fine _ openstack version kolla-ansible/train Do you have any ideas? Thanks, İzzettin

2 1

[all] Important discussion about the OpenInfra Foundation's future
by Jeremy Stanley 12 Mar '25

12 Mar '25

The OpenInfra Foundation's board of directors is considering a significant organizational change, and your feedback is critical to assist them in their decision. Please read this announcement on the foundation mailing list: https://lists.openinfra.org/archives/list/foundation@lists.openinfra.org/th… You can follow up publicly on that list with any questions or input you have for the board and staff, or in one of the public feedback conference calls mentioned there, as well as privately to Jonathan Bryce or myself if you prefer to give feedback in confidence. Thanks as always for your interest in the future of our community! -- Jeremy Stanley -- Jeremy Stanley

4 11

[ovn][neutron] ha_chassis make priority permanent
by Satish Patel 12 Mar '25

12 Mar '25

Folks, I am dealing with a very strange DHCP issue because of the priority of ha_chassis. I have the following ha_chassis group and I want os-chn-gen-comp-001 and os-chn-gen-comp-002 to always service DHCP for sriov interface. I have used following command to give them high priority $ ovn-nbctl --no-leader-only set ha_chassis 97077f76-46ae-4e15-9502-24fdb4ad0214 priority=32767 $ ovn-nbctl --no-leader-only set ha_chassis 97077f76-46ae-4e15-9502-24fdb4ad0214 priority=32767 But suddenly today something happened and all priority got reset causing small outage and cause all sriov VM started looking IP address. Solution was I have again set high priority again by hand to fix it.. How do I make priority permanently so it will never reset again. $ (ovn-nb-db)[root@os-chn-ctrl01 /]# ovn-nbctl --no-leader-only list HA_Chassis 784ec6e9-9af8-45c6-86e0-75ae7ccf9278 7fa04343-4471-4707-b5e9-23bd7f29ca6e 97077f76-46ae-4e15-9502-24fdb4ad0214 c75de7ab-b346-4aa5-886b-31b0fd12401e dd6ce2d4-9746-4429-862a-e78750bb4909 _uuid : 784ec6e9-9af8-45c6-86e0-75ae7ccf9278 chassis_name : os-chn-ctrl03 external_ids : {} priority : 32764 _uuid : 7fa04343-4471-4707-b5e9-23bd7f29ca6e chassis_name : os-chn-gen-comp-001 external_ids : {} priority : 32766 _uuid : 97077f76-46ae-4e15-9502-24fdb4ad0214 chassis_name : os-chn-gen-comp-002 external_ids : {} priority : 32767 _uuid : c75de7ab-b346-4aa5-886b-31b0fd12401e chassis_name : os-chn-ctrl01 external_ids : {} priority : 32765 _uuid : dd6ce2d4-9746-4429-862a-e78750bb4909 chassis_name : os-chn-ctrl02 external_ids : {} priority : 32763

1 1