March 2024 - openstack-discuss - lists.openstack.org

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

29 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

[oslo] python-consul2 is unmaintained
by Takashi Kajinami 21 Apr '25

21 Apr '25

Hello, I recently noticed that python-consul2 library[1], which is used by the consul coordination driver in tooz, hasn't been updated for 3+ years. Looking at issues in the project, there is an indication that the library is not compatible with ACL API in consul >= 1.11[2]. There is another fork created[3] and this includes fixes to support new API endpoints. Although the driver in tooz does not directly use the feature, I think it's better to discuss our plan to mitigate risks caused by the unmaintained library. As far as I can think of, there are three options now 1. Deprecate consul driver and remove it 2. Keep using python-consul2 now. At least basic functionality is proven to work by our functional tests (Note that the tests do not cover all configuration patterns) 3. Replace python-consul2 by py-consul Before we start the overall discussions I'd like to ask a few questions to the wider audience, as our inputs. - Is anyone using the consul coordination driver now ? - Does anyone have experience with python-consul2 and/or py-consul ? Note that this discussion affects the http messaging driver[4] currently proposed, because it also requires client library to communicate with Consul. Actually I noticed the situation when I noticed that the requirement check job is failing because the library is not part of global requirements list... Thank you, Takashi Kajinami [1] https://github.com/poppyred/python-consul2 [2] https://github.com/poppyred/python-consul2/issues/42 [3] https://github.com/criteo-forks/py-consul [4] https://review.opendev.org/c/openstack/oslo.messaging/+/912499 -- Takashi Kajinami irc: tkajinam github: https://github.com/kajinamit launchpad: https://launchpad.net/~kajinamit

2 3

[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 19 Jan '25

19 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 23 Dec '24

23 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 24 Nov '24

24 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) 06 Aug '24

06 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 16 May '24

16 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

[largescale-sig] Next meeting: March 27, 9utc
by Thierry Carrez 24 Apr '24

24 Apr '24

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

2 3

[oslo][release][requirements] broken watch_log_file depends on unmaintained pyinotify
by Takashi Kajinami 19 Apr '24

19 Apr '24

Hello, # This is mainly a oslo topic but I'm adding release team and requirements # team because we likely need new stable/2024.1 release of oslo.log. I looked into an old oslo.log bug[1] during the weekend and noticed that the watch_log_file option in oslo.log has been broken for some time. Looking into the problem further, I leaned that pyinotify[1] library, which is used in this feature, hasn't been updated for 9 years (!!). What is worse, pyinotify dependes on asynccore which has been removed from Python 3.12 and I'm skeptical that we can fix pyinotify to make it work with Python 3.12. There was an old discussion to replace pyinotify by inorify[3] but itnofiy hasn't been updated for 4 years and looks also unmaintained. I think the only option we have here is deprecating the functionality in 2024.1 so that we can remove it in early phase of 2024.2. Because we are quite close to 2024.1 GA, we have to make the decision early. I've already proposed the change for deprecation[4]. If you have any concerns then please reply to this email or leave your comments in the review. Thank you, Takashi [1] https://bugs.launchpad.net/oslo.log/+bug/1740111 [2] https://github.com/seb-m/pyinotify [3] https://github.com/dsoprea/PyInotify [4] https://review.opendev.org/c/openstack/oslo.log/+/914788 -- Takashi Kajinami irc: tkajinam github: https://github.com/kajinamit launchpad: https://launchpad.net/~kajinamit

3 5

[designate] Support for DNSSEC // Bump in the wire signer via BIND9 or Knot
by Christian Rohmann 18 Apr '24

18 Apr '24

Hello, I was wondering is anybody knew about the current state of DNSSEC signing for Designate-managed zones. Since Designate MDNS serves as primary they actually should do the signing / provide already signed zones via zone transfers. Adding support for DNSSEC this was last discussed for Kilo [1], but that spec was never finished, DNSSEC support never implemented. One approach to do this is using a bump in the wire signer [2][3][4] and have an intermediate BIND9 or Knot server doing the signing. Has anybody implemented something of this kind? If so, how do your users receive their initial DS / DNSKEY for the parent zone? Regards Christian [1] https://review.opendev.org/c/openstack/designate-specs/+/132571 [2] https://bind9.readthedocs.io/en/latest/dnssec-guide.html#bump-in-the-wire-s… [3] https://jpmens.net/2023/07/22/adieu-opendnssec-bienvenido-knot-dns/ [4] https://labs.ripe.net/author/anandb/dnssec-signer-migration/

4 7

[heat] Parametrization of Neutron trunk subports scaling down
by Lajos Katona 17 Apr '24

17 Apr '24

Hi, With Hot templates we run into a scaling issue with Neutron trunk subports. The task is to create Neutron trunks with "vlan_count" number of subports, and with stack update be able to add or remove subports of the created trunk. We tried with resourceGroup, and that works well if we increase the number of subports. The problem comes with decrease, as with resourceGroups I can't (my lack of knowledge) tell heat_engine that first update the trunk and remove the subport and after that delete the port. And Neutron API gives back conflict as the port which heat_engine tries to delete is still used by the trunk. Do you know a way to accomplish such an operation with Hot templates? Thanks in advance for the help. Best wishes Lajos Katona (lajoskatona)

2 4

[kolla-ansible][Antelope][Heat] Heat UpdateWaitConditionHandle Issues
by Devin Patterson 16 Apr '24

16 Apr '24

Hello, We are creating a workflow to use Heat auto-scaling groups with wait conditions. The ideal goal would be to have the wait condition clear and require another signal when the Heat stack is updated. Trying to use the resource OS::Heat::UpdateWaitConditionHandle instead of OS::Heat::WaitConditionHandle. This works during initial creation, but when I udpdate the stack with a new configuration, I get the following error. UpdateWaitConditionHandle.update() got an unexpected keyword argument 'new_template_id' Any ideas on how to use wait conditions during stack updates or to fix the above error. Thanks in advance. Devin

2 2

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

10 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

[kolla-ansible][horizon]Create instance default parameters
by Franck VEDEL 10 Apr '24

10 Apr '24

Hi, With horizon, is it possible de have this default parameter when you create an instance: in source, create a new volume: « No ». And.. if it’s possible, how configure this with kolla-ansible ? Thank’s for your help. Franck

2 4

Nova filter based on VM metadata?
by Ken D'Ambrosio 08 Apr '24

08 Apr '24

Hey, all. I'm looking for a way to to filter to a particular aggregate based on arbitrary VM metadata. (E.g., maybe FACTER facts from Puppet that we pass to the VM as metadata.) Could someone point me toward documentation that might outline how to accomplish that? As I see it, there's really one thing I need to understand -- the rest I can probably glean from extant filters: how (or if) a filter could access a given VM's metadata from the API creation request (if that's even possible). Thanks! -Ken

3 3

[openstack-ansible] : Ussuri minor version update.
by keshav bareja 04 Apr '24

04 Apr '24

Hi Team I am planning to update my environment from the current ussuri minor version to the latest minor version available for the Ussuri. I found the procedure below. https://docs.openstack.org/openstack-ansible/ussuri/admin/upgrades/minor-up… I have some queries on this: 1. How to find the current minor release version of the Ussuri deployed on my environment? Is there any command or way that can help? 2. What is the latest minor version available for Ussuri? In the Ussuri release notes page I could see 2.10, can someone please confirm if 2.10 is the latest version? 3. Also I need to know the bug fixes between my current release to the latest minor ussuri release. 4. Can someone confirm what all pre-requisite I need to take care of before going with the update. 5. Anyone having experience with such minor updates , Please share precaution and recommendations, Ussuri Series Release Notes <https://docs.openstack.org/releasenotes/openstack-ansible/victoria.html> <https://docs.openstack.org/releasenotes/openstack-ansible/train.html> <https://bugs.launchpad.net/openstack-ansible/+filebug?field.title=Ussuri%20…> 21.2.10 <https://docs.openstack.org/releasenotes/openstack-ansible/ussuri.html#relno…>Security Issues <https://docs.openstack.org/releasenotes/openstack-ansible/ussuri.html#secur…> - This release eliminates following security issues: - OSSA-2021-005: https://security.openstack.org/ossa/OSSA-2021-005.html - OSSA-2021-006: https://security.openstack.org/ossa/OSSA-2021-006.html

2 5

[freezer] Project status update
by Dmitriy Rabotyagov 02 Apr '24

02 Apr '24

Hey there! In a previous email thread [1] an interest toward reviving the Freezer project was raised. As a result of the thread we've organized a first sync meeting with interested parties. It was a quite productive discussion and we came up with a couple of action points as a result of it. You can find more information in the etherpad [2] Among everything, one of the most important parts for now, is to step into the PTL role or move a project to a distributed leadership. At the moment the project is leadless, since there was no candidacy submitted for this election. We also agreed to schedule the next meeting on April 2 from 16-00 till 17-00 UTC and discuss progress and blockers which were found. I'm attaching an invitation to the meeting to the email. If it doesn't work, you can join on the mentioned time via the link [3] Hope to see you there and thanks for everyone who participated and stepped in for the project! [1] https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… [2] https://etherpad.opendev.org/p/freezer-status [3] https://meet.google.com/ckc-gevi-epe

1 2

[neutron] Proposing Ihar Hrachyshka as neutron core reviewer
by Brian Haley 02 Apr '24

02 Apr '24

Hello Neutrinos, I would like to nominate Ihar Hrachyshka for Neutron core reviewer (again). He's been leaving some very useful comments lately, moved-up in the reviewer stats over the past 90 days [0], and has a lot of OVN knowledge. Ihar was previously a core reviewer from 2015-2018 so most might already know him. I think he'd be a great re-addition to the team. Please vote with a +1/-1. [0] https://www.stackalytics.io/report/contribution?module=neutron-group&projec… Thanks, -Brian, Neutron PTL

8 8

[qa][ptg] Virtual Dalmatian vPTG Planning
by Martin Kopec 02 Apr '24

02 Apr '24

Hello everyone, here is [1] our etherpad for the Dalmatian/2024.2 virtual PTG. Please, add your topics there if there is anything you would like to discuss / propose ... You can also vote for time slots for our sessions so that they fit your schedule at [2]. We will most likely go with 1-hour slot per day, as they usually fit easier into everyone's schedule. The number of slots will depend on the number of topics proposed in [1]. [1] https://etherpad.opendev.org/p/apr2024-ptg-qa [2] https://framadate.org/pklG59pH47w6ZdJI Thanks, -- Martin Kopec Principal Software Quality Engineer Red Hat EMEA IM: kopecmartin

1 1

openstacksdk, ironicclient, os-fault: Please replace python3-appdirs dependency with platformdirs
by Thomas Goirand 01 Apr '24

01 Apr '24

Hi, 3 bugs have been opened in Debian to get appdirs replaced by platformdirs: https://bugs.debian.org/1067995 https://bugs.debian.org/1067999 https://bugs.debian.org/1068000 Here's the bug report content: > python3-appdirs is dead upstream[1] and its Debian maintainer has > indicated that it should not be included in trixie[2]. A recommended > replacement is python3-platformdirs[3], which is a fork of appdirs > with a very similar API. > > Please migrate from appdirs to platformdirs or some other replacement, > so that appdirs can be removed. > > Thanks, > smcv > > [1] https://github.com/ActiveState/appdirs/commit/8734277956c1df3b85385e6b308e9… > [2] https://bugs.debian.org/1060427 >[3] https://pypi.org/project/platformdirs/ Can we do that in upstream OpenStack, during the Dalmatian cycle? Cheers, Thomas Goirand (zigo)

3 3

[zun][neutron] cannot start container after stopping it
by James Leong 30 Mar '24

30 Mar '24

Hi all, I am having issues with the network being attached to a container. Here's my scenario: when I first created a container via the dashboard, I had a successful running container; then later, I attached a floating IP to it, and when I tried to stop and start the container, I got the following error message. Error response from daemon: Cannot restart container 780688e20528: failed to create endpoint zun-720f2207-86f8-4845-9434-b8f21aeafeb8 on network 8475928f-e65a-4e72-9b15-7de43a5b8853: NetworkDriver.CreateEndpoint: Virtual device creation failed. Any suggestions or recommendations are greatly appreciated. Best, James

2 1

[kolla] weekly meeting on 3rd April 2024 is cancelled
by Michał Nasiadka 30 Mar '24

30 Mar '24

Hello, I’m cancelling next weekly meeting for Kolla (on 3rd April 2024) due to absence of key people (including me). Let’s speak on the PTG sessions the following week. Best regards, Michał Nasiadka mnasiadka(a)gmail.com

1 0

pdb in uwsgi
by Gk Gk 30 Mar '24

30 Mar '24

Hi, I am trying to insert pdb.set_trace() in the file " https://opendev.org/openstack/placement/src/branch/master/placement/objects…" for debugging purposes. But when I manually start the placement service using this command "/openstack/venvs/uwsgi-27.3.0-python3/bin/uwsgi --autoload --ini /etc/uwsgi/placement-api.ini --honour-stdin", it is running as normal but not giving the pdb prompt when launching a nova boot command elsewhere. Is this a uwsgi pdb bug ? Thanks Y.G

2 2

Re: Please Help To Setup Bumblebee VDI project based on DevStack
by Matthew Swigart 29 Mar '24

29 Mar '24

Hi Manuel, Thank you for your kind response. And yes, I fixed my previous issue and was able to access the Django Admin site like you shared a screenshot. Thank you for sharing that.🥰 Also, I contacted Andy and I'm in the same boat with him in the Matrix Element chat app. I've been contacting your former Freibug Univerisity colleagues from several months ago through Matrix Element room, Dirk, Michael Scherle, etc. They are really supportive. 👍 I'm also planning to collaborate on the project: https://github.com/OpenSourceVDI/osvdi . So this is the pre-development step for me So at least I want to try to test this bumblebee VDI based on DevStack on my local first, but Andy has also never tested the bumblebee on Devstack yet. I'm a bit sorry to Freiburg colleagues since they are already experienced in this step and they are forwarding to develop VDI that can support 3D rendering so I don't want to take time from them and want to support them as soon as possible after I pass through this step. For now, I stuck the one issue to create VDI. The issue is when I creating VDI, I got this issue. [image: image.png] I guess there is a problem with setting up the security group. I ran the *setup-openstack.sh* script by setting *CIDR=192.168.174.0/24 <http://192.168.174.0/24>* and setting the *OS_SECGROUPS=bumblebee_desktops* . I'm not sure I did correctly. Could you please let me know *what the would be CIDR value in the setup-openstack.sh and OS_SECGROUPS in the env file*? Let me attach some of my current configuration screenshots for references. Networks: [image: image.png] Security Groups: [image: image.png] bumblebee-desktops security group detail: [image: image.png] Security Group and keypair values: [image: image.png] bumblebee-desktop Security Group detail: [image: image.png] Env file: [image: image.png] I'd appreciate it if you could kindly reply to my email again. Please keep in touch. Much appreciated. Matthew On Thu, Mar 28, 2024 at 5:58 AM Manuel Bentele < development(a)manuel-bentele.de> wrote: > Hi Matthew, > > I fixed the above issue. The issue was happening because when trying to > create an instance through the nova client, input > parameters(security_groups and key_name) were empty. > > Nice to hear that you were able to solve the problem. At some code > locations, Bumblebee could still have better error handling ;) > > I quickly set up a fresh instance of Bumblebee and can't reproduce your > Django admin site access problem. If I use the default settings from the > Docker compose .env file and log in with the admin account, an 'Admin' > button appears in the menu bar: > > If you then click on the 'Admin' button, the Django admin site will load: > > There you can then graphically edit the corresponding objects from the > Bumblebee data model. For example, here is the mask for changing the > Ubuntu Jammy desktop type if you click on 'Desktop types' and then 'jammy': > > You can now do the same for the volumes or other objects. Why access to > the Django admin site doesn't work for you is a mystery to me. The same > also applies to the security groups. So far I have only ever assigned one > security group. Perhaps there is still an error due to a bug in the > Bumblebee logic if several security groups are specified. > > Anyway, I am also fully available on the weekends. I joined in OpenStack > VDI room Matrix element. (https://matrix.to/#/#opensource-vdi:matrix.org) > So hopefully we can discuss more detail through that room. > > Interesting, I haven't heard of that yet. Oh I see that my former > colleagues are also active there. I started this project back then: > https://github.com/OpenSourceVDI/osvdi. And now it seems that the project > is making visible progress. > > In the meantime, I no longer have anything to do with the VDI topic due to > another job. I just saw your question on the mailing list and thought I > could help. I have dealt with Bumblebee in the past and was also in > contact with Andy Botting. He is one of the main developers of Bumblebee and > reads the OpenStack mailing list from time to time. He is always happy to > receive further support for Bumblebee from the community and their > feedback. If you have specific questions, you can also contact him > directly: Andy Botting <andy(a)andybotting.com>. Nevertheless, you can also > ask my former colleagues from the University of Freiburg in the Matrix > room. I put their email addresses in the CC. They can help you too. > > Regards, > Manuel > > On 26.03.24 07:37, Matthew Swigart wrote: > > Hi Manuel, > > I fixed the above issue. The issue was happening because when trying to > create an instance through the nova client, input > parameters(security_groups and key_name) were empty. So I created a new > keypair and added keyname to env, And then I got the security group list by > running the "openstack security group list" command. > [image: image.png] > So I set "bumblebee-desktops" to OS_SECGROUPS in the env file, but I got > this issue -Unable to find security_group with name or id > 'bumblebee-desktops' > [image: image.png] > Here is my current env file screenshot: > [image: image.png] > Do you have any idea how to set the correct OS_SECGROUPS value in the env > file? If you already have the correct env file, then please let me know. > > Thank you, > Matthew > > On Mon, Mar 25, 2024 at 9:45 PM Matthew Swigart < > matthew.swigart35(a)gmail.com> wrote: > >> Hello Manuel, >> >> Appreciate your kind response. To fix the bad UUID, I updated the flavor >> field type from UUID to String instead in the Volume class from model.py. >> Also I created migration for this. So I was able to fix the above issue but >> after that changes, I got the new error. >> Let me attach the screenshot. >> >> Anyway, I am also fully available on the weekends. I joined in OpenStack >> VDI room Matrix element. (https://matrix.to/#/#opensource-vdi:matrix.org >> ) >> So hopefully we can discuss more detail through that room. >> >> Regards, >> Matthew >> >> On Mon, Mar 25, 2024 at 6:00 PM Manuel Bentele < >> development(a)manuel-bentele.de> wrote: >> >>> Hi Matthew, >>> >>> I'm glad that my mail was helpful to you. >>> >>> [...] I tried debugging the value and desktop_type.default_flavor.id >>> value is 2 [...] >>> >>> This seems to be where the error lies. A decimal value is set, but it >>> is not a valid UUID. >>> >>> [...] I tried checking the admin URL (/rcsadmin) but I can't see any >>> link to access DB records.) [...] >>> >>> You are already on the right track. It might be the case that the user >>> does not yet have the appropriate flags in Keycloak to be able to access >>> it. You can double check whether the required attribute "is_staff" is >>> set as stated in the Django documentation (see [3]). This attribute is >>> automatically set in Bumblebee if a user is already assigned the "staff" >>> role in Keycloak. Maybe there is something wrong in the initial setup? >>> >>> Please let me know your discoveries. I don't have much time at the >>> moment, but towards the end of the week I can set up a fresh instance >>> myself and see if access to the Django admin page still works. >>> >>> [3] https://docs.djangoproject.com/en/5.0/ref/contrib/admin/#overview >>> >>> Regards, >>> Manuel >>> >>> On 3/25/24 04:36, Matthew Swigart wrote: >>> >>> Hi Manuel, thank you for your helpful email. >>> >>> Yes, you are correct, so there is an issue when creating a record in DB >>> from vm_manager>vm_functions>create_vm.py>create_volume>Line 122 [1] (I >>> tried debugging the value and desktop_type.default_flavor.id value is >>> 2) and vm_manager>models.py>Volume class Line 138 [2] >>> >>> Could you please let me know how to fix the issue in more detail? >>> >>> And you said, I can access DB records through the Django admin site, >>> could you please let me know how to do it? (I tried checking the admin URL >>> (/rcsadmin) but I can't see any link to access DB records.) >>> >>> [1] >>> https://github.com/NeCTAR-RC/bumblebee/blob/2201540ba50af98838d9285d4659b93… >>> [2] >>> https://github.com/NeCTAR-RC/bumblebee/blob/2201540ba50af98838d9285d4659b93… >>> >>> Regards, >>> Matthew >>> >>> >>> >>> On Sun, Mar 24, 2024 at 2:34 PM Manuel Bentele < >>> development(a)manuel-bentele.de> wrote: >>> >>>> Hi Matthew, >>>> >>>> It looks like a UUID is missing or corrupted in the Django data model >>>> of Bumblebee while creating a volume record for a new VM. >>>> >>>> If we take a look at the model of a Bumblebee volume, we notice that a >>>> valid UUID for the flavor field is required (see [1]). During the VM >>>> creation, a new volume record is created where the volume's flavor field is >>>> set to the resolved UUID of the default flavor from a desktop type (see >>>> [2]). Setting an invalid flavor UUID could be the cause here. >>>> >>>> When setting up bumblebee, did you specify valid flavor names (existing >>>> ones from OpenStack) for all desktop types? >>>> >>>> To check the volume records in the database and adjust them if >>>> necessary, you can simply use the Django admin site. There you can view the >>>> entire data model of Bumblebee and all stored records graphically. >>>> >>>> [1] >>>> https://github.com/NeCTAR-RC/bumblebee/blob/2201540ba50af98838d9285d4659b93… >>>> [2] >>>> https://github.com/NeCTAR-RC/bumblebee/blob/2201540ba50af98838d9285d4659b93… >>>> >>>> Best regards, >>>> Manuel >>>> >>>> On 3/24/24 04:29, Matthew Swigart wrote: >>>> >>>> Hello, >>>> >>>> I'm trying to install the VDI project on my Ubuntu 22.04 LTS Desktop >>>> VMware workstation. >>>> So I chose Bumblebee(https://github.com/NeCTAR-RC/bumblebee) and went >>>> through several steps like configuring the devstack, installing docker, and >>>> Bumblebee project. >>>> >>>> And then, I tried to create a virtual desktop from Bumblebee and I got >>>> the below error: >>>> >>>> ValueError: badly formed hexadecimal UUID string >>>> >>>> Attached error screenshot: >>>> >>>> [image: image.png] >>>> >>>> Anybody has already experienced a similar issue or does anybody have >>>> any idea to solve this problem? Then please help me. >>>> >>>> Looking forward to hearing from you. >>>> >>>> Much appreciated. >>>> Matthew >>>> >>>>

2 1

keystone-manage db_sync problem
by aldavx＠gmail.com 29 Mar '24

29 Mar '24

Hi I'm trying migrate a keystone installation from stein to train and when I'm running : keystone-manage db_sync --check I see the following errors : 2024-03-29 10:48:08.193 469 WARNING py.warnings [-] /usr/lib/python3/dist-packages/sqlalchemy/dialects/mysql/reflection.py:62: SAWarning: Unknown schema content: ' "repository_id" varchar(250) NOT NULL,' util.warn("Unknown schema content: %r" % line) 2024-03-29 10:48:08.194 469 WARNING py.warnings [-] /usr/lib/python3/dist-packages/sqlalchemy/dialects/mysql/reflection.py:62: SAWarning: Unknown schema content: ' "repository_path" text DEFAULT NULL,' util.warn("Unknown schema content: %r" % line) 2024-03-29 10:48:08.194 469 WARNING py.warnings [-] /usr/lib/python3/dist-packages/sqlalchemy/dialects/mysql/reflection.py:62: SAWarning: Unknown schema content: ' "version" int(11) DEFAULT NULL,' util.warn("Unknown schema content: %r" % line) 2024-03-29 10:48:08.197 469 WARNING py.warnings [-] /usr/lib/python3/dist-packages/sqlalchemy/dialects/mysql/reflection.py:62: SAWarning: Unknown schema content: ' "id" int(11) NOT NULL AUTO_INCREMENT,' util.warn("Unknown schema content: %r" % line) : migrate.exceptions.DatabaseNotControlledError: migrate_version 2024-03-29 10:48:08.199 469 WARNING py.warnings [-] /usr/lib/python3/dist-packages/sqlalchemy/dialects/mysql/reflection.py:62: SAWarning: Unknown schema content: ' "service" varchar(64) DEFAULT NULL,' util.warn("Unknown schema content: %r" % line) : migrate.exceptions.DatabaseNotControlledError: migrate_version 2024-03-29 10:48:08.199 469 WARNING py.warnings [-] /usr/lib/python3/dist-packages/sqlalchemy/dialects/mysql/reflection.py:62: SAWarning: Unknown schema content: ' "path" varchar(128) DEFAULT NULL,' util.warn("Unknown schema content: %r" % line) : migrate.exceptions.DatabaseNotControlledError: migrate_version 2024-03-29 10:48:08.200 469 WARNING py.warnings [-] /usr/lib/python3/dist-packages/sqlalchemy/dialects/mysql/reflection.py:62: SAWarning: Unknown schema content: ' "method" varchar(16) DEFAULT NULL,' util.warn("Unknown schema content: %r" % line) : migrate.exceptions.DatabaseNotControlledError: migrate_version 2024-03-29 10:48:08.201 469 CRITICAL keystone [-] Unhandled error: sqlalchemy.exc.NoSuchTableError: access_rule 2024-03-29 10:48:08.201 469 ERROR keystone Traceback (most recent call last): 2024-03-29 10:48:08.201 469 ERROR keystone File "/usr/lib/python3/dist-packages/migrate/versioning/schema.py", line 45, in load 2024-03-29 10:48:08.201 469 ERROR keystone self.table = Table(tname, self.meta, autoload=True) 2024-03-29 10:48:08.201 469 ERROR keystone File "/usr/lib/python3/dist-packages/sqlalchemy/sql/schema.py", line 469, in __new__ 2024-03-29 10:48:08.201 469 ERROR keystone metadata._remove_table(name, schema) 2024-03-29 10:48:08.201 469 ERROR keystone File "/usr/lib/python3/dist-packages/sqlalchemy/util/langhelpers.py", line 67, in __exit__ 2024-03-29 10:48:08.201 469 ERROR keystone compat.reraise(exc_type, exc_value, exc_tb) 2024-03-29 10:48:08.201 469 ERROR keystone File "/usr/lib/python3/dist-packages/sqlalchemy/util/compat.py", line 277, in reraise 2024-03-29 10:48:08.201 469 ERROR keystone raise value 2024-03-29 10:48:08.201 469 ERROR keystone File "/usr/lib/python3/dist-packages/sqlalchemy/sql/schema.py", line 464, in __new__ 2024-03-29 10:48:08.201 469 ERROR keystone table._init(name, metadata, *args, **kw) 2024-03-29 10:48:08.201 469 ERROR keystone File "/usr/lib/python3/dist-packages/sqlalchemy/sql/schema.py", line 552, in _init 2024-03-29 10:48:08.201 469 ERROR keystone metadata, autoload_with, include_columns, _extend_on=_extend_on 2024-03-29 10:48:08.201 469 ERROR keystone File "/usr/lib/python3/dist-packages/sqlalchemy/sql/schema.py", line 590, in _autoload 2024-03-29 10:48:08.201 469 ERROR keystone _extend_on=_extend_on, 2024-03-29 10:48:08.201 469 ERROR keystone File "/usr/lib/python3/dist-packages/sqlalchemy/engine/base.py", line 2125, in run_callable 2024-03-29 10:48:08.201 469 ERROR keystone return conn.run_callable(callable_, *args, **kwargs) 2024-03-29 10:48:08.201 469 ERROR keystone File "/usr/lib/python3/dist-packages/sqlalchemy/engine/base.py", line 1596, in run_callable 2024-03-29 10:48:08.201 469 ERROR keystone return callable_(self, *args, **kwargs) 2024-03-29 10:48:08.201 469 ERROR keystone File "/usr/lib/python3/dist-packages/sqlalchemy/engine/default.py", line 415, in reflecttable 2024-03-29 10:48:08.201 469 ERROR keystone table, include_columns, exclude_columns, **opts 2024-03-29 10:48:08.201 469 ERROR keystone File "/usr/lib/python3/dist-packages/sqlalchemy/engine/reflection.py", line 639, in reflecttable 2024-03-29 10:48:08.201 469 ERROR keystone raise exc.NoSuchTableError(table.name) 2024-03-29 10:48:08.201 469 ERROR keystone sqlalchemy.exc.NoSuchTableError: migrate_version 2024-03-29 10:48:08.201 469 ERROR keystone 2024-03-29 10:48:08.201 469 ERROR keystone During handling of the above exception, another exception occurred: 2024-03-29 10:48:08.201 469 ERROR keystone 2024-03-29 10:48:08.201 469 ERROR keystone Traceback (most recent call last): 2024-03-29 10:48:08.201 469 ERROR keystone File "/usr/lib/python3/dist-packages/oslo_db/sqlalchemy/migration.py", line 128, in db_version 2024-03-29 10:48:08.201 469 ERROR keystone return versioning_api.db_version(engine, repository) 2024-03-29 10:48:08.201 469 ERROR keystone File "<decorator-gen-6>", line 2, in db_version 2024-03-29 10:48:08.201 469 ERROR keystone File "/usr/lib/python3/dist-packages/migrate/versioning/util/__init__.py", line 167, in with_engine 2024-03-29 10:48:08.201 469 ERROR keystone return f(*a, **kw) 2024-03-29 10:48:08.201 469 ERROR keystone File "/usr/lib/python3/dist-packages/migrate/versioning/api.py", line 148, in db_version 2024-03-29 10:48:08.201 469 ERROR keystone schema = ControlledSchema(engine, repository) 2024-03-29 10:48:08.201 469 ERROR keystone File "/usr/lib/python3/dist-packages/migrate/versioning/schema.py", line 33, in __init__ 2024-03-29 10:48:08.201 469 ERROR keystone self.load() 2024-03-29 10:48:08.201 469 ERROR keystone File "/usr/lib/python3/dist-packages/migrate/versioning/schema.py", line 54, in load 2024-03-29 10:48:08.201 469 ERROR keystone exceptions.DatabaseNotControlledError(str(exc)), tb) 2024-03-29 10:48:08.201 469 ERROR keystone File "/usr/lib/python3/dist-packages/six.py", line 692, in reraise 2024-03-29 10:48:08.201 469 ERROR keystone raise value.with_traceback(tb) 2024-03-29 10:48:08.201 469 ERROR keystone File "/usr/lib/python3/dist-packages/migrate/versioning/schema.py", line 45, in load 2024-03-29 10:48:08.201 469 ERROR keystone self.table = Table(tname, self.meta, autoload=True) 2024-03-29 10:48:08.201 469 ERROR keystone File "/usr/lib/python3/dist-packages/sqlalchemy/sql/schema.py", line 469, in __new__ 2024-03-29 10:48:08.201 469 ERROR keystone metadata._remove_table(name, schema) 2024-03-29 10:48:08.201 469 ERROR keystone File "/usr/lib/python3/dist-packages/sqlalchemy/util/langhelpers.py", line 67, in __exit__ 2024-03-29 10:48:08.201 469 ERROR keystone compat.reraise(exc_type, exc_value, exc_tb) 2024-03-29 10:48:08.201 469 ERROR keystone File "/usr/lib/python3/dist-packages/sqlalchemy/util/compat.py", line 277, in reraise 2024-03-29 10:48:08.201 469 ERROR keystone raise value 2024-03-29 10:48:08.201 469 ERROR keystone File "/usr/lib/python3/dist-packages/sqlalchemy/sql/schema.py", line 464, in __new__ 2024-03-29 10:48:08.201 469 ERROR keystone table._init(name, metadata, *args, **kw) 2024-03-29 10:48:08.201 469 ERROR keystone File "/usr/lib/python3/dist-packages/sqlalchemy/sql/schema.py", line 552, in _init 2024-03-29 10:48:08.201 469 ERROR keystone metadata, autoload_with, include_columns, _extend_on=_extend_on 2024-03-29 10:48:08.201 469 ERROR keystone File "/usr/lib/python3/dist-packages/sqlalchemy/sql/schema.py", line 590, in _autoload 2024-03-29 10:48:08.201 469 ERROR keystone _extend_on=_extend_on, 2024-03-29 10:48:08.201 469 ERROR keystone File "/usr/lib/python3/dist-packages/sqlalchemy/engine/base.py", line 2125, in run_callable 2024-03-29 10:48:08.201 469 ERROR keystone return conn.run_callable(callable_, *args, **kwargs) 2024-03-29 10:48:08.201 469 ERROR keystone File "/usr/lib/python3/dist-packages/sqlalchemy/engine/base.py", line 1596, in run_callable 2024-03-29 10:48:08.201 469 ERROR keystone return callable_(self, *args, **kwargs) 2024-03-29 10:48:08.201 469 ERROR keystone File "/usr/lib/python3/dist-packages/sqlalchemy/engine/default.py", line 415, in reflecttable 2024-03-29 10:48:08.201 469 ERROR keystone table, include_columns, exclude_columns, **opts 2024-03-29 10:48:08.201 469 ERROR keystone File "/usr/lib/python3/dist-packages/sqlalchemy/engine/reflection.py", line 639, in reflecttable 2024-03-29 10:48:08.201 469 ERROR keystone raise exc.NoSuchTableError(table.name) 2024-03-29 10:48:08.201 469 ERROR keystone migrate.exceptions.DatabaseNotControlledError: migrate_version 2024-03-29 10:48:08.201 469 ERROR keystone 2024-03-29 10:48:08.201 469 ERROR keystone During handling of the above exception, another exception occurred: 2024-03-29 10:48:08.201 469 ERROR keystone 2024-03-29 10:48:08.201 469 ERROR keystone Traceback (most recent call last): 2024-03-29 10:48:08.201 469 ERROR keystone File "/usr/bin/keystone-manage", line 10, in <module> 2024-03-29 10:48:08.201 469 ERROR keystone sys.exit(main()) 2024-03-29 10:48:08.201 469 ERROR keystone File "/usr/lib/python3/dist-packages/keystone/cmd/manage.py", line 41, in main 2024-03-29 10:48:08.201 469 ERROR keystone cli.main(argv=sys.argv, developer_config_file=developer_config) 2024-03-29 10:48:08.201 469 ERROR keystone File "/usr/lib/python3/dist-packages/keystone/cmd/cli.py", line 1370, in main 2024-03-29 10:48:08.201 469 ERROR keystone CONF.command.cmd_class.main() 2024-03-29 10:48:08.201 469 ERROR keystone File "/usr/lib/python3/dist-packages/keystone/cmd/cli.py", line 327, in main 2024-03-29 10:48:08.201 469 ERROR keystone sys.exit(DbSync.check_db_sync_status()) 2024-03-29 10:48:08.201 469 ERROR keystone File "/usr/lib/python3/dist-packages/keystone/cmd/cli.py", line 269, in check_db_sync_status 2024-03-29 10:48:08.201 469 ERROR keystone expand_version = upgrades.get_db_version(repo='expand_repo') 2024-03-29 10:48:08.201 469 ERROR keystone File "/usr/lib/python3/dist-packages/keystone/common/sql/upgrades.py", line 236, in get_db_version 2024-03-29 10:48:08.201 469 ERROR keystone session.get_bind(), repo, get_init_version(repo)) 2024-03-29 10:48:08.201 469 ERROR keystone File "/usr/lib/python3/dist-packages/oslo_db/sqlalchemy/migration.py", line 131, in db_version 2024-03-29 10:48:08.201 469 ERROR keystone meta.reflect(bind=engine) 2024-03-29 10:48:08.201 469 ERROR keystone File "/usr/lib/python3/dist-packages/sqlalchemy/sql/schema.py", line 4159, in reflect 2024-03-29 10:48:08.201 469 ERROR keystone Table(name, self, **reflect_opts) 2024-03-29 10:48:08.201 469 ERROR keystone File "/usr/lib/python3/dist-packages/sqlalchemy/sql/schema.py", line 469, in __new__ 2024-03-29 10:48:08.201 469 ERROR keystone metadata._remove_table(name, schema) 2024-03-29 10:48:08.201 469 ERROR keystone File "/usr/lib/python3/dist-packages/sqlalchemy/util/langhelpers.py", line 67, in __exit__ 2024-03-29 10:48:08.201 469 ERROR keystone compat.reraise(exc_type, exc_value, exc_tb) 2024-03-29 10:48:08.201 469 ERROR keystone File "/usr/lib/python3/dist-packages/sqlalchemy/util/compat.py", line 277, in reraise 2024-03-29 10:48:08.201 469 ERROR keystone raise value 2024-03-29 10:48:08.201 469 ERROR keystone File "/usr/lib/python3/dist-packages/sqlalchemy/sql/schema.py", line 464, in __new__ 2024-03-29 10:48:08.201 469 ERROR keystone table._init(name, metadata, *args, **kw) 2024-03-29 10:48:08.201 469 ERROR keystone File "/usr/lib/python3/dist-packages/sqlalchemy/sql/schema.py", line 552, in _init 2024-03-29 10:48:08.201 469 ERROR keystone metadata, autoload_with, include_columns, _extend_on=_extend_on 2024-03-29 10:48:08.201 469 ERROR keystone File "/usr/lib/python3/dist-packages/sqlalchemy/sql/schema.py", line 574, in _autoload 2024-03-29 10:48:08.201 469 ERROR keystone _extend_on=_extend_on, 2024-03-29 10:48:08.201 469 ERROR keystone File "/usr/lib/python3/dist-packages/sqlalchemy/engine/base.py", line 1596, in run_callable 2024-03-29 10:48:08.201 469 ERROR keystone return callable_(self, *args, **kwargs) 2024-03-29 10:48:08.201 469 ERROR keystone File "/usr/lib/python3/dist-packages/sqlalchemy/engine/default.py", line 415, in reflecttable 2024-03-29 10:48:08.201 469 ERROR keystone table, include_columns, exclude_columns, **opts 2024-03-29 10:48:08.201 469 ERROR keystone File "/usr/lib/python3/dist-packages/sqlalchemy/engine/reflection.py", line 639, in reflecttable 2024-03-29 10:48:08.201 469 ERROR keystone raise exc.NoSuchTableError(table.name) 2024-03-29 10:48:08.201 469 ERROR keystone sqlalchemy.exc.NoSuchTableError: access_rule 2024-03-29 10:48:08.201 469 ERROR keystone I've checked the DB and both tables are there (access_rule and migrate_version). Do you know what could be wrong ? Best Alex

1 0

[ironic][PTG] Ironic Dalmatian 2024.2 PTG schedule
by Riccardo Pittau 29 Mar '24

29 Mar '24

Hello ironicers! We've finalized the schedule for the Ironic Dalmatian (2024.2) virtual PTG happening from Tuesday April 9th to Thursday April 11th. You can find the list of topics and the detailed schedule as well as the link to connect to the event in the etherpad at https://etherpad.opendev.org/p/ironic-ptg-april-2024 See you all there! CIao Riccardo

1 0

[Bobcat][Ansible][AIO] how to inspect lxc logs
by tatsuro.makita.bp＠nttdata.com 29 Mar '24

29 Mar '24

Hi OpenStack Users Group, I am building a single instance of AWS EC2 using OpenStack Ansible AIO (Bobcat). We are trying to build an all-in-one environment and check the functions of Bobcat. Construction Steps: https://docs.openstack.org/openstack-ansible/latest/user/aio/quickstart.html * I could use VLAN on EC2 only one instance. it doesn't multi-instance. Anssible has been successful, and I can access and log in to the Horizon console with a browser. I have been able to register the image, but I get an error when I create a volume from the image. * Even if you create an empty volume, the same error will occur. Wording displayed in the volume creation message: Message Level: ERROR Event Id: VOLUME_VOLUME_001_003 User Message: "all schedulelocate volume:Could not find any available weighted backend." When I tried to refer to the lxc log to debug the environment, Under /var/log/lxc, there is only the log from the first startup, and there are no debug statements that are running during the actual inspection. The lxc-* command does not have a command like "Docker logs", so I am having trouble analyzing logs such as Cinder. When building with Ansible, it is built with "debug:True" defined in /etc/openstacl_deploy/user_variables.yml. Is there any other configuration that outputs Debug logs for each component? Any advice on things to look at when analyzing each component built with lxc would be fine. Furthermore, my environment is as follows. *Instance type: m5a.2xlarge *vCPU8, 32GiB, EBS storage 100GB(root) and 50GB(seccond) *OS:Ubuntu-jammy-22.04 *OpenStack Ansible: 28.0.1 (Bobcat) Thanks regards.

3 5

[barbican][requirements] incompatibility between cryptography and pykmip
by Takashi Kajinami 29 Mar '24

29 Mar '24

Hello, It was recently discovered that the latest pykmip release is not compatible[1][2] with cryptography>42.0.0, which is currently in upper constraints for master and 2024.1. The latest release of pykmip is incompatible with even cryptography >= 39.0.0, because no release has been created since the compatibility fix[2] was merged. The stable/2023.2 branch currently uses cryptography 40.0.2 so the pykmip library has been broken since 2023.2, it seems. I wonder what would be the appropriate step to mitigate the problem, and I would like to ask for opinions. Especially the first question is a bit urgent because we have quite a short period to make deprecation for 2024.1 . 1. (To the barbican team and the operators subscribing this list) Can we deprecate the kmip secret store plugin in 2024.1 so that we can drop it in 2024.2 ? Or does anyone have any concern with removing it in a future release ? 2. (To requirements team) In case the proposed fix[3] is merged and a new pykmip release is created, can we bump the version in 2024.1 u-c and 2023.2 u-c ? As far as I've checked, pykmip is used only by Barbican so bumping it would have quite limited impact. Thank you, Takashi [1] https://meetings.opendev.org/irclogs/%23openstack-barbican/%23openstack-bar… [2] https://github.com/OpenKMIP/PyKMIP/issues/713 [3] https://github.com/OpenKMIP/PyKMIP/commit/652d5cab [4] https://github.com/OpenKMIP/PyKMIP/pull/714 -- Takashi Kajinami irc: tkajinam github: https://github.com/kajinamit launchpad: https://launchpad.net/~kajinamit

2 1

[release] Release countdown for week R+0, Apr 01-05
by Elõd Illés 28 Mar '24

28 Mar '24

Development Focus ----------------- We will be releasing the coordinated OpenStack 2024.1 Caracal release next week, on April 3rd, 2024. Thanks to everyone involved in the 2024.1 Caracal cycle! We are now in pre-release freeze, so no new deliverable will be created until final release, unless a release-critical regression is spotted. Otherwise, teams attending the virtual PTG should start to plan what they will be discussing there, by creating and filling team etherpads. You can access the list of PTG etherpads at: http://ptg.openstack.org/etherpads.html General Information ------------------- On release day, the release team will produce final versions of deliverables following the cycle-with-rc release model, by re-tagging the commit used for the last RC. A patch doing just that will be proposed. PTLs and release liaisons should watch for that final release patch from the release team. While not required, we would appreciate having an ack from each team before we approve it on the 3rd, so that their approval is included in the metadata that goes onto the signed tag. Upcoming Deadlines & Dates -------------------------- Final 2024.1 Caracal release: April 3rd, 2024 2024.2 Dalmatian Virtual PTG: April 8-12, 2024 Előd Illés irc: elodilles @ #openstack-release

1 0

[CloudKitty] Cancelling weekly meeting of 1st of April
by Rafael Weingärtner 28 Mar '24

28 Mar '24

April 1stt is a public holiday for most People who attend the CloudKitty bi-weekly meeting. Therefore, we will be cancelling If you need any assistance until the next meeting, you can reach me via e-mail. Best regards, -- Rafael Weingärtner

1 0

[tc] Resolution regarding 2024.2 Dalmatian election
by Jay Faulkner 28 Mar '24

28 Mar '24

Hi all, There was a difficult situation spawned by the results of the recent TC election; all members, as elected, could not be seated under the TC Charter's diversity of affiliation policy[0][1]. One of the tc-members-elect from Red Hat, Sylvain Bauza, resigned his candidacy to resolve the affiliation issue[2]. As a result, we have a TC resolution up for vote, https://review.opendev.org/c/openstack/governance/+/914024, which adjudicates the election by acknowledging Sylvain's decision and naming Artem Goncharov his replacement under the TC charter rules for filling vacant seats[3]. This email serves as the required notice to the community of this resolution. I'd like to personally thank the Red Hat TC members and members-elect for resolving this issue, with a special thanks to Sylvain for helping to preserve TC affiliation diversity. Thanks, Jay Faulkner OpenStack TC Chair 0: https://governance.openstack.org/tc/reference/charter.html#tc-diversity-req… 1: https://review.opendev.org/c/openstack/governance/+/913912/3#message-728e57… 2: https://review.opendev.org/c/openstack/governance/+/913912/3#message-bb14bf… 3: https://governance.openstack.org/tc/reference/charter.html#election-for-tc-…

4 3

Facing issues in accessing console of Openstack VM's in EDGE sites
by Swogat Pradhan 28 Mar '24

28 Mar '24

Hi, I have set up openstack wallaby using tripleo on 3 different locations using DCN. I have a central site and 2 EDGE sites, when accessing the console of central sites I do not face any issues, but when accessing the console for EDGE sites I face issues sometimes, and then the issue disappears automatically and then comes back again. Attaching screenshot for reference. Can you please suggest what to look at here to fix this issue? With regards, Swogat Pradhan

2 2

[freezer] IRC channel #openstack-freezer has been registered
by Dmitriy Rabotyagov 28 Mar '24

28 Mar '24

Hey folks, After ML [1] some folks joined the #openstack-freezer channel on OFTC network, but I asked ppl to leave it since we had to empty the channel and register it accordingly. I'm glad to announce that this process has been completed (huge kudos to Jeremy Stanley (fungi) for helping with that!) and everyone interested in reviving/contributing to the Freezer project are warmly welcome to join the channel. [1] https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack…

2 1

[Glance] Cancelling Today's Weekly Meeting
by Pranali Deore 27 Mar '24

27 Mar '24

Hello, Cancelling today's meeting since there is nothing much on agenda for today. Thanks & Regards, Pranali Deore

1 0

tool can be used to monitor an OpenStack
by kjme001＠gmail.com 27 Mar '24

27 Mar '24

hello what tool can be used to monitor an OpenStack cluster? Regards

2 1

[tc][ptg] PTG Schedule
by Jay Faulkner 27 Mar '24

27 Mar '24

Hi all, I've put together a tentative schedule for TC topics and times for discussion on the etherpad: https://etherpad.opendev.org/p/apr2024-ptg-os-tc -- it may change if new topics emerge. Please let me know if any of the scheduled times are a hardship or if there are any questions. Thanks, Jay Faulkner OpenStack TC Chair

1 0

[ptl][release] OpenStack Caracal OpenInfra Live
by Allison Price 27 Mar '24

27 Mar '24

Hi everyone, Apologies for the late notice, but I wanted to gather interest from PTLs to participate in an OpenStack Caracal OpenInfra Live next Thursday, April 3 after Wednesday’s release. Like past episodes (you can see Bobcat here [1]), we will give interested PTLs the opportunity to present the progress their team made in Caracal as well as present upcoming priorities for Dalmatian. The episode will air on Thursday at 1400 UTC, so interested participants would need to be available 1330-1500 UTC on Thursday, April 3. If you are interested, please let me know. Thanks! Allison [1] https://www.youtube.com/watch?v=q7WDncK3YuM

6 9

Proposing Pete Zaitcev as Cinder core
by Rajat Dhasmana 27 Mar '24

27 Mar '24

Hello everyone, I would like to nominate Pete Zaitcev for the Cinder core position. Here is a summary of the work done by Pete in the Cinder project: 1. Reviews In the last 90 days[1] (half cycle), he has been the third highest reviewer in number (after 2 cores) and has a decent +/- ratio (stating that he frequently suggests improvements/asks questions in patches) In the last 180 days[2] (one cycle), we see the same pattern. 2. Commits Pete has taken over the backup domain of Cinder, which was not very actively looked at before. He has already completed features and fixes to improve our backup drivers, and is actively looking to improve swift and ceph backup backends which are the most used by OpenStack users. 3. Community Presence Pete consistently attends Cinder upstream events like meetings, festival of XS reviews, midcycles, PTGs etc. Apart from that, Pete also brings expertise from his Swift experience in the object storage domain. Given all the above reasons, I feel Pete is a good candidate for the cinder core team. I will keep this thread open for 1 week and if there are no objections, I will add Pete to the cinder core group. [1] https://www.stackalytics.io/report/contribution?module=cinder-group&project… [2] https://www.stackalytics.io/report/contribution?module=cinder-group&project… Thanks Rajat Dhasmana

5 6

[cinder][PTG] Cinder 2024.2 Dalmatian PTG planning
by Jon Bernard 27 Mar '24

27 Mar '24

Hi All, We will be conducting the Cinder 2024.2 (Dalmatian) PTG in a couple of weeks from Tuesday April 9th to Friday April 12th from 1300-1700 UTC[1]. The etherpad and schedule for Cinder PTG is here[2]. [1] https://ptg.opendev.org/ptg.html [2] https://etherpad.opendev.org/p/dalmatian-ptg-cinder Please add any topics or ideas you wish to propose for discussion to the "planning" section of the etherpad. Once we have the final set of topics, they will be distributed across our available days. Following are the details of the event: Dates: 9 April (Tuesday) - 12 April (Friday), 2024 Time: 1300 - 1700 UTC Room: Newton Video conference Tool: Zoom (Link can be found on the PTG page[1] by clicking on Cinder slot) Thanks! -- Jon

2 1

[cinder] This week's meeting (today) will be in video+IRC
by Rajat Dhasmana 27 Mar '24

27 Mar '24

Hello Argonauts, As we keep last meeting of the month in video + IRC mode, this week's meeting (today) will be held in video + IRC mode with the following details: Date: 27th March, 2024 Time: 1400 UTC Meeting link: https://meet.google.com/zya-oxpp-qre IRC Channel: #openstack-meeting-alt Make sure you're connected to both the gmeet meeting and IRC as discussion can happen at both places depending on how the author wants to conduct it. Thanks Rajat Dhasmana

1 0

Network would be shown to a member but IP allocation would be denied?
by Mika Saari 27 Mar '24

27 Mar '24

Hi, I am currently testing kolla-ansible using the latest release. During the creation of an external/provider network ("public"), I have observed that a non-admin project ("test") can view the network and allocate IP addresses for routers, for example. I would like to restrict this behavior so that the external network is listable (openstack network list), but IP allocation is denied. I have experimented with RBAC rules, creating a new role ("view-only") and assigning it to a user ("user") in the "test" project. I modified the policy.yaml files in both Neutron and Horizon as outlined in the documentation ( https://docs.openstack.org/kolla-ansible/latest/admin/advanced-configuratio… ). Below are the snippets from my neutron/policy.yaml and horizon/neutron_policy.yaml files created following the sample https://docs.openstack.org/neutron/2023.2/configuration/policy-sample.html policy.yaml get_network: "(rule:admin_only) or (role:view_only)" get_subnet: "(rule:admin_only) or (role:view_only)" get_port: "(rule:admin_only) or (role:view_only)" get_router: "(rule:admin_only) or (role:view_only)" neutron_policy.yaml get_network: "(rule:admin_only) or (role:view_only)" get_subnet: "(rule:admin_only) or (role:view_only)" get_port: "(rule:admin_only) or (role:view_only)" get_router: "(rule:admin_only) or (role:view_only)" After deploying Neutron and Horizon, I adjusted the default RBAC policy so that the "External Network" action only affects the "admin" project, not "*". While the admin can still see the public network, the test project user with the "view_only" role cannot see the "public" network. Enabling the RBAC policy for the "test" project allows the network to be visible, but it also enables the member of the project ("user") to reserve IP addresses for network components. I'm seeking guidance on where to find more information about policies to achieve the desired functionality. Should I redeploy all the services, or is depolying Neutron and Horizon sufficient? Am I on the right track with my policy tests, or is there a simpler way to achieve this functionality? Thank you very much for your assistance!

2 6