- openstack-discuss - lists.openstack.org

[Devstack] Trying to setup development environment on VM
by Ishan Shanware (ishanwar) 16 Mar '25

16 Mar '25

Hello Everyone, I am currently trying to setup in all-in-one development environment for OpenStack on a Debian VM. The VM has 16 GB RAM and 4 CPUs. However, I face an error while trying to run FORCE=yes ./stack.sh. I get an error that keystone does not start. This causes the entire process to fail. Requesting assistance in solving this issue. I am following the this guide: https://docs.openstack.org/devstack/latest/guides/single-machine.html PFA the error log and error message on the terminal. [Call Trace] ./stack.sh:1126:start_keystone /opt/stack/devstack/lib/keystone:549:die [ERROR] /opt/stack/devstack/lib/keystone:549 keystone did not start Error on exit World dumping... see /opt/stack/logs/worlddump-2024-11-18-150808.txt for details ovs-vsctl: unix:/var/run/openvswitch/db.sock: database connection failed (No such file or directory) ovs-vsctl: unix:/var/run/openvswitch/db.sock: database connection failed (No such file or directory) Thanks in advance, Ishan

3 5

[neutron] Bug deputy report for week 11 of 2025
by Miguel Lavalle 16 Mar '25

16 Mar '25

I was the Neutron bug deputy last week. Following is a brief summary of the reported bugs: High bugs -------------- https://bugs.launchpad.net/neutron/+bug/2101839 [fullstack] Random errors during the execution of ``wait_until_true``. Assignee Rodolfo Alonso. Proposed fix: https://review.opendev.org/c/openstack/neutron/+/943942 https://bugs.launchpad.net/neutron/+bug/2101857 ``neutron-tempest-plugin-ovn-ubuntu-jammy`` job unstable. No owner. Jobs neutron-tempest-plugin-*-ubuntu-jammy`` were made no voting: https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/944119 Medium bugs ------------------ https://bugs.launchpad.net/neutron/+bug/2101840 ovs jobs randomly failing with guest vms not getting ip from dhcp. Assignee Lajos Katona https://bugs.launchpad.net/neutron/+bug/2101998 [OVN][Placement] Deleting a configured resource provider does not remove the Placement entry. Assignee Rodolfo Alonso. Proposed fix: https://review.opendev.org/c/openstack/neutron/+/944053 https://bugs.launchpad.net/neutron/+bug/2102083 ``SingletonDecorator`` class to allow destroying instances. Assignee Rodolfo Alonso. Proposed fix: https://review.opendev.org/c/openstack/neutron/+/944099 https://bugs.launchpad.net/neutron/+bug/2101871 Use of revision_number for router update on 2023.2 Bobcat cause error 500. Waiting for reproducer info from submitter Low bugs ------------- https://bugs.launchpad.net/neutron/+bug/2102095 [OVN][Placement] Change the message level when a Placement exception happens. Assignee Rodolfo Alonso. Proposed fix: https://review.opendev.org/c/openstack/neutron/+/944101 RFEs ----- https://bugs.launchpad.net/neutron/+bug/2102090 [RFE][OVN][Placement] With Neutron API WSGI module, the initial chassis configuration is not executed. https://bugs.launchpad.net/neutron/+bug/2102165 [RFE] Forbid usage of certain IP addresses in subnet pools https://bugs.launchpad.net/neutron/+bug/2102184 [RFE] Project-Specific QoS Controls for Granular Resource Management Incomplete --------------- https://bugs.launchpad.net/neutron/+bug/2102044 Nova-API problem - cannot list instances anymore

1 0

[ci][all] Migrating doc job back to ubuntu jammy
by Takashi Kajinami 16 Mar '25

16 Mar '25

Hi, I noticed that doc job in taskflow repo was broken recently. Example: https://review.opendev.org/c/openstack/taskflow/+/944495?tab=change-view-ta… Digging into the failure, it seems the failure is caused by api doc build, trying to parse a module importing asyncore, because asyncore is no longer available in Python 3.12. IIUC Doc job was recently migrated from Ubuntu Jammy to Ubuntu Noble, which means that the default python version was bumped to 3.12. We are aware of the deprecation/removal of asyncore and already deprecated the implementation in taskflow. However deprecation was merged during 2024.2 cycle so we can't remove it until 2025.2 cycle to follow SLURP policy. There might be a way to drop the asyncore-related implementations from docs to unblock the doc job, I'm not sure if that is the right approach given the fact the implementation is deprecated but is still valid in older python versions. Thus, I wonder if we can keep running doc job in Jammy for 2025.1, which still supports Ubuntu Jammy, and then migrate the job again during 2025.2 . An alternative approach is to remove the asyncore implementation during this cycle, breaking SLURP policy, but I'm not sure if this can be the preferred option. Thank you, Takashi -- Takashi Kajinami irc: tkajinam github: https://github.com/kajinamit launchpad: https://launchpad.net/~kajinamit

2 4

Deploiment in 2025
by Albert Shih 16 Mar '25

16 Mar '25

Hi everyone Long time ago I deploy a openstack mostly manually, then I integrated in our deployment tool (puppet). Now I need to re-install everything. I'm searching the «best» method to do that. My deployment would be on bare-metal, I don't need/want a deployment of CEPH (I already have my ceph cluster). Just need the cinder to use the ceph. The main focus is the easy way to upgrade. I don't have a lot of hardware so I can afford to have a «test» cluster for upgrading. I'm thinking of kolla, what do you think ? I see they are now openstack-helm project, which If I understand correctly use a k8s to manage the deployment of openstack. Is that correct ? With those tools is they are any limitation about the result ? Or can I got the most the main features of openstack ? What would you recommend ? Regards. -- Albert SHIH 🦫 🐸 Observatoire de Paris France Heure locale/Local time: mer. 05 mars 2025 17:13:54 CET

8 16

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

14 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 13 Mar '25

13 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 13 Mar '25

13 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 12 Mar '25

12 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