February 2024 - openstack-discuss

[openstack][kolla-ansible]about group node config overwrite
by Nguyễn Hữu Khôi 30 Oct '25

30 Oct '25

Hello Koller. I want to ask if we can overwrite config for a group of nodes. For example, compute01 >> compute10 will have the same nova configuration compute11 >> compute20 will have the same nova configuration. It will be very nice if we support this way. Thank you. Regards Nguyen Huu Khoi

4 7

Fwd: DPDK+OVS with OpenStack
by Mark Wittling 23 Apr '25

23 Apr '25

Looking for someone who knows OpenStack with OpenVSwitch, and in addition to that, DPDK with OpenStack and OVS.I am using OpenStack Queens, with OpenVSwitch. The architecture I am using is documented here: https://docs.openstack.org/neutron/queens/admin/deploy-ovs-provider.htmlThe OVS I am using on the Compute Node, is compiled with DPDK, and I have enabled the datapath to netdev (DPDK) on br-prv (provider network bridge), and br-tun (tunneling bridge). But these two bridges, br-tun and br-prv, are patched into another OpenStack bridge, called br-int. I wasn’t actually sure about whether to tinker with this bridge, and wondered what datapath it was using.Then, I realized there is a parameter in the openvswitch_agent.ini file, which I will list here: # OVS datapath to use. 'system' is the default value and corresponds to the # kernel datapath. To enable the userspace datapath set this value to 'netdev'. # (string value) # Possible values: # system - <No description provided> # netdev - <No description provided> #datapath_type = system datapath_type = netdev So in tinkering with this, what I realized, is that when you set this datapath_type to system or netdev, it will adjust the br-int bridge to that datapath type.So here is my question. How can I launch a non-DPDK VM, if all of the bridges are using the netdev datapath type?Here is another question. What if one of the flavors don’t have the largepages property set on them? I assumed OpenStack would revert to a system datapath and not use DPDK for those VM interfaces. Well, I found out in testing, that is not the case. If you set all your bridges up for netdev, and you don’t set the property on the Flavor of the VM (largepages), the VM will launch, but it simply won’t work.Is there no way, on a specific Compute Host, to support both DPDK (netdev datapaths) and non-DPDK (system datapaths)?Either on a VM interface level (VM has one interface that is netdev DPDK and another that is system datapath non-DPDK)?Or on a VM by VM basis (VM 1 has 1 or more netdev datapath interfaces and VM 2 has 1 or more system datapath interfaces)?Am I right here? Once you set up a Compute Host for DPDK, it’s DPDK or nothing on that Compute Host? (edited)

3 2

How to config DPDK compute in OVN
by dangerzone ar 22 Apr '25

22 Apr '25

Hi....as far I understand ovs does support dpdk compute to be deployed. I'm referring to the guideline ' *https://docs.openstack.org/networking-ovn/queens/admin/dpdk.html <https://docs.openstack.org/networking-ovn/queens/admin/dpdk.html>* ' ... It's too brief.. May I know how to config dpdk compute in OVN networking openstack? Hope someone could help what is the config to be done.... Currently compute is run without dpdk over openstack train ovn based. Please need some info on how I can proceed. Thank you

2 1

[octavia] Purging ERROR'ed amphora and load balancers stuck in transitional states
by Paul Browne 11 Apr '25

11 Apr '25

Hello Octavia users, For a while I've been trying to find a systematic way to remove Octavia LBs+Amphora that have become stuck in ERROR or transitional PENDING_* states ; $ openstack loadbalancer amphora list -f value | grep ERROR a2323f14-3aaa-418a-8249-111aaa9c21fe 1fa7bd54-f60c-420c-94f3-d4c02f03d4fe ERROR MASTER 10.8.0.242 192.168.3.247 e5b236ba-e7ee-4ed7-9f58-57ce7a408489 1fa7bd54-f60c-420c-94f3-d4c02f03d4fe ERROR BACKUP 10.8.0.190 192.168.3.247 6b556f28-93c9-49dd-b6ee-4379288e7957 d5e402fe-2c4b-49af-a700-532cb408cee5 ERROR MASTER 10.8.0.39 192.168.3.126 c669db5d-8686-4d5c-9e95-e02030b34301 d5e402fe-2c4b-49af-a700-532cb408cee5 ERROR BACKUP 10.8.0.174 192.168.3.126 $ openstack loadbalancer list -f value | grep -vi active 1fa7bd54-f60c-420c-94f3-d4c02f03d4fe k8s-clusterapi-cluster-default-ci-6386871107-kube-upgrade-kubeapi 3a06571936a0424bb40bc5c672c4ccb1 192.168.3.247 PENDING_UPDATE amphora d5e402fe-2c4b-49af-a700-532cb408cee5 k8s-clusterapi-cluster-default-ci-6386871107-latest-kubeapi 3a06571936a0424bb40bc5c672c4ccb1 192.168.3.126 PENDING_DELETE amphora These resources are marked immutable and so cannot be failed over or deleted; $ openstack loadbalancer amphora failover a2323f14-3aaa-418a-8249-111aaa9c21fe Load Balancer 1fa7bd54-f60c-420c-94f3-d4c02f03d4fe is immutable and cannot be updated. (HTTP 409) (Request-ID: req-6e66c4e8-c3d3-4549-a03c-367017c8c8b3) $ openstack loadbalancer failover 1fa7bd54-f60c-420c-94f3-d4c02f03d4fe Invalid state PENDING_UPDATE of loadbalancer resource 1fa7bd54-f60c-420c-94f3-d4c02f03d4fe (HTTP 409) (Request-ID: req-84b44212-e7a8-4101-a16f-18c774c0577e) The backing Nova instances for these Amphora do seem to exist and be in good working order. Is there any API way to purge these out of Octavia's service state, or would (very careful) DB hackery be required here? Many thanks, Paul Browne ******************* Paul Browne Research Computing Platforms University Information Services Roger Needham Building JJ Thompson Avenue University of Cambridge Cambridge United Kingdom E-Mail: pfb29(a)cam.ac.uk<mailto:pfb29@cam.ac.uk> Tel: 0044-1223-746548 *******************

4 6

[glance][ops] proposal to remove the glance-scrubber
by Brian Rosmaita 20 Jan '25

20 Jan '25

Hello Glance users, The Glance project team wants to determine whether anyone is using the glance-scrubber utility [0]. If not, we are thinking of deprecating it this cycle to be removed in the appropriate future cycle. If you have not previously heard of the glance-scrubber, that's most likely because it's only useful for particular deployment configurations of which yours is not one. See the doc [0] for details if you are curious. Our suspicion is that the glance-scrubber may have outlived its usefulness for modern OpenStack configurations. (The last time I remember it being discussed at a PTG was during the snowstorm in Dublin, which I believe was the Rocky development cycle). On the other hand, the team also has some ideas for improving the scrubber, but there's no point doing that if it's not actually being used in the first place. So if removal of the glance-scrubber would negatively affect you, please respond to this email so we can get some data points. Thanks! [0] https://docs.openstack.org/glance/latest/cli/glancescrubber.html

2 2

[cinder][kubernetes] pvc stuck in reserved state
by Eugen Block 10 Jan '25

10 Jan '25

Hi, we have a couple of k8s clusters in our openstack environment (Victoria) and are facing some problems when pods get moved to different worker nodes. The PVCs get stuck in "reserved" state, and they only get attached after resetting the volumes to "available" state. First I thought it was due to the missing multiattach volume type which seems to work fine in our customer's cluster. I also found the "duplicate connector" error messages in the nova-compute.log: > Unable to update attachment.(Invalid volume: duplicate connectors > detected on volume But after adding the multiattach volume type and retyping the affected volumes, the PVCs still get stuck in "reserved" state while I don't see any error messages on the hypervisors anymore. So it seems that something has changed/improved, but now I don't have a trace where to look next. Could this be a cinder-csi driver issue or something? Our cinder backend is ceph (Pacific). Not sure which information could help so please ask for anything I can provide. Any pointers are highly appreciated! Thanks! Eugen

1 2

ERROR openstack [-] Resource OS::TripleO::Network::Ports::ControlPlaneVipPort maps to type OS::Neutron::Port and the Neutron service is not available when using ephemeral Heat.| Openstack tripleo wallaby version
by Swogat Pradhan 24 Dec '24

24 Dec '24

Hi, I am currently trying to deploy openstack wallaby using tripleo arch. I created the network jinja templates, ran the following commands also: #openstack overcloud network provision --stack overcloud --output networks-deployed-environment.yaml custom_network_data.yaml # openstack overcloud network vip provision --stack overcloud --output vip-deployed-environment.yaml custom_vip_data.yaml # openstack overcloud node provision --stack overcloud --overcloud-ssh-key /home/stack/sshkey/id_rsa overcloud-baremetal-deploy.yaml and used the environment files in the openstack overcloud deploy command: (undercloud) [stack@hkg2director ~]$ cat deploy.sh #!/bin/bash THT=/usr/share/openstack-tripleo-heat-templates/ CNF=/home/stack/ openstack overcloud deploy --templates $THT \ -r $CNF/templates/roles_data.yaml \ -n $CNF/workplace/custom_network_data.yaml \ -e ~/containers-prepare-parameter.yaml \ -e $CNF/templates/node-info.yaml \ -e $CNF/templates/scheduler-hints.yaml \ -e $CNF/workplace/networks-deployed-environment.yaml \ -e $CNF/workplace/vip-deployed-environment.yaml \ -e $CNF/workplace/overcloud-baremetal-deployed.yaml \ -e $CNF/workplace/custom-net-bond-with-vlans.yaml Now when i run the ./deploy.sh script i encounter an error stating: ERROR openstack [-] Resource OS::TripleO::Network::Ports::ControlPlaneVipPort maps to type OS::Neutron::Port and the Neutron service is not available when using ephemeral Heat. The generated environments from 'openstack overcloud baremetal provision' and 'openstack overcloud network provision' must be included with the deployment command.: tripleoclient.exceptions.InvalidConfiguration: Resource OS::TripleO::Network::Ports::ControlPlaneVipPort maps to type OS::Neutron::Port and the Neutron service is not available when using ephemeral Heat. The generated environments from 'openstack overcloud baremetal provision' and 'openstack overcloud network provision' must be included with the deployment command. 2022-04-19 13:47:16.582 735924 INFO osc_lib.shell [-] END return value: 1 Can someone tell me where the mistake is? With regards, Swogat Pradhan

4 4

[kolla] [openeuler] CI jobs status
by Michał Nasiadka 26 Nov '24

26 Nov '24

Hello Koalas, OpenEuler jobs in master (to be Antelope) are failing for a long time. If no one is interested in maintaining OpenEuler support in Kolla-Ansible - I will propose dropping it’s support on Wednesday Kolla meeting. Best regards, Michal

4 3

[horizon][ceph] object storage container storage policy missing
by Satish Patel 25 Nov '24

25 Nov '24

Folks, Openstack Release: Zed Recently I have integrated ceph RGW service with openstack/keystone and testing with command line tool "openstack container create foo1" and it works but when I go to Horizon UI I am seeing it doesn't have storage policy dropdown list and because of that I am not able to create container or upload file from Horizon GUI https://ibb.co/KhYW6Rd It works with commands like but not horizon. $ openstack container create foo1 +---------------------------------------+-----------+------------------------------------------------+ | account | container | x-trans-id | +---------------------------------------+-----------+------------------------------------------------+ | AUTH_d4d82849885e4126aef402c408ad2c5c | foo1 | tx00000c057454841b13497-0065b558b4-42ff2eb-ahm | +---------------------------------------+-----------+------------------------------------------------+ $ openstack container list +------+ | Name | +------+ | foo1 | +------+

2 2

[nova][libvirtd] internal error: unable to execute QEMU command 'query-named-block-nodes'
by Satish Patel 22 Oct '24

22 Oct '24

Folks, I have a ceph cluster and recently I configured rbd-mirror to replicate all data to remove ceph cluster for disaster recovery. Yesterday for POC we did a hard cutover on ceph and point openstack to the new cluster. All other vms came back up fine but 2 vms stuck in this error state in libvirt logs 2024-01-31 22:44:37.591+0000: 474597: error : qemuMonitorJSONCheckErrorFull:399 : internal error: unable to execute QEMU command 'query-named-block-nodes': cannot read image start for probe: Permission denied If it's a wider issue than it should impact all the vms but why only two VM stuck and not starting and libvirt giving me this error in logs nova-compute logs also showing same error 2024-01-31 22:44:40.925 7 INFO nova.compute.manager [None req-b33485b5-8740-48ae-8b5b-a440de3f11a4 c48fcfb9347f413f92fcece065644b00 ca5c652478c7429e964257990800e9cb - - default default] [instance: 2de0f880-77c7-4d2c-9e01-898c57ad3693] Successfully reverted task state from powering-on on failure for instance. 2024-01-31 22:44:40.944 7 ERROR oslo_messaging.rpc.server [None req-b33485b5-8740-48ae-8b5b-a440de3f11a4 c48fcfb9347f413f92fcece065644b00 ca5c652478c7429e964257990800e9cb - - default default] Exception during message handling: libvirt.libvirtError: internal error: unable to execute QEMU command 'query-named-block-nodes': cannot read image start for probe: Permission denied

3 8

Kolla Ansible on Ubuntu 20.04 - cloud-init & other network issues
by Tobias McNulty 10 Oct '24

10 Oct '24

Hi, I'm attempting to use Kolla Ansible 14.6.0 to deploy OpenStack Yoga on a small 3-node Ubuntu 20.04 cluster. The nodes have 128 GB RAM each, dual Xeon processors, and dual 10G Intel NICs. The NICs are connected to access ports on a 10G switch with separate VLANs for the local and external networks. All the playbooks run cleanly, but cloud-init is failing in the Ubuntu 20.04 and 22.04 VMs I attempt to boot. The VM images are unmodified from https://cloud-images.ubuntu.com/, and cloud-init works fine if I mount a second volume with user-data. The error is a timeout attempting to reach 169.254.169.254. This occurs both when booting a VM in an internal routed network and directly in an external network. I tried various neutron plugin agents (ovn, linuxbridge, and openvswitch both with and without firewall_driver = openvswitch <https://docs.openstack.org/kolla-ansible/latest/reference/networking/neutro…>) first with a clean install of the entire OS each time, all with the same result. Running tcpdump looking for 169.254.169.254 shows nothing. As a possible clue, the virtual NICs are unable to pass any traffic (e.g., to reach an external DHCP server) unless I completely disable port security on the interface (even if the associated security group is wide open). But disabling port security does not fix cloud-init (not to mention I don't really want to disable port security). Are there any additional requirements related to deploying OpenStack with Kolla on Ubuntu 20.04? This is a fairly vanilla configuration using the multinode inventory as a starting point. I tried to follow the Quick Start <https://docs.openstack.org/kolla-ansible/yoga/user/quickstart.html> as closely as possible; the only material difference I see is that I'm using the same 3 nodes for control + compute. I am using MAAS so it's easy to get a clean OS install on all three nodes ahead of each attempt. I plan to try again with the standard (non-HWE) kernel just in case, but otherwise I am running out of ideas. In case of any additional clues, here are my globals.yml and inventory file, along with the playbook I'm using to configure the network, images, VMs, etc., after bootstrapping the cluster: https://gist.github.com/tobiasmcnulty/7dbbdbc67abc08cbb013bf5983852ed6 Thank you in advance for any advice! Cheers, Tobias

5 9

Live migration fails
by Szabo, Istvan (Agoda) 07 Aug '24

07 Aug '24

Hi, I have couple of compute nodes where the live migration fails with existing vms. When I quickly spawn a vm and try live migration it works so I assume shouldn't be a big problem with the compute node. However I have many existing vms where it fails with a servername not found. /var/log/nova/nova-conductor.log:2021-04-21 14:47:12.605 227612 ERROR nova.conductor.tasks.migrate [req-f4067a26-a233-4673-8c07-9a8a290980b0 dce35e6eceea4312bb0baa0510cef363 ca7e35079f4440c78bd9870724b9638b - default default] [instance: 1517a2ac-3b51-4d8d-80b3-89a5614d1ae0] Unable to find record for source node servername on servername: ComputeHostNotFound: Compute host servername could not be found. /var/log/nova/nova-conductor.log:2021-04-21 14:47:12.605 227612 WARNING nova.scheduler.utils [req-f4067a26-a233-4673-8c07-9a8a290980b0 dce35e6eceea4312bb0baa0510cef363 ca7e35079f4440c78bd9870724b9638b - default default] Failed to compute_task_migrate_server: Compute host servername could not be found.: ComputeHostNotFound: Compute host servername could not be found. /var/log/nova/nova-conductor.log:2021-04-21 14:47:12.605 227612 WARNING nova.scheduler.utils [req-f4067a26-a233-4673-8c07-9a8a290980b0 dce35e6eceea4312bb0baa0510cef363 ca7e35079f4440c78bd9870724b9638b - default default] [instance: 1517a2ac-3b51-4d8d-80b3-89a5614d1ae0] Setting instance to ACTIVE state.: ComputeHostNotFound: Compute host servername could not be found. /var/log/nova/nova-conductor.log:2021-04-21 14:47:12.672 227612 ERROR oslo_messaging.rpc.server [req-f4067a26-a233-4673-8c07-9a8a290980b0 dce35e6eceea4312bb0baa0510cef363 ca7e35079f4440c78bd9870724b9638b - default default] Exception during message handling: ComputeHostNotFound: Compute host am-osfecn-4025 Tried with this command: nova live-migration --block-migrate id. Any idea? Thank you. ________________________________ This message is confidential and is for the sole use of the intended recipient(s). It may also be privileged or otherwise protected by copyright or other legal rules. If you have received it by mistake please let us know by reply email and delete it from your system. It is prohibited to copy this message or disclose its content to anyone. Any confidentiality or privilege is not waived or lost by any mistaken delivery or unauthorized disclosure of the message. All messages sent to and from Agoda may be monitored to ensure compliance with company policies, to protect the company's interests and to remove potential malware. Electronic messages may be intercepted, amended, lost or deleted, or contain viruses.

5 16

[ptl][tc] OpenStack packages PyPi additional external maintainers audit & cleanup
by Ghanshyam Mann 17 May '24

17 May '24

Hi PTLs, As you might know or have seen for your project package on PyPi, OpenStack deliverables on PyPi have additional maintainers, For example, https://pypi.org/project/murano/, https://pypi.org/project/glance/ We should keep only 'openstackci' as a maintainer in PyPi so that releases of OpenStack deliverables can be managed in a single place. Otherwise, we might face the two sets of maintainers' places and packages might get released in PyPi by additional maintainers without the OpenStack project team knowing about it. One such case is in Horizon repo 'xstatic-font-awesome' where a new maintainer is added by an existing additional maintainer and this package was released without the Horizon team knowing about the changes and release. - https://github.com/openstack/xstatic-font-awesome/pull/2 To avoid the 'xstatic-font-awesome' case for other packages, TC discussed it in their weekly meetings[1] and agreed to audit all the OpenStack packages and then clean up the additional maintainers in PyPi (keep only 'openstackci' as maintainers). To help in this task, TC requests project PTL to perform the audit for their project's repo and add comments in the below etherpad. - https://etherpad.opendev.org/p/openstack-pypi-maintainers-cleanup Thanks to knikolla to automate the listing of the OpenStack packages with additional maintainers in PyPi which you can find the result in output.txt at the bottom of this link. I have added the project list of who needs to check their repo in etherpad. - https://gist.github.com/knikolla/7303a65a5ddaa2be553fc6e54619a7a1 Please complete the audit for your project before March 15 so that TC can discuss the next step in vPTG. [1] https://meetings.opendev.org/meetings/tc/2023/tc.2023-01-11-16.00.log.html#… -gmann

18 27

[kolla-ansible] support for FWaaS/LBaaS?
by garcetto 15 May '24

15 May '24

good morning, does kolla support fwaas or lbaas? thank you

3 4

[all][packaging][release][qa] pep-517 and pip 23
by smooney＠redhat.com 06 May '24

06 May '24

hi folks, TL;DR ----- this is a long email so the tl;dr is we should add pyproject.toml ``` [build-system] requires = ["pbr>=5.7.0", "setuptools>=36.6.0", "wheel"] build-backend = "pbr.build" ``` to all openstack projects to supprot pip 23.1+ Long version ------------ As some of you may know the ptg happend last week an done of hte topic raised there was a know limitation in devstack where GLOBAL_VENV=True does not work on centos/fedora derived distros. while i generally dont use centos/fedora derived distros for my daily work i have been using devstack for over 10 years at this point so when im told it broken i ocationlly will go fix it. In this case the issue is not with devstack (it often isnt) and is actully in our collective reliance on a deprecated functionality and how we package openstack today. Back story, for better or worse when openstack was created the landscape of python packaging was significantly different then it is today. To help corodinate our dependcies the openstack comunity went all in on requirements.txt and developed upper-constraits to manage our requirements and developed PBR (python build Reasonableness). both of those approches have served us well and likely will continue to do so for some time. Since then pyproject.toml has started to gain popularity and pep-517 (A build-system independent format for source trees) has been adotpted but so far openstack as a comunity has not embraced those changes. (although pbr already supprot pep-517 :) ). Until now this has not been a problem however with recent release of pip things are now breaking. Problem Context: - openstack does not provide pyporject.toml files - openstack project configure setuptools to use pbr via setup.py - setuptools support generating scripts form entry points(console_scripts) which we use for project binaries( nova- compute, neutron-server, ...) - openstack api services use a pbr extension know as wsgi_scripts which adds a similar functionality for generating wsgi application mains file - devstack due to coming changes in distro to block "sudo pip install" now installs openstack in a single by default on debian distros. on centos/fedora distros it currently almost functional (but not). - devstack installs in editable mode because that is how most developers use devstack for developemnt What changed: - pip 20.2 deprecated support for falling back to calling setup.py when pyproject.toml is not present - https://pip.pypa.io/en/stable/news/#v20-2 - https://github.com/pypa/pip/issues/8368 - at this point when pyproject.yaml is not called pip calls setup.py install [-e] <path to repo or package name> - setup.py invokes pbr to generate wsgi_scripts and other files - in pip 23.1 the fallback was removed https://pip.pypa.io/en/stable/news/#v23-1 - pip now builds a temp local wheel instead of calling setup.py install when pyproject.toml is not found - in editable mode (-e) the default way the wheel is built does not invoke pbr properly to generate the wsgi files - as a result the wsgi files are not installed to the venv bin dir and this causes devstack to fail to start keystone (or any other wsgi api) The fix, there are a few ways to approch this: - clamp pip (https://review.opendev.org/c/openstack/devstack/+/898845) this is a terible idea and it breaks debian - clamping pip below 23.1 works on centos for now however OVS on debian already requires pep 517 for installing - as such when that version of ovs (or other projects start enforcing that) hits centos it will break - add a minimal pyproject.toml to all openstack project - example for keystone https://review.opendev.org/c/openstack/keystone/+/899519 - this example jsut adds the minium pyproject.toml to enable pbr to be used as the build system - it does not remove supprot for setup.py but it will not be used by default going forward whit new version of pip - all config is still in setup.cfg - add pyproject.toml support but remove setup.py support https://review.opendev.org/c/opendev/bindep/+/816741 - this goes one step futrue and actuly nulls out setup.py - we could take this approach if we want to but its not required. The reason for this email is to get agreement on how to support pip 23.1+ My proposal would be to add pyproject.toml with the minimal config required to enable pip 23.2 but not drop the setup.py support in this cycle. i would suggest that we can deprecate installing via setup.py in caracal if that is desirable but not make that change until the next slurp to give time to projects and packages to catch up. if there are no objections to that i would like to ask what is the preferd way to create and submit the patches for the minimal pyproject.toml ``` [build-system] requires = ["pbr>=5.7.0", "setuptools>=36.6.0", "wheel"] build-backend = "pbr.build" ``` i can propose patches to the main project deployed by devstack by default. i.e. nova/neutron ectra but it might be better if someone form the core teams of each project could take on that task and chasing the reviews. if someone has a script to generate a patch for a set of repos that just add the above pyporject.toml then we can use that to keep a consistent topic/commit message across all patches. my proposal for testing this is two fold. in ci we can test the patches are functional by using a DNM patch to devstack to force enable the gloal venv on centos and depend on the set of patches, i will modify https://review.opendev.org/c/openstack/devstack/+/898845 to do that locally we can test that the patch is functional by doing the following substituting keystone for the relevant project. ``` git clone https://opendev.org/openstack/keystone cd keystone python3 -m venv .venv . .venv/bin/activate python3 -m pip install -U pip python3 -m pip install -e . ls .venv/bin/keystone* ``` the ls will not contain the wsgi script with the addition of the pyproject.toml it should. on debian sid i can reproduce the same issue the problem we are seeing on centos 9 now will start impacting other distos eventually so its good to fix this now. if i start proposing this to glance/nova/neutron/cinder/swift/horizon/placement (to get a default devstack working) can i get cores to review? can cores form each project nominate peopel to review or volenteer to do this work. i have created https://etherpad.opendev.org/p/pep-517-and-pip-23 to track this work i have some other work that i think we can do in parallel like addign pyporject.toml support to the pti requirements if we go this way but that i think we can discuss on a governacne patch to updated it. anyway this is a lot to digest so feedback is welcome. if someone else would like to drive this that is also welcome (i.e. tc/release team) regards sean.

10 27

[all][tc] Modernize Python Stack
by Niklas Schwarz 11 Apr '24

11 Apr '24

Hello, I have just ran over the mailing listing post OpenStack 2024.2 testing runtime by Ganshyam Mann [1] on dropping support for python3.8 for the upcoming Openstack 2024.2 release. This post and some small contributions to some openstack components have lead me to write this post. What I would like to suggest to modernize the Python-Stack used for OpenStack. Such a modernization includes: - A current python version - A modern and up to date static code analysis - Introduce type annotations Let me explain what I mean: A current python version: The current supported Python versions are Python 3.8 to Python 3.11 [2]. As of writing, OpenStack Yoga was just moved to unmaintained. To install this release, e.g. on an Ubuntu Jammy operating system the packages are included in the Ubuntu-Packages. The default Python version on an Ubuntu 22.04 operating system is Python3.10. And looking at the support of the Python versions [3] Python 3.8 to 3.10 only receive security updates but the end is near for Python 3.8 to be out of support. The policy defined which Python version should be used for testing [4] will result that Python 3.8 is still used for the OpenStack 2024.1 release [5]. And this will also result in required support for Python3.8 in the upcoming releases of OpenStack. I my opinion the policy should be reworked and the OpenStack releases should be more aggressive on dropping support for older Python versions. Modern features of the language cannot be otherwise be used, therefor improvements in speed, security and general toolchain/ecosystem cannot be fully leveraged. By defining the lower bound of the Python Version we are limiting ourself to this version but we might also reduce the features we can use because of deprecations of the newer versions . A modern and up to date static code analysis: Currently flake8 and pylint are used both of which are modern analysis tools. But their configuration is in my opinion not up to date. Lets have a look at the configuration of the neutron-lib [6]. As seen a lot of rules are disabled by the configuration and are needed at the current moment at the state of the project. In addition some rules need to be adjusted such as the line length (80 characters is a very aggressive limit and on most modern displays a line length of 100 to 120 can fit without any problems, personal opinion). The adjustment of the static code analysis besides opinionated rules will lead me to my third point to modernize the Python stack used Introduce type annotations Python type annotations are well supported in the current Python versions and through the typing package additional types are added. The introduction of type annotations will improve the developer experience. This is also motivated by the Python foundation in pep-484 [7]. Because of the type annotation all modern IDEs can provide (more precise) type hints. The type hints can and in in my experience will reduce the introduction of bugs (accessing members or calling methods, no logical bugs) and will shorten the time to develop a new feature or fix a logical bug and do not run in runtime exceptions. The datatypes passed to a method are clear and we do not need to dig down a rabbithole to find out what is passed to a method. The name of a variable does not always tell the truth. As an example I want to look at a patch [8] for the neutron-vpnaas component. Christian Rohmann and I worked on this patch for the component together (this has also lead me to write this email) to improve the reconciling for VPNaaS. It took as along time to find out that a RouterInformation object is passed in to a method instead of a router but the variable was named router. We both agreed on that in the first place the naming of the variable was wrong but type annotations would have saved us a good amount of time. This does not mean that the naming is not important and that type annotations will save the world, the context which includes the name of variables is important and type annotations will add additional information to the context. And I have just touched the surface on what is possible with the introduction of type annotations, thinking of automatic document generation, test generation, even code generation,... As a reference to my point modernizing the static analysis this can then also include the introduction of mypy to check the types used. Of course such a change cannot be done in one big commit and needs time but I suggest to start adding type annotations and improve the overall code quality of the OpenStack services, starting with the oslo packages as they are used by mostly all OpenStack components. Of course such changes cannot be done for such a huge project in one day. It took a long time to remove support for Python 2. So I do not expect such changes to happen immediately. But it would be nice to have a discussion about it and maybe create a road map and adjust some policy on supported Python versions and create new policies how to write Python code and what additional tools should be used. I can also understand if not everything is possible but the last two points need to be addressed in my opinion. These changes will lead overall to better code quality but most important the introduction to the big code base will be easier for new developers and reviewers will also have a better time. Best regards Niklas [1] https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… [2] https://docs.openstack.org/tempest/latest/supported_version.html [3] https://devguide.python.org/versions/ [4] https://governance.openstack.org/tc/resolutions/20181024-python-update-proc… [5] https://governance.openstack.org/tc/reference/runtimes/2024.1.html [6] https://github.com/openstack/neutron-lib/blob/master/.pylintrc [7] https://peps.python.org/pep-0484/#rationale-and-goals [8] https://review.opendev.org/c/openstack/neutron-vpnaas/+/875745

15 27

Accessing virsh in openstack wallaby | tripleo
by Swogat Pradhan 24 Mar '24

24 Mar '24

Hi, Can someone please tell me how can i access the virsh utility on the compute node on openstack wallaby? Previously we used nova_libvirt but in wallaby there are multiple containers and i am unable to use virsh utility to edit my domain.xml file. List of containers: [root@dcn01-hci-2 ~]# podman ps | grep nova 10d981158842 172.25.201.68:8787/tripleomaster/openstack-nova-libvirt:current-tripleo kolla_start 2 months ago Up 2 months ago nova_virtlogd_wrapper e91667516afc 172.25.201.68:8787/tripleomaster/openstack-nova-libvirt:current-tripleo kolla_start 2 months ago Up 2 months ago nova_virtsecretd a4b07fe0e833 172.25.201.68:8787/tripleomaster/openstack-nova-libvirt:current-tripleo kolla_start 2 months ago Up 2 months ago nova_virtnodedevd d7e1db393e9c 172.25.201.68:8787/tripleomaster/openstack-nova-libvirt:current-tripleo kolla_start 2 months ago Up 2 months ago nova_virtstoraged 5308a171793e 172.25.201.68:8787/tripleomaster/openstack-nova-libvirt:current-tripleo kolla_start 2 months ago Up 2 months ago nova_virtqemud f490a6249ba1 172.25.201.68:8787/tripleomaster/openstack-nova-libvirt:current-tripleo kolla_start 2 months ago Up 6 weeks ago nova_virtproxyd ab0441e56957 172.25.201.68:8787/tripleomaster/openstack-nova-compute:current-tripleo kolla_start 2 months ago Up 2 months ago (healthy) nova_migration_target f35fbba5b690 172.25.201.68:8787/tripleomaster/openstack-nova-compute:current-tripleo kolla_start 2 months ago Up 6 weeks ago (unhealthy) nova_compute 82bc01993106 172.25.201.68:8787/tripleomaster/openstack-nova-libvirt:current-tripleo /usr/sbin/virtlog... 2 months ago Up 2 months ago Can someone please suggest how I can i edit an instance xml file in this setup? With regards, Swogat Pradhan

2 5

[swift] Can I use oslo.log / oslo.config in swift? Can we make Swift behave like the rest of OpenStack?
by Thomas Goirand 20 Mar '24

20 Mar '24

Hi, Because we had some issues with a bad rebalance in production (we didn't loose any data, but some drives went full...), I attempted to implement the Swift mitigation to prevent disk full scenarios. I found that what upstream recommends [1] is a script that's written in Python 2, and that wouldn't work at all: it's not only very old, it's also a very partial implementation. So I wrote this: https://review.opendev.org/c/openstack/swift/+/907523 But then, I was told (thanks for the review!) that I shouldn't be using oslo.config and/or oslo.log, as other parts of Swift don't do that. I do understand that the rest of Swift is like this, and therefore, the review comment is probably right. However... Back in the days, I would have understood why things would have been written that way: the Oslo libs were young, and not available everywhere, and it was kind of a good idea not to use them. But now, fast forward in 2024, I found that Swift behaving differently from the rest of OpenStack is more a problem than a feature. It's also very frustrating to use the old way with the config_parser, which can't auto-generate the config file and so on. So I am wondering: - is it still the case, that I shouldn't use oslo.config / oslo.log when adding a patch in Swift? - can we revisit this, and convert swift to oslo.config generated config files, and PBR shell-script entry points instead of binary simply dropped into the toplevel bin folder? Can we make swift smarter and behave like the rest of OpenStack? :) Cheers, Thomas Goirand (zigo) [1] https://docs.openstack.org/swift/latest/admin_guide.html#preventing-disk-fu…

2 2

Use Openstack SDK for Swift
by Albert Braden 20 Mar '24

20 Mar '24

I'm writing a script that will use admin credentials to check user projects for containers. I'm already doing something similar for non-swift accounts, doing things like: cloud.network.networks(project_id=projectid): I read here about the Object SDK: https://docs.openstack.org/openstacksdk/latest/user/guides/object_store.html And I tried this: cloud.object_store.containers(project_id=projectid): But I get an error: Invalid query params: project_id I read the Object SDK document here and it doesn't seem to say anything about how to specify a project: https://docs.openstack.org/openstacksdk/latest/user/proxies/object_store.ht… But when I read the Swift API document, I see that I can use "/v1/{account}/{container}", so I'm guessing that there must be a way to do it via the SDK. https://docs.openstack.org/api-ref/object-store/#show-container-details-and… Is it possible to specify the project in an Object SDK call, or do I need to use the old python API for this?

2 2

[Freezer] Is Freezer dead?
by pi3.14＠tuta.io 19 Mar '24

19 Mar '24

Hi folks, is Freezer still supported? I don't see any real development going on with it. Is it recommended to use in a production Cloud environment? Are there other free and open source alternatives to Freezer? Thanks Roby

8 19

[swift] Increase part power on account/container ring
by Thiago De Moraes Teixeira 13 Mar '24

13 Mar '24

Morning, Here we have a cluster with Accounts/Containers ring with part power 8 and our Objects ring with part power 20 (builted later). Now we want to migrate the 'old' Accounts/Containers ring to a new one, with higher part power, like 20. Is there a better way to do this? I'm doing some crazy tests with SAIO and multiples storage nodes, based in build a new ring with part power 20 and just swap the old files (account/container.ring.gz) with the new ones and let the replicators do their jobs, moving *.db files to their new home partition. Until today these tests worked fine, but I don't know how to do it on a large scale, with some terabytes of data. Just wondering about some ways to do that :) And before/after this change, is there any command in swift that i can audit this entire process, ensuring that cluster data remains the same? Thanks! -- _‘Esta mensagem é direcionada apenas para os endereços constantes no cabeçalho inicial. Se você não está listado nos endereços constantes no cabeçalho, pedimos-lhe que desconsidere completamente o conteúdo dessa mensagem e cuja cópia, encaminhamento e/ou execução das ações citadas estão imediatamente anuladas e proibidas’._ * **‘Apesar do Magazine Luiza tomar todas as precauções razoáveis para assegurar que nenhum vírus esteja presente nesse e-mail, a empresa não poderá aceitar a responsabilidade por quaisquer perdas ou danos causados por esse e-mail ou por seus anexos’.*

3 8

[neutron][horizon] disable permission to release floating ip for non-admin users
by Satish Patel 09 Mar '24

09 Mar '24

Folks, I want to disable permission or the horizon button or whatever best way to not allow end users to "Release floating IP" because I want them to stick with assigned IP and not releasing them because of some regulatory process. Not sure what is the best way to have this level of control. I found neutron policy delete_floatingip: but is this the correct way to implement this policy? OR Does Horizon have some level of ACL to remove buttons or disable it? Looking for advice or clues. Thanks!

3 2

[heat][monasca][sahara][senlin] Features dependent on inactive projects
by Takashi Kajinami 09 Mar '24

09 Mar '24

Hello, As you know, some of the OpenStack projects were marked inactive during this cycle. There are still on-going discussions but from my view these are very likely excluded from the upcoming 2024.1 release and it's unclear yet if any of these projects will be kept. Currently heat provides features integrated with some of the inactive projects (Monasca, Sahara and Senlin), and we have to decide how we deal with these features[1]. The main concern is that we can't maintain the features for the inactive projects, and IMO we should retire these features if these inactive projects are abandoned or are no longer maintained in the consistent way with the other active projects. Based on the current situation, I'd propose the following steps for upcoming cycles. - Deprecate the features dependent on inactive projects in 2023.2 release - Note that we have to remove these features directly during this cycle in case any problems related to these project block the upcoming heat release. - Remove these features in 2024.1 release unless we are sure that these projects are kept maintained as active projects in the openstack namespace, with following the global release cycle. Please let me know if you have any concern about the proposed plan. If I hear no objections then I'll propose patches for deprecation. Thank you, Takashi Kajinami irc: tkajinam [1] I've submitted a series of patches to remove these features and these would give a clear view about the features affected. https://review.opendev.org/q/topic:%22inactive-project-removal%22+project:o…

3 6

[neutron] Is the vxlan(overlay) network a Provider network or a self-service network
by 韩光宇 08 Mar '24

08 Mar '24

Hi, In neutron install doc[1], I got the concept of Provider network and Self-service network. And I got that: - Provider network bridges virtual networks to physical networks and relies on physical network infrastructure for layer-3 (routing) services - Self-service network routes virtual networks to physical networks using Network Address Translation (NAT) So I understand: Flat/Vlan network are Provide network and vxlan/gre network are Self-service network. But, in openstack cmd, I found that all network types are classified as provider network types. ``` openstack network create --help ... --provider-network-type <provider-network-type> The physical mechanism by which the virtual network is implemented. For example: flat, geneve, gre, local, vlan, vxlan. ``` I am confused, why do vxlan and gre appear in the **provider network type**? According to the installation doc[1], overlay networks should not all be self-service networks Or is the provider network in cmd not the same as the provider network in the installation document, the provider network here is only different from the tenant network? Can someone help me distinguish between these concepts, or suggest questions that I can read: why vxlan is provider network I will appreciate for any help. Best wishes, Han Guangyu [1] https://docs.openstack.org/neutron/latest/install/controller-install-obs.ht…

2 1

[cinder][glance][nova][telemetry][monasca][oslo][vmware] Can we deprecate(and remove) VMWare support ?
by Takashi Kajinami 07 Mar '24

07 Mar '24

Hi all, As you might know, some of the OpenStack projects currently support usage of VMWare component. However recently the VMware virt driver in nova was marked experimental in 2023.2 release [1] and it has been discussed that the driver will be removed in 2023.2 release[2], after deprecation is backported to 2023.1. (Please someone from nova team correct me if I'm wrong) So my current question is; Does it make sense to deprecate all of the features to support VMWare component ? My understanding is that these features were added to be used along with VMWare virt driver in nova, but once the virt driver is removed this use case is voided. I'll list up the features within the discussion scope below. nova: VMWare virt driver (this is already experimental by [1]) cinder: VMware Storage Driver (vmdk) glance: VMWare Datastore (I proposed deprecating this in [3][4]) ceilometer: VMWare virt driver (this was deprecated by [5]) os-brick: VmdkConnector monasca-agent: vcenter collector (*1) oslo.vmware: the whole project NOTE: These features are found based on dependency on oslo.vmware but there can be a few not listed here. Outside of OpenStack's governance, there are two projects dependent on oslo.vmware, networking-vsphere and vmware-nsx but both of these look inactive. Because of SLURP, we have to complete deprecation during in 2024.1 release so that we can drop the feature right after 2024.1. If we fail then we have to maintain these features until 2025.1 (the features already deprecated can be removed earlier, though). So I'd like to get feedback and decision before deadline for 2024.1 Thank you, Takashi (*1) Monasca is now inactive so I doubt anyone would work on this topic before it is retired. [1] https://review.opendev.org/c/openstack/nova/+/863911 [2] https://review.opendev.org/c/openstack/nova/+/897017 [3] https://review.opendev.org/c/openstack/glance_store/+/893696 [4] https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… [5] https://review.opendev.org/c/openstack/ceilometer/+/894540

6 21

[kolla][cinder][nfs] NFS backend error for volumes
by Satish Patel 07 Mar '24

07 Mar '24

Folks, I am configuring NFS for the cinder backend but somehow it doesn't go well. I am running kolla-ansible with the 2023.1 release. cinder.conf [DEFAULT] enabled_backends = volumes-ssd,volumes-nfs [volumes-nfs] volume_driver = cinder.volume.drivers.nfs.NfsDriver volume_backend_name = volumes-nfs nfs_shares_config = /etc/cinder/nfs_shares nfs_snapshot_support = True nas_secure_file_permissions = False nas_secure_file_operations = False Inside the cinder_volume docker container I can see it mounts NFS automatically and directory permissions is also cinder:cinder also I am able to write on NFS share also so it's not a permission issue also. $ docker exec -it cinder_volume mount | grep nfs 192.168.18.245:/volume1/NFS on /var/lib/cinder/mnt/1ec32c051aa5520a1ff679ce879da332 type nfs (rw,relatime,vers=3,rsize=131072,wsize=131072,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.18.245,mountvers=3,mountport=892,mountproto=udp,local_lock=none,addr=192.168.18.245) But service is still showing down. | cinder-volume | os-ctrl2@volumes-nfs | nova | enabled | down | 2024-02-28T04:13:11.000000 | In logs I am seeing these 3 lines but then no activity in logs even after restarting the container so that is very strange. 2024-02-28 04:13:12.995 153 ERROR os_brick.remotefs.remotefs [None req-6bcb8eab-6aa6-4c36-9a7a-ed673c39dcbc - - - - - -] Failed to mount 192.168.18.245:/volume1/NFS, reason: mount.nfs: Protocol not supported : oslo_concurrency.processutils.ProcessExecutionError: Unexpected error while running command. 2024-02-28 04:13:13.501 153 WARNING cinder.volume.drivers.nfs [None req-6bcb8eab-6aa6-4c36-9a7a-ed673c39dcbc - - - - - -] The NAS file permissions mode will be 666 (allowing other/world read & write access). This is considered an insecure NAS environment. Please see https://docs.openstack.org/cinder/latest/admin/blockstorage-nfs-backend.html for information on a secure NFS configuration. 2024-02-28 04:13:13.501 153 WARNING cinder.volume.drivers.nfs [None req-6bcb8eab-6aa6-4c36-9a7a-ed673c39dcbc - - - - - -] The NAS file operations will be run as root: allowing root level access at the storage backend. This is considered an insecure NAS environment. Please see https://docs.openstack.org/cinder/latest/admin/blockstorage-nfs-backend.html for information on a secure NAS configuration. Has anyone configured NFS and noticed any behavior?

3 12

[Watcher] How use Watcher to scheduler Openstack resource without cpu_usage
by Nguyễn Hữu Khôi 06 Mar '24

06 Mar '24

Hello guys. I want to use watcher to scheduler openstack resources but some openstack versions are missing cpu_usage metric. How do we use Watcher without it? Thank you. Nguyen Huu Khoi

3 5

[tc][murano] Removing Murano from 2024.1 release
by Jay Faulkner 06 Mar '24

06 Mar '24

Hi all, After discussion in the TC meeting today about lots of gathered evidence that Murano is inactive and plagued by serious bugs, I have proposed a resolution to remove Murano from the release. This is roughly equivalent to marking it inactive; however we can only use inactive status to remove things from the release before milestone-2. At this point, the TC is too late discovering the bad state of Murano to use inactivity to prevent its release. Therefore, I have proposed a special-case resolution[0] reflecting general consensus in the TC meeting that Murano should not be released. I wanted to inform the community of this resolution, and advise anyone who may be considering deployment of Murano to be aware of its current inactive state. Additionally, if you believe our evaluation of the situation is wrong, feel free to let your voice be heard in Gerrit. Thanks, Jay Faulkner OpenStack TC Chair 0: https://review.opendev.org/c/openstack/governance/+/910434

1 1

[diskimage-builder] bootable ISO image for baremetal
by Ettore Simone 05 Mar '24

05 Mar '24

Hi! I know it is not one of the most wonderful options for DIB, but in some circumstances I used ISO image in a USB stick for some old and unmaintained hardware. I used to fix by hand every time the "iso" element to complete the task, due to an old reference to a deprecated variable (DIB_IMAGE_ROOT_FS_UUID, now DIB_BOOT_LABEL). I proposed a very small fix and I hope it could be merged in the future: https://review.opendev.org/c/openstack/diskimage-builder/+/905556 Thank you for all your great work. Cheers, Ettore

4 6

[magnum][nova] AZ or Host aggregates not working as expected
by Satish Patel 05 Mar '24

05 Mar '24

2 13

Need Help to setup Bumblebee VDI project
by Artemio Mendoza 02 Mar '24

02 Mar '24

Hello, I'm trying to set up the Bumblebee (https://github.com/NeCTAR-RC/bumblebee) project on my local computer to test. So I installed docker and tried setup by following the readme. But I'm really new in OpenStack (only tried to run OpenStack through devstack) so I would appreciate it if I could have a very detailed guide. So please share any idea, online video link, or guide document. anything is good to me. Looking forward to hearing from you. Thanks, Artemio Mendoza

3 4

[TC][openapi] Request for new projects under the OpenStack hat
by gtema 01 Mar '24

01 Mar '24

Hi TC representatives, Some time ago I was communicating about my POC on generating OpenAPI schemas from the source code of services. I continued working on that and have now few projects (that I was developing on GitHub to make life easier) that I would like to bring under the OpenStack hood (and place them under the SDK team). I have also figured out that Nova is now reviewing spec on starting using supporting this (thanks Stephen) and Neutron folks expressed also interest. === codegenerator https://gtema.github.io/openstack-codegenerator/ This project is responsible for generation of the OpenAPI specs and generate other (currently user-facing) code ouf of them === openstack-openapi https://gtema.github.io/openstack-openapi/ This repo hosts rendered specs and provides analogue to the os-api-ref Sphinx extension that renders them into the html (what you see under the link is a mix of Swagger and os-api-ref style). I was not really effectively working on that rendering lately, the repo right now is more or less a storage for the specs themselves with a first sketch of sphinx extension of rendering and basic OpenAPI flavoring doc. === openstack-rs https://gtema.github.io/openstack/ This is a Rust monorepo project with few items: - SDK for OpenStack out of the rendered OpenAPI specs - experimental CLI following very different approach compared to the python- openstackclient. It is compiled into single binary (what helps those not willing to pull whole python with all deps and the insanity we experience lately or those who build docker containers with only OSC inside to bypass the mentioned hell) and purely auto-generated from the specs - [future] openstack-tui (similar to k9s for Kubernetes) Here it is all really oriented only on the user facing tooling. I am very convinced in this project and will continue working on it independent on the outcome. Any objections/ideas/comments? Should I just go and create 3 project-config changes pending the approval? ====== Since I am on this topic anyway I would also like to address another related question. While working for OpenTelekomCloud we developed HashiVault plugin for managing OpenStack credentials as secrets (I had a talk on that in Vancouver). We tried to bring this to OpenDev but were unsure under which namespace. Pretty shortly a Hashi license issue started circling around and after few back and forth iterations we were not sure what to do with that project at all. Anyway the plugin itself is Apache-2 and working. It should be possible to also use it with OpenBAO (as a fork of Vault), but it was not tested so far. I am now not with Telekom anymore, but people there are still willing to contribute it under the OpenStack. Do you have any opinions on that? Is there interest in getting this under the OpenDev and if yes then which namespace (openstack or X)? ======= Thanks, Artem

4 5

[all][ptls][release] Action needed to move forward Unmaintained branch policy
by Jay Faulkner 01 Mar '24

01 Mar '24

Hi all, If you are a PTL of a project, a release liason, or a person generally interested in older OpenStack branches, please make sure you take a look at the topic here: https://review.opendev.org/q/topic:%22vwx-unmaintained%22 and vote appropriately on projects you care about. More information can be found in the commit message for the patches themselves. A lot of folks have done work behind the scenes to enable this transition; please help us by doing your part and getting these reviews done in a timely manner is one way we can show gratitude to the releases team and others who have worked to make this transition possible. Thanks, Jay Faulkner OpenStack TC Chair

2 1

[blazar] Proposing Mark Powers and Matt Crees as core reviewers
by Pierre Riteau 01 Mar '24

01 Mar '24

Hello, I would like to nominate two new core reviewers for the Blazar project: - Mark Powers from University of Chicago - Matt Crees from StackHPC Mark Powers has been operating Blazar for several years for the Chameleon project (https://www.chameleoncloud.org) and maintains a fork of Blazar with many changes for this environment. The most useful changes are gradually being contributed upstream. Matt Crees has contributed several useful features to Blazar in the past few releases and helps to maintain the code. The Blazar project will benefit from their expertise and I trust their input as reviewers. Best wishes, Pierre Riteau (priteau)

1 1

[all] Gate issues and memory pressure; can you help?
by Jay Faulkner 01 Mar '24

01 Mar '24

Hi all, As some of you are aware, keeping the OpenStack CI system operating is a massive amount of work, and it's a team effort. Along those lines, we continue to have issues with CI, and memory pressure is a common thread. Recently at a TC meeting[0] we discussed how the gate is using more ram -- now in the form of swap. One additional concern is that this memory usage increase may be reflective of what our users are experiencing -- bugs that we need to fix for the sake of our users. A specific target of concern is oslo.privsep[1], but generally a need for an audit of memory usages of OpenStack services would be of significant value to the community. If you're interested in taking on this work, please reach out here, on the mailing list, or in any relevant #openstack-* channel, such as #openstack-tc. In any event, don't wait for permission! Take action and see if you can make things better, even a little bit. Thanks, Jay Faulkner OpenStack TC Chair 0: https://meetings.opendev.org/meetings/tc/2024/tc.2024-02-20-18.00.log.html 1: https://opendev.org/openstack/oslo.privsep

1 0

[cinder] FFE request for [NetApp] LUN space allocation support in 2024.1
by Borra, Jayaanand 01 Mar '24

01 Mar '24

Hello All, I would like to request FFE in the 2024.1 Caracal cycle for the below patch https://review.opendev.org/c/openstack/cinder/+/893106 Reason for FFE: Addressing review comments Thank you! Jayaanand.

3 2

Openstack Networking queries
by KK CHN 29 Feb '24

29 Feb '24

List, My kolla-ansible OpenStack installation all-in-one on Virtual Machine( Ubuntu 22.04, ) This base VM has three vNICs 1. ens192 with ip 10.170.16.128 from my organization's LAN with internet connectivity 2. ens224 is configured manually with a 10.220.0.51 IP ( from a VLAN for internal testing without internet) 3. ens160 This interface is made up without any IPs ( I don't know why this has to be up without any IP address, but kolla-ansible all-in-one installation document specifies one interface like this required ) Can I do the kolla-ansible deployment with the above 2 vNICs only ( ens192 and ens 224 ?) But ens192 I cannot have without IP addresses as it is my organizational LAN. Other clients in the office use this Segment for daily work . I don't have control on 10.170.16.0/24 but only on10.170.16.128 ip Any serious issues there by using only ens192 and ens224 alone in this case ? ( I can use ens224 ( 10.220.0.0/24 segment as floating IPs as it is in my control as a VLAN) But How can I connect the internet and external world communication to this vLAN 10.220.0.0/24 from 10.170.16.128 IP which has the internet. (to use these vLAN IPs as floating point IPs ) my tenant network can be ( all VMs can be on 10.0.0.0/24) How to provide the internet to this vLAN 10.220.0.0/24 from the available internet connected IP ens192 (10.170.16.128 with internet) I have only control on this IP but not on 10.170.16.0/24 network as it is not under my control. Can I use the following config for bootstrapping and deploying kolla-ansible all-in-one *Correct me what I am missing or what wrong I am doing in this setup ??* (kolla_ansible_venv3) ubuntu@ubuntu-VM:~$ grep ^[^#] /etc/kolla/globals.yml --- workaround_ansible_issue_8743: yes config_strategy: "COPY_ALWAYS" kolla_base_distro: "ubuntu" openstack_release: "2023.1" kolla_internal_vip_address: "10.220.0.24" kolla_external_vip_address: "{{ kolla_internal_vip_address }}" kolla_container_engine: docker network_interface: "ens224" neutron_external_interface: "ens160" neutron_plugin_agent: "openvswitch" nova_compute_virt_type: "qemu" (kolla_ansible_venv3) ubuntu@ubuntu-VM:~$

2 1

*[glance] Request for Feature Freeze Exception*
by Abhishek Kekane 29 Feb '24

29 Feb '24

Hi Team, I would like to request FFE for "Using centralized database for cache operations" feature. Patches: https://review.opendev.org/q/topic:%22centralized-cache-db%22 Status: Base functionality is merged Pending: - Devstack patch for defaulting cache_driver to centralized_db - https://review.opendev.org/c/openstack/devstack/+/907110 - Tempest tests for caching images on remote node - https://review.opendev.org/c/openstack/tempest/+/901525 - Grenade patch to change cache-driver to centralized_db on upgrade - https://review.opendev.org/c/openstack/grenade/+/901678 - New tempest job to test centralized db - https://review.opendev.org/c/openstack/glance/+/901429 - New Grenade job to test upgrade scenario - https://review.opendev.org/c/openstack/glance/+/901649 - Make centralized_db driver default in glance - https://review.opendev.org/c/openstack/glance/+/907111 Why miss the deadline: Some useful restructuring during milestone 3 This feature is useful as we just need a single database which reduces the need of maintaining sqlite3 database and also can enhance caching operations by introducing new APIs in future. Kindly consider this feature for the current cycle and assist with reviews and suggestions. Thank you, Abhishek Kekane

3 2

[nova] dry-run migration api
by Pavlo Shchelokovskyy 29 Feb '24

29 Feb '24

Hi all, Recently I've been looking into various load optimizations tooling for OpenStack (like Watcher), and noticed a lacking feature that could make such tooling much more robust and useful. The optimization tooling usually collects some metric about compute hosts and instances that nova may be totally unaware of (e.g. power consumption of a compute node in Watts), and then tries to reshuffle the instances between hypervisors to optimize said metric in some sense. The problem is, the tool has no idea beforehand if nova will actually allow moving this given instance to this given hypervisor. I am talking about resource consumption, resource provider traits, image and aggregate metadata matching, numa placement, server group affinities etc. To know all this for sure, the optimization tool would have to duplicate most of the nova scheduler and good part of placement inside of itself - which is not feasible. This is why AFAIU in Watcher all available strategies mention that they expect "any VM to be migrateable to any hypervisor", which is far from many if not most real life deployments. What I suggest is adding a new API to nova to effectively have a 'migration dry run' - it should return the list of target hosts a given instance may be migrated to, accounting for all the knowledge nova has about the instance and the hypervisors. The list can be already sorted by nova weighers to signal the preferred choice from nova side. AFAIU such a new API would not require any drastic changes in Nova - the most of the code is already there, used during migrations, only that at the last step, instead of choosing the best compute and actually initiating the migration process, the result of filtering and weighing will be returned to the caller in some form. Would there be interest in such an API? If yes, I could start writing and proposing a spec. Best regards, -- Dr. Pavlo Shchelokovskyy Principal Software Engineer Mirantis Inc www.mirantis.com

3 2

Re: Enabling external connectivity to VMs
by Eugen Block 29 Feb '24

29 Feb '24

Please don't drop the list from your response. I'm not very familiar with kolla, but if you're able to ping the instance via floating IP it seems okayish. Maybe you need to set neutron_external_interface to ens192 instead? Someone with more kolla experience will probably correct me here, so don't rely on my response. Zitat von KK CHN <kkchn.in(a)gmail.com>: > Hi Eugen, > > I have followed the > https://docs.openstack.org/kolla-ansible/latest/reference/networking/neutro… > > But mistakenly I have configured ens160 as neurton_external_interface: > "ens160" as the docs says an interface without IP address needed so I > create a vNIC ens160 without IP and used this without knowing What I am > doing..!!!! > > The issue is tenant VMs don't get Internet. also tenant VMs cant ping > base VM(Ubuntu 22.04 IP 10.220.0.51, or 10.176.16.128 .. ) totally > confused. > > > Could you help me to understand what I am doing wrong here ? > Greetings > Krish. > > *For more info what I have done so far : * Please refer to > the following... > > In the Base VM, I created 3 vNICs. > > 1. ens192 with my Org's dhcp LAN IP 10.176.16.128 which has the internet. > 2. ens224 with 10.220.0.51 IP which is a VLAN IP of (10.220.0.0/24) which > is created for testing purposes internally by N/W guy. This doesn't have > the internet.. > > 3. ens160 up active without IP address. ( Wrongly I specified this as the > e neutron_external_interface in globals.yml) > > > > *I have deployed the openstack..Everything up and running .. * > I am able to create Routers, Network and subnets and able to create > instances(all VMs spawning with 10.0.0.0/24 IPs) > > I created the networks(external with subnet 10.220.0.0/24 with > start=10.220.0.30 to end=10.220.0.50) and internal Network(with subnet > named demo-net 10.0.0.0/24 for tenants) > > I am able to associate the VMs with 10.0.0.0/24 IPs to Floating IPs from > 10.220.0.0/24 > > and from my Base(host) VM(Ubuntu22.04 with ens224 10.220.0.51) I am able > to ping the 10.0.0.28 tenant VM IP through the associated floating IPs as > > $ ip netns ( On base (host) VM) dsplays the router > (kolla_ansible_venv3) ubuntu@ubuntu-VM:~$ ip netns > qrouter-ecc6fe39-a733-4f30-bf67-ac42407227f8 (id: 1) > > qdhcp-c29f26ac-3594-4c40-bf20-f2d5ba7d6eea (id: 0) > > > $(kolla_ansible_venv3) ubuntu@ubuntu-VM:~$ sudo ip netns exec > qrouter-ecc6fe39-a733-4f30-bf67-ac42407227f8 ping 10.0.0.28 ( the VM > tenant IP address) > PING 10.0.0.28 (10.0.0.28) 56(84) bytes of data. > 64 bytes from 10.0.0.28: icmp_seq=1 ttl=64 time=0.972 ms > > (kolla_ansible_venv3) ubuntu@ubuntu-VM:~$ sudo ip netns exec > qrouter-ecc6fe39-a733-4f30-bf67-ac42407227f8 ping 10.220.0.44 ( the > Floating IP associated to 10.0.0.28 VM) > PING 10.220.0.44 (10.220.0.44) 56(84) bytes of data. > 64 bytes from 10.220.0.44: icmp_seq=1 ttl=64 time=0.840 ms > 64 bytes from 10.220.0.44: icmp_seq=2 ttl=64 time=0.599 ms > > (kolla_ansible_venv3) ubuntu@ubuntu-VM:~$ sudo ip netns exec > qrouter-ecc6fe39-a733-4f30-bf67-ac42407227f8 ping 10.220.0.33 ( The router > IP through which connects floating ip 10.220.0.44 and then to tenant VM ip > 10.0.0.28 ) > > PING 10.220.0.33 (10.220.0.33) 56(84) bytes of data. > 64 bytes from 10.220.0.33: icmp_seq=1 ttl=64 time=0.038 ms > > *Hence it works somehow. * But ens224 10.220.0.51 doesn't have > internet on the base VM. But only ens192->10.170.16.128 IP has.. > > How can I provide the internet connectivity of ens192 to ens224 Is this > possible or Am I doing some dump here.? What is the other way / best way > to do this .. > I am beginning my journey with OpensStack but stuck here without much > progress.. > > > (kolla_ansible_venv3) ubuntu@ubuntu-VM:~$ grep ^[^#] /etc/kolla/globals.yml > --- > workaround_ansible_issue_8743: yes > config_strategy: "COPY_ALWAYS" > kolla_base_distro: "ubuntu" > openstack_release: "2023.1" > kolla_internal_vip_address: "10.220.0.24" > kolla_external_vip_address: "{{ kolla_internal_vip_address }}" > kolla_container_engine: docker > network_interface: "ens224" > neutron_external_interface: "ens160" > neutron_plugin_agent: "openvswitch" > nova_compute_virt_type: "qemu" > (kolla_ansible_venv3) ubuntu@ubuntu-VM:~$ > > > The following screenshot shown the tenant VM console(tty) where I am able > to ping floating IP(10.220.0.44 and its router ip 10.220.0.33 ) but > neither 10.220.0.51 the base VM ens224 IP nor ens192 10.17.16.128 > > > [image: image.png] > > > > krish > > On Tue, Feb 27, 2024 at 11:09 PM Eugen Block <eblock(a)nde.ag> wrote: > >> Hi, >> >> Check out this page: >> >> >> https://docs.openstack.org/kolla-ansible/latest/reference/networking/neutro… >> >> You need some sort of external network to provide connectivity for >> instances. >> >> Zitat von KK CHN <kkchn.in(a)gmail.com>: >> >> > List, >> > >> > I am a bit confused with the OpenStack Networking configuration for >> > Created virtual machines on a (Kolla-ansible all-in-one on an Ubuntu >> > 22.04 VM ) openstack installation. >> > >> > I am able to create virtual machines through the dashboard as well as >> CLI. >> > I have used the default network/cirros images created from init-runonce >> > script. >> > >> > But Real time, how can I configure these new VMs to communicate with Base >> > VM or external world by ping, ssh or make internet connection etc. >> > >> > Base VM is Ubuntu22.04 - with IPs ens192=>10.170.16.128(with Internet), >> > second interface => ens224 => 10.220.0.51 and ens160 up and running >> > without IP address for neutron_external_interface: >> > >> > All the VMs which I created getting IP addresses in series (10.0.0.X). >> > >> > But How to allocate Internet and make external world communication to >> and >> > from these VMs ? >> > >> > >> > Any hints/directions towards this much appreciated. >> > >> > Greetings, >> > Krish >> > >> > >> > If required more inputs here follows the additional information. >> > >> > (kolla_ansible_venv3) ubuntu@ubuntu-VM:~$ grep ^[^#] >> /etc/kolla/globals.yml >> > --- >> > workaround_ansible_issue_8743: yes >> > config_strategy: "COPY_ALWAYS" >> > kolla_base_distro: "ubuntu" >> > openstack_release: "2023.1" >> > kolla_internal_vip_address: "10.220.0.24" >> > kolla_external_vip_address: "{{ kolla_internal_vip_address }}" >> > kolla_container_engine: docker >> > network_interface: "ens224" >> > neutron_external_interface: "ens160" >> > neutron_plugin_agent: "openvswitch" >> > nova_compute_virt_type: "qemu" >> > (kolla_ansible_venv3) ubuntu@ubuntu-VM:~$ >> > >> > >> > >> > Additional inputs: >> > >> > There are 3 virtual interfaces on the base Ubuntu22.04 Virtual Machine. >> > ens192->10.170.16.128 with internet, ens224->10.220.0.51 , ens160 up >> > without IP >> > >> > 1. First Interface contain IP address from My organizations DHCP lease >> from >> > LAN(10.16.16.0) Which has Internet connectivity. >> > ens192: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP >> group >> > default qlen 1000 link/ether 00:0c:29:33:18:3c brd ff:ff:ff:ff:ff:ff >> > altname enp11s0 >> > inet 10.170.16.128/23 brd 10.170.17.255 scope global dynamic >> noprefixroute >> > ens192 >> > valid_lft 786963sec preferred_lft 786963sec >> > inet6 fe80::cd1a:bc6c:b129:f91f/64 scope link noprefixroute >> > valid_lft forever preferred_lft forever3 >> > >> > >> > 2. Interface I have 10.220.0.51 >> > >> > ens224: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP >> group >> > default qlen 1000 >> > link/ether 00:0c:29:33:18:46 brd ff:ff:ff:ff:ff:ff >> > altname enp19s0 >> > inet 10.220.0.51/24 brd 10.220.0.255 scope global noprefixroute >> ens224 >> > valid_lft forever preferred_lft forever >> > inet 10.220.0.24/32 scope global ens224 >> > valid_lft forever preferred_lft forever >> > inet6 fe80::a8b6:f094:c47:8282/64 scope link noprefixroute >> > valid_lft forever preferred_lft forever >> > >> > 3. ens160 without any IP address which is up and running configured for >> > Kolla neutron_external_interface: "ens160" >> > >> > ens160: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master >> > ovs-system state UP group default qlen 1000 >> > link/ether 00:0c:29:33:18:32 brd ff:ff:ff:ff:ff:ff >> > altname enp3s0 >> > >> > >> > >> > 1. What networks need to be created additionally ? >> > 2. Bridges and bonds required here or not ? >> > >> > 3. To enable these New VMs to talk to external world( ssh, ping, internet >> > connection to all these VMs ) what all the steps need to be performed or >> I >> > left out ? >> >> >> >>

1 0

[oslo][release][requirement] FFE request for oslo.context
by Takashi Kajinami 29 Feb '24

29 Feb '24

Hello, I'd like to request an exception to merge a change[1] to oslo.context and create a new stable/2024.1 release. This change is required to fix the problem which is current blocking us from bumping oslo.messaging to the final 2024.2 release version (14.7.0)[2]. The change is small and has quite limited impact. I've tested the modification locally and confirmed it fixes the heat unit tests. [1] https://review.opendev.org/c/openstack/oslo.context/+/910153 [2] https://review.opendev.org/c/openstack/requirements/+/909906 -- Takashi Kajinami irc: tkajinam github: https://github.com/kajinamit launchpad: https://launchpad.net/~kajinamit

3 4

[magnum] Dropping default Cluster API driver
by Mohammed Naser 29 Feb '24

29 Feb '24

Hi everyone, It seems that based on a recent post that I saw on the Twitter-sphere[1], it seems that the Magnum team has decided to move forward with setting a default driver for the Cluster API. I don't agree with this. Unfortunately, we don't have much recordings of our PTG conversations, and since the notes on the PTG are pretty light[2], I don't see any details of that. I don't see why we should be merging a native Cluster API driver and not allowing the operators and deployment tools decide which one they want to support. Personally, I think that the Helm driver should be built in a separate repository and then installed by the user as a Python package once they understand what are the backends and their options, as opposed to shipping one out of the box with far less features. We already have successful users which are using our implementation in production that have also posted blogs and shared their experience, we'd be doing them a disservice by now announcing a 'native' built-in driver. Can the decision be changed so that there is no built-in driver, and you must decide to install one yourself? Also, I would be really happy to hear feedback from users of the driver for their comments here. Thanks, Mohmamed [1]: https://www.stackhpc.com/magnum-clusterapi.html [2]: https://etherpad.opendev.org/p/r.5b94a5a9dbf4e3bf8202b5e57cb93770

19 34

[ptl][election][trove] PTL candidacy for 2024.2
by chunyang wu 29 Feb '24

29 Feb '24

Hello everyone: I would like to announce my candidacy for PTL of the Trove project for the 2024.2 cycle. For the Dalmatian cycle, i'd like to focus on the following: * review the coming patches * Add more tempest tests * Add CI tests for the latest datastore(mysql, mariadb, postgresql) version * improve docs thanks wu.chunyang

2 2

[all][elections][tc] TC Election Campaigning Kickoff
by Ian Y. Choi 29 Feb '24

29 Feb '24

Developers, The TC Election Campaigning Period has now started[1]. During the next couple days, you are all encouraged to ask the candidates questions about their platforms[2], opinions on OpenStack, community governance, and anything else that will help you to better determine how you will vote. This is the time to raise any issues you wish the future TC to consider, and to evaluate the opinions of the nominees prior to their election. Candidates, Each of you has posted a platform[2], and announced your nomination to the developers. From this point, you are encouraged to ask each other questions about the posted platforms, and begin discussion of any points that you feel are particularly important during the next cycle. While you are not yet TC members, your voices and opinions about the issues raised in your platforms and questions raised by the wider community will help ensure that the future TC has the widest possible input on the matters of community concern, and the electorate has the best information to determine the ideal TC composition to address these and other issues that may arise. [1] https://governance.openstack.org/election/ [2] https://opendev.org/openstack/election/src/branch/master/candidates/2024.2/…

1 0

[all][elections][ptl][tc] Combined PTL/TC 2024.2 cycle Election Nominations End
by Ian Y. Choi 29 Feb '24

29 Feb '24

The PTL and TC Nomination period is now over. The official candidate lists for PTLs [0] and TC seats [1] are available on the election website. -- PTL Election Details -- There are 11 projects without candidates, so according to this resolution[2], the TC will have to decide how the following projects will proceed: Ec2_Api, Freezer, Kuryr, Murano, OpenStack_Charms, Sahara, Senlin, Skyline, Solum, Trove, Watcher There are 0 projects that will have elections: . -- TC Election Details -- The official candidate list is available on the election website[1]. Now begins the campaigning period where candidates and electorate may debate their statements. Polling will start Mar 06, 2024 23:45 UTC. Thank you, [0] https://governance.openstack.org/election/#2024.2-ptl-candidates [1] https://governance.openstack.org/election/#2024.2-tc-candidates [2] https://governance.openstack.org/resolutions/20141128-elections-process-for…

1 0

Ansible performance
by Gk Gk 29 Feb '24

29 Feb '24

Hi, Is there any way to speedup the playbooks execution of openstack ansible ? Can we remove gather facts for any tasks without affecting the installation ?

5 4

Ansible variables
by Gk Gk 29 Feb '24

29 Feb '24

Hi, We have an OSA setup. During a service playbook, for example, say rabbitmq, which task or play is responsible for creating it's haproxy configuration ? I mean, where is the code in openstack ansible to say to gather the values from user_variables file for that particular service or gather it from conf.d ? For instance, for rabbitmq service, where is the code which says to get the rabbitmq management port for the backend to be 15671 ? I mean where is the source code for pulling it from user_variables file and also which variable from it ?

3 2

[ptl][election][barbican] PTL Candidacy for 2024.2
by Grzegorz Grasza 28 Feb '24

28 Feb '24

Hello, I would like to propose my candidacy for Barbican PTL in the 2024.2 cycle. I've been the PTL since Antelope and I would like to continue to contribute in this role. As in the past cycles, I will continue to focus on Barbican maintenance and stability. Thanks you for your consideration, Grzegorz Grasza (xek)

1 0

[election][cloudkitty] PTL candidacy for the 2024.2 release cycle
by Rafael Weingärtner 28 Feb '24

28 Feb '24

Hi all, I would like to self-nominate for the role of PTL of CloudKitty for the 2024.2 release cycle. I have been PTL since the Victoria cycle and I am willing to continue in this role. I will keep working with existing contributors to maintain CloudKitty for their use cases and encourage the addition of new functionalities. I have opened the patch with my candidacy: https://review.opendev.org/c/openstack/election/+/910519 -- Rafael Weingärtner

1 0

[ptl][election][keystone] PTL Candidacy for 2024.2
by Dave Wilde 28 Feb '24

28 Feb '24

Hello, I would like to continue my tenure as PTL of Keystone. Over the past cycle we have made some great progress especially around the cadence in getting patches reviewed and merged. I would like to focus this next cycle on seeing that [1] is implemented as well as some much needed backlog cleanup. I would also, finally, like to get a "known-issues" section added to the documentation as well as ensuring that our documentation is up to date. Thanks for your time and support and I'm looking forward to another great cycle. [1]: https://specs.openstack.org/openstack/keystone-specs/specs/keystone/2024.1/… /Dave

1 0