May 2024 - openstack-discuss - lists.openstack.org

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

[tc][all][monasca ] Retiring the Monasca project
by Ghanshyam Mann 16 Feb '25

16 Feb '25

Hello everyone, As you might know, the Monasca project is not active and was marked 'inactive' since 2024.1 cycle[1]. In this cycle also, this project is leaderless[2] and no maintainer stepped up to maintain it. As discussed in the Leaderless project etherpad[2], the next step is to retire the project. I'm sending this email to propose the Monasca retirement and based on the response, I will proceed next. [1] https://governance.openstack.org/tc/reference/emerging-technology-and-inact… [2] https://etherpad.opendev.org/p/2024.2-leaderless#L72 -gmann

6 17

[ironic]About the OS supported by Diskimage-builder
by Junya Noguchi (Fujitsu) 03 Feb '25

03 Feb '25

To whom it may concern. My name is Junya Noguchi. I have some questions about the supported OS for Diskimage-builder operation. Please respond. References https://docs.openstack.org/ironic-python-agent-builder/latest/admin/dib.html Does it mean that the OS that says "work but receive only limited testing and support" works but is not supported? References https://docs.openstack.org/diskimage-builder/latest/ This document describes RHEL and other operating systems that are not supported in the previous question. Are these operating systems supported? Also, are there any plans to support more operating systems in the future? Best regards, Junya Noguchi

5 7

[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

[ironic] Having issue with deploying ISO image to node
by James Leong 17 Nov '24

17 Nov '24

Hi all, I am trying to play around with ironic, and I am having an issue with deploying an Ubuntu 20.04 ISO image onto my bare metal node. Since I am quite new to bare metal, I am not entirely sure what went wrong as I couldn't find any error messages shown on my log file (ironic-conductor, ironic-api, ironic_neutron_agent, and nova-compute-ironic). This might be my guess; the ironic inspection is hitting timeout, which is causing the deployment to timeout. However, I have no idea why the inspection is failing at timeout. Any help would be appreciated. Best, James

6 7

[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

[kuryr][tc] Final call for Kuryr PTL/DPL liaisons
by Ghanshyam Mann 15 Oct '24

15 Oct '24

Hello Everyone, Kuryr project ends up being a leaderless project for the 2024.2 Dalmatian cycle[1]. There is no volunteer to serve as PTL or DPL liaisons yet. As the next step, I have proposed to mark this project Inactive: - https://review.opendev.org/c/openstack/governance/+/916945 If you would like to serve as a leader and help maintain this project, this is the right time to step up by replying to this email or commenting in gerrit change 916945. [1] https://etherpad.opendev.org/p/2024.2-leaderless#L99 Ref: https://governance.openstack.org/tc/reference/emerging-technology-and-inact… -gmann

4 10

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

[openstack][kolla-ansible]about upgrading openstack
by Nguyễn Hữu Khôi 04 Aug '24

04 Aug '24

Hello. I read this doc about upgrading openstack https://docs.openstack.org/kolla-ansible/latest/user/operating-kolla.html But I would like to know if We install a new kolla-ansible(version to upgrade) on the new deployment host, apply changes with password.yml, global.yml and multinode and keep old /etc/kolla/config. Finally, we use kolla-ansible deploy instead of kolla-ansible upgrade. Are these steps ok? Pls correct me if I am wrong. Thank you. Regards Nguyen Huu Khoi

3 8

[kolla-ansible][letsencrypt] containers are running but not getting certificates.
by Jonathan Proulx 03 Jul '24

03 Jul '24

Hi All, I'm trying to do a test multinode deploy using 2023.2 I have letsencrypt_webserver and letsencrypt_lego contsainers running and I'm seeing random traffic in the /var/log/kolla/letsencrypt/letsencrypt-webserver-access.log so fairly confident they're plumbed through to the public internet properly, but I don't seem to be getting certificates. how can I trigger a renewal attempt so I can maybe see what I've screwed up? Thanks, -Jon -- Jonathan Proulx (he/him) Sr. Technical Architect The Infrastructure Group MIT CSAIL

3 6

[barbican][openstack-helm][tacker] Request to Include Barbican Installation Guide in OpenStack-Helm Documentation
by JUSO WATARU(十楚　航) 20 Jun '24

20 Jun '24

Hello, We are presently in the process of enhancing the official OpenStack-Helm documentation by including a procedural guide for deploying Tacker using helmchart. Through discussions with members of the openstack-helm community, it has been emphasized that Barbican is an indispensable component for Tacker. Hence, it would be highly beneficial for users to have comprehensive instructions for installing Barbican with helmchart included in the official OpenStack-Helm documentation [1]. Consequently, we suggest that the Barbican community integrate the installation guide for the Barbican component into the official OpenStack-Helm documentation. This addition is poised to significantly enhance the clarity and accessibility of deployment procedures for users. We eagerly welcome your opinions and feedback on this proposal, as we aim to ensure that the documentation for openstack deployment with helmchart meets the needs of our community. [1] https://docs.openstack.org/openstack-helm/latest/install/openstack.html Regards, Wataru

2 2

Issue in Stack.sh
by Lohit S 13 Jun '24

13 Jun '24

How to fix this issue while stack.sh is executed +functions-common:_run_under_systemd:1655 sudo systemctl start devstack(a)q-svc.service +functions-common:run_process:1687 time_stop run_process +functions-common:time_stop:2421 local name +functions-common:time_stop:2422 local end_time +functions-common:time_stop:2423 local elapsed_time +functions-common:time_stop:2424 local total +functions-common:time_stop:2425 local start_time +functions-common:time_stop:2427 name=run_process +functions-common:time_stop:2428 start_time=1716869530330 +functions-common:time_stop:2430 [[ -z 1716869530330 ]] ++functions-common:time_stop:2433 date +%s%3N +functions-common:time_stop:2433 end_time=1716869534546 +functions-common:time_stop:2434 elapsed_time=4216 +functions-common:time_stop:2435 total=16163 +functions-common:time_stop:2437 _TIME_START[$name]= +functions-common:time_stop:2438 _TIME_TOTAL[$name]=20379 +lib/neutron:start_neutron_service_and_check:640 neutron_url= http://192.168.122.150:9696/ +lib/neutron:start_neutron_service_and_check:642 is_service_enabled tls-proxy +functions-common:is_service_enabled:2077 return 1 +lib/neutron:start_neutron_service_and_check:646 '[' '!' -z networking ']' +lib/neutron:start_neutron_service_and_check:647 neutron_url= http://192.168.122.150:9696/networking +lib/neutron:start_neutron_service_and_check:649 echo 'Waiting for Neutron to start...' Waiting for Neutron to start... +lib/neutron:start_neutron_service_and_check:651 local 'testcmd=wget --no-proxy -q -O- http://192.168.122.150:9696/networking' +lib/neutron:start_neutron_service_and_check:652 test_with_retry 'wget --no-proxy -q -O- http://192.168.122.150:9696/networking' 'Neutron did not start' 60 +functions-common:test_with_retry:2359 local 'testcmd=wget --no-proxy -q -O- http://192.168.122.150:9696/networking' +functions-common:test_with_retry:2360 local 'failmsg=Neutron did not start' +functions-common:test_with_retry:2361 local until=60 +functions-common:test_with_retry:2362 local sleep=0.5 +functions-common:test_with_retry:2364 time_start test_with_retry +functions-common:time_start:2407 local name=test_with_retry +functions-common:time_start:2408 local start_time= +functions-common:time_start:2409 [[ -n '' ]] ++functions-common:time_start:2412 date +%s%3N +functions-common:time_start:2412 _TIME_START[$name]=1716869535329 +functions-common:test_with_retry:2365 timeout 60 sh -c 'while ! wget --no-proxy -q -O- http://192.168.122.150:9696/networking; do sleep 0.5; done' +functions-common:test_with_retry:2366 die 2366 'Neutron did not start' +functions-common:die:285 local exitcode=0 [Call Trace] ./stack.sh:1322:start_neutron_service_and_check /home/lohit22/opensource/openstack/devstack/Org/devstack/lib/neutron:652:test_with_retry /home/lohit22/opensource/openstack/devstack/Org/devstack/functions-common:2366:die [ERROR] /home/lohit22/opensource/openstack/devstack/Org/devstack/functions-common:2366 Neutron did not start exit_trap: cleaning up child processes Error on exit

2 2

[openstack charm][tc] openstack-charms still need PTL appointment
by Ghanshyam Mann 11 Jun '24

11 Jun '24

Hello Felipe, openstack-charm team, I tried to reach out to you on IRC but could not connect. This is regarding openstack-charm PTL appointment for the 2024.2 cycle. I am not sure if you noticed or not but there are some comments for you to fix on your PTL appointment. Please check the below Gerrit change and fix the same or let us know if there is a change in the plan. - https://review.opendev.org/c/openstack/governance/+/914254 -gmann

2 3

[swift] clean up orphan segment parts
by Rafael Tavares Oliveira 07 Jun '24

07 Jun '24

Hey there! We've been using swift and we came across this bug https://bugs.launchpad.net/swift/+bug/1813202. We decided to work it out and have an ongoing patch to solve this issue alongside ronaldo.maia(a)luizalabs.com, we would like to share and get some feedback before we submit it. To solve this, we took inspiration in obj/expirer.py: In S3 controllers we register task objects in an internal account, each task object points to an orphaned slo object, which can be created in two situations, when a multipart-upload is not completed or when a multipart object is overwritten. These tasks will be checked by the daemon (a new one we made called "s3-slo-expirer") after some time and deleted from the base accounts. Rafael

2 2

[all][tc] Eventlet migration: Call to action
by Jay Faulkner 07 Jun '24

07 Jun '24

Hi all, As you may have read in Goutham's TC summary, the existing eventlet goal[0] is unlikely to gain consensus to merge. This appears to be due to the difference in needs between OpenStack projects, and belief that it's unlikely a single solution would serve them all. Our current situation is: 1) Eventlet usage must be discontinued. The temporary maintainers are just that -- temporary -- and we should not expect eventlet to continue to be a valid path moving forward. 2) We have basic agreement that shared tooling, such as oslo libraries, should not dictate a specific threading model. In lieu of specific technical leadership and guidance from the TC, this leaves it to individual projects to decide what threading model to use instead of eventlet monkey patching. The unmerged spec[0] may be a good starting point if you're wondering where to start. Importantly: do not let this work wait! It is a significant change and will take a long time to complete. Thanks, Jay Faulkner 0: https://review.opendev.org/c/openstack/governance/+/902585

6 7

Antelope Barbican/Keystone: failure to delete secrets (Keystone TrustNotFound)
by Michel Jouvin 05 Jun '24

05 Jun '24

Hi, I've been validating Yoga -> Antelope on our preprod cloud. It was working successfully but "suddenly" (i.e. without a kwown/identified change!) when deleting Magnum clusters, the deletion of Barbican secrets (after stack deletion) fail. In the Magnum log, I find the following error: ---- Failed to delete trust: keystoneauth1.exceptions.http.Unauthorized: The request you have made requires authentication. (HTTP 401) (Request-ID: req-a4400250-e8d5-46ec-a28a-dcb97a682512) (traceback skipped for readability) 2024-05-29 10:43:09.750 2078 INFO magnum.common.cert_manager.barbican_cert_manager [None req-94df560b-d6da-4fba-83a9-34e0b08c64c8 - - - - - -] Recursively deleting certificate container https://os-77023.lal.in2p3.fr:9311/v1/containers/edd8487a-6cf1-4f4c-9f53-17… from Barbican. 2024-05-29 10:43:09.750 2078 INFO barbicanclient.base [None req-94df560b-d6da-4fba-83a9-34e0b08c64c8 - - - - - -] Calculated Containers uuid ref: containers/edd8487a-6cf1-4f4c-9f53-173dfae7a8b2 2024-05-29 10:43:09.760 2078 ERROR barbicanclient.client [None req-94df560b-d6da-4fba-83a9-34e0b08c64c8 - - - - - -] 4xx Client error: Not Found: Secrets container not found. 2024-05-29 10:43:09.761 2078 ERROR magnum.common.cert_manager.barbican_cert_manager [None req-94df560b-d6da-4fba-83a9-34e0b08c64c8 - - - - - -] Error recursively deleting certificate container https://os-77023.lal.in2p3.fr:9311/v1/containers/edd8487a-6cf1-4f4c-9f53-17…: barbicanclient.exceptions.HTTPClientError: Not Found: Secrets container not found. ---- In Keystone log, I find with the same timestamp the following error that seems related to the one above: ---- 2024-05-29 10:43:09.690 1713 WARNING keystone.api._shared.authentication [None req-a4400250-e8d5-46ec-a28a-dcb97a682512 - - - - - -] Could not find trust: cf4b1b6082594025a1ff9e48df383566.: keystone.exception.TrustNotFound: Could not find trust: cf4b1b6082594025a1ff9e48df383566. 2024-05-29 10:43:09.693 1713 WARNING keystone.server.flask.application [None req-a4400250-e8d5-46ec-a28a-dcb97a682512 - - - - - -] Authorization failed. The request you have made requires authentication. from 134.158.77.23: keystone.exception.Unauthorized: The request you have made requires authentication. 2024-05-29 10:43:09.746 1723 ERROR keystone.server.flask.application [None req-8c76f304-c2a3-418c-8372-02c706ed356e 44d8cb3192b3485790ababe29991491a - 5b67a8641dd041089e018ceea9884eac - 5b67a8641dd041089e018ceea9884eac -] Could not find user: 527ec32509d849e8a49b41c3dc4c4c32.: keystone.exception.UserNotFound: Could not find user: 527ec32509d849e8a49b41c3dc4c4c32. ---- It is not clear for me if the ERROR is releated to the 2 warnings as the request is not the same but it seems to happen every time this way. In Barbican logs, there is not much things related except a 401 status for the request corresponding ot the TrustNotFound. I'm looking for advices on how to troubleshoot this. In particular, when the trust should be created and whether I should find somewhere a matching error at the time of the trust creation. It seems the error is only affecting deletion but I may be wrong. for the record, when starting Magnum there is an error complaining about /etc/magnum/keystone_auth_default_policy.json being not found but ignored it so far. And in Keystone an error seems to occur at Magnum cluster creation time: --- 2024-05-29 10:17:17.530 1711 WARNING py.warnings [None req-f484cc35-3e54-4d7f-8688-e6442c90344f a22b1199c74f4a819a49f3ac037a5e44 1dd67113c8bb4ef0a31dfca53335ffbd - - defaul t default] /usr/lib/python3.9/site-packages/oslo_policy/policy.py:1129: UserWarning: Policy "identity:list_services": "role:reader and system_scope:all" failed scope check. The token used to make the request was project scoped but the policy requires ['system'] scope. This behavior may change in the future where using the intended scope is re quired ---- Thanks in advance for any hint. Best regards, Michel

2 3

Antelope Magnum: creating a new cluster makes the/some others unhealthy
by Michel Jouvin 05 Jun '24

05 Jun '24

Hi, I have been playing with Magnum (Antelope), creating a lot of clusters with the same template and varying the number of masters and/or nodes, having ~10 clusters started in the same project. I observed recently that cluster configuration that used to work well were not working any more (CREATE_FAILED during the master deployment in general). I have not found any evidence of the cause digging in various logs but I observed that with the current list of active clusters, if add a new one (even with a configuration as minimal as 1 master and 1 node), not only its creation fails but also the other (or at least) running clusters become unhealthy. If I delete the failed cluster, the other clusters return to the healthy state. It seems very reproducible (I did it more than 10 times) but I still don't see any message in the logs that could help to identify the cause. I've the feeling (but may be wrong) that it is related to either an insufficient project quota or an insufficient limit on one of the OpenStack service. Any idea on a possible cause or any advice on where to look for some information? Thanks in advance. Michel

2 6

[all] SQLAlchemy minimum requirement
by Pierre Riteau 02 Jun '24

02 Jun '24

Hello everyone, Historically, many projects were using the following requirement for SQLAlchemy: SQLAlchemy!=1.1.5,!=1.1.6,!=1.1.7,!=1.1.8,>=1.0.10 These banned versions were present in global-requirements.txt until earlier this month [1]. The remaining projects with the above requirement must change it to fix their requirements-check job (ERROR: Requirement for package SQLAlchemy excludes a version not excluded in the global list). While fixing the requirement for blazar, I realised that OpenStack projects are using a wide range of minimum requirements. For example, networking-sfc had already bumped the minimum to SQLAlchemy 2.0 [2], although this is being reverted [3]. While all projects must be compatible with the upper constraint (currently 2.0.30), should we agree on a maximum version for the lower bound? The 2024.2 release targets Ubuntu Jammy, which includes python3-sqlalchemy 1.4.31, and Debian bookworm, which includes python3-sqlalchemy 1.4.46. Thanks, Pierre Riteau (priteau) [1] https://review.opendev.org/c/openstack/requirements/+/879743 [2] https://review.opendev.org/c/openstack/networking-sfc/+/920046 [3] https://review.opendev.org/c/openstack/networking-sfc/+/920868

2 1

The outbound unicast traffic of VMS with security group enabled is broadcast
by renwc＠chinatelecom.cn 31 May '24

31 May '24

hello everyone， Here is a description of a bug I encountered using openstack Security Group,If security groups are enabled for virtual nics on cloud hosts, The outgoing traffic of the VMS enabled in the security group should be sent in unicast mode, but it is eventually forwarded to all ports in the vlan on the ovs br-int bridge. Does the openstack open source community have a patch to fix this bug? Can you provide patch? The following is my debugging process in detail. The unicast packet sent by the remote virtual machine 172.83.160.63 to the local virtual machine 172.83.160.74 is passed to the br-ex->br-int-> VM, Because the security group is enabled on the VM NIC, The br-int cannot learn the entry whose port is patch-ex and mac address is vm2. Therefore those packets sent from vm1 to vm2 are broadcast in vlans because they fail to match mac address entries. 172.83.160.74 patch-int 172.83.160.63 vm1 --- ovs(br-int) ------ ovs(br-ex)--- tor(physical switch) ......vm2 patch-ex The following is the ovs kernel flow table. The mac address of vm1 is fa:16:3e:6c:f3:09,The mac address of vm2 is fa:16:3e:d2:14:b5, the action of the flow table is multiple ports. recirc_id(0x314123),in_port(8),ct_state(-new+est-rel-rpl),eth(src=fa:16:3e:d2:14:b5,dst=fa:16:3e:6c:f3:09),eth_type(0x0800),ipv4(proto=6,frag=no),tcp(dst=2048/0xf800), packets:60100, bytes:14257193, used:2.035s, flags:P., actions:push_vlan(vid=5,pcp=0),3,pop_vlan,push_vlan(vid=1732,pcp=0),1,pop_vlan,7,9,10,15,5,18 recirc_id(0x314123),in_port(8),ct_state(-new+est-rel+rpl-inv+trk),ct_zone(0x5),ct_mark(0),eth(src=fa:16:3e:d2:14:b5,dst=fa:16:3e:6c:f3:09),eth_type(0x0800),ipv4(frag=no), packets:1, bytes:54, used:2.037s, flags:., actions:push_vlan(vid=5,pcp=0),3,pop_vlan,push_vlan(vid=1732,pcp=0),1,pop_vlan,7,9,10,15,5,18 After careful debugging analysis, the openflow action in the flow table 82 added by neutron is the VM port instead of normal. As a result, the ovs br-int bridge cannot learn the mac entry of vm2. table=82, priority=77,ct_state=+new-est,tcp,reg5=0x9,tp_dst=0x4/0xfffc actions=ct(commit,zone=NXM_NX_REG6[0..15]),output:9 table=82, priority=77,ct_state=+est-rel-rpl,tcp,reg5=0x9,tp_dst=0x4/0xfffc actions=output:9 Looking forward to reply thanks. weichun ren

2 1

The outgoing unicast traffic from the VMS enabled in the security group is eventually forwarded to all ports.
by renwc＠chinatelecom.cn 30 May '24

30 May '24

Hello， Here is a description of a bug I encountered using openstack Security Group,If security groups are enabled for virtual nics on VMS, The outgoing traffic from the VMS enabled in the security group should be sent in unicast mode, but it is eventually forwarded to all ports in the vlan on the ovs br-int bridge. Does the openstack open source community have a patch to fix this bug? Can you provide patch fixed the issue? The following is my debugging process in detail. The unicast packet sent by the remote virtual machine 172.83.160.63 to the local virtual machine 172.83.160.74 is passed to the br-ex->br-int-> VM, Because the security group is enabled on the VM NIC, The br-int cannot learn the entry whose port is patch-ex and mac address is vm2. Therefore those packets sent from vm1 to vm2 are broadcast in vlans because they fail to match mac address entries. 172.83.160.74 patch-int 172.83.160.63 vm1 --- ovs(br-int) ------ ovs(br-ex)--- tor(physical switch) ......vm2 patch-ex The following is the ovs kernel flow table. The mac address of vm1 is fa:16:3e:6c:f3:09,The mac address of vm2 is fa:16:3e:d2:14:b5, the action of the flow table is multiple ports. recirc_id(0x314123),in_port(8),ct_state(-new+est-rel-rpl),eth(src=fa:16:3e:d2:14:b5,dst=fa:16:3e:6c:f3:09),eth_type(0x0800),ipv4(proto=6,frag=no),tcp(dst=2048/0xf800), packets:60100, bytes:14257193, used:2.035s, flags:P., actions:push_vlan(vid=5,pcp=0),3,pop_vlan,push_vlan(vid=1732,pcp=0),1,pop_vlan,7,9,10,15,5,18 recirc_id(0x314123),in_port(8),ct_state(-new+est-rel+rpl-inv+trk),ct_zone(0x5),ct_mark(0),eth(src=fa:16:3e:d2:14:b5,dst=fa:16:3e:6c:f3:09),eth_type(0x0800),ipv4(frag=no), packets:1, bytes:54, used:2.037s, flags:., actions:push_vlan(vid=5,pcp=0),3,pop_vlan,push_vlan(vid=1732,pcp=0),1,pop_vlan,7,9,10,15,5,18 After careful debugging analysis, the openflow action in the flow table 82 added by neutron is the VM port instead of normal. As a result, the ovs br-int bridge cannot learn the mac entry of vm2. table=82, priority=77,ct_state=+new-est,tcp,reg5=0x9,tp_dst=0x4/0xfffc actions=ct(commit,zone=NXM_NX_REG6[0..15]),output:9 table=82, priority=77,ct_state=+est-rel-rpl,tcp,reg5=0x9,tp_dst=0x4/0xfffc actions=output:9 Was the issue above fixed in the openstack ? Looking forward to reply thanks. Best Regards weichun ren

1 0

Re: [tc][all][senlin] Retiring the Senlin project
by Ghanshyam Mann 30 May '24

30 May '24

---- On Thu, 30 May 2024 11:43:00 -0700 Sang Tran Quoc wrote --- > > Dear Ghanshyam, > > Greeting! I’m Sang from Viet Nam and now I’m working at the FPT Smart Cloud (Silver member of OpenInfra) as the openstack team leader. We have teammate with about 10 members who maintains the senlin project on our production AutoScaling Feature (my presentation about senlin at last VietOpenInfra summithttps://www.youtube.com/watch?v=aYXDI4mwohQ&t=1s) It’s sad to hear about community retired this project from upstream so I would like to nominate our team to continue maintain this project and I will handle the PTL role for further roadmap, bugs fix and feature. > > Hopefully it’s not late, I’m look forward to hearing from you for further discuss about next chance for senlin project. ++ openstack-discuss ML Hi Sang, Thanks for reaching out and its good to hear about Senlin project usage and your interest in maintaining it. > Hopefully it’s not late, I’m look forward to hearing from you for further discuss about next chance for senlin project. Unfortunately, TC has already retired the Senlin project[1]. Since last cycle, we have been waiting for interested maintainers to step up. * No Leader in 2024.1 cycle ** https://etherpad.opendev.org/p/2024.1-leaderless * After TC discussion, Senlin has been marked as an 'inactive' project since '2024.1' cycle ** https://review.opendev.org/c/openstack/governance/+/902626 ** This was the time we were expecting someone to come forward and step up to maintain it. * No leader for Senlin in 2024.2 cycles also ** https://etherpad.opendev.org/p/2024.2-leaderless * Considering no leader for two cycles, no maintainer, and the process, TC initiated the retirement: ** https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… But this is not the end and Senlin can still re-become the official OpenStack project[2]. For that, you need to re-apply Senlin as a new project in OpenStack, please check the process: - https://governance.openstack.org/tc/reference/new-projects-requirements.html [1] - https://review.opendev.org/c/openstack/governance/+/919347 - https://review.opendev.org/q/topic:%22retire-senlin%22+ [2]https://governance.openstack.org/tc/reference/dropping-projects.html#re-b… -gmann > > > Thanks & Best Regards > > > Sang Tran Quoc (Mr.) > FPT Smart Cloud > FPT Tower, 10 Pham Van Bach Str., Cau Giay Dist., Ha Noi, Viet Nam > E: sangtq8(a)fpt.com > T: 0962949843 > W: https://fptcloud.com | https://fpt.ai > > > > > From:Ghanshyam Mann gmann(a)ghanshyammann.com> > Date: Saturday, 11 May 2024 at 09:06 > To: openstack-discuss openstack-discuss(a)lists.openstack.org> > Subject: Re: [tc][all][senlin] Retiring the Senlin project > ---- On Wed, 24 Apr 2024 13:39:33 -0700 Ghanshyam Mann wrote --- > > Hello everyone, > > > > As you might know, the Senlin project is not active and was marked 'inactive' > > since 2024.1 cycle[1]. In this cycle also, this project is leaderless[2] and no maintainer > > stepped up to maintain it. As discussed in the Leaderless project etherpad[2], the next > > step is to retire the project. > > > > I'm sending this email to propose the Senlin retirement and based on the response, > > I will proceed next. > > Seeing no response to this email or no volunteer to maintain this project, I have proposed > the retirement in governance: > > - https://review.opendev.org/c/openstack/governance/+/919347 > > -gmann > > > > > [1] https://governance.openstack.org/tc/reference/emerging-technology-and-inact… > > [2] https://etherpad.opendev.org/p/2024.2-leaderless#L72 > > > > -gmann > > >

1 0

[neutron][all] OOM killer on coverage job
by Brian Haley 30 May '24

30 May '24

Hi, Neutron has been having issues with our coverage gate job triggering the OOM killer since last week [0], which I just confirmed by holding a node and looking in the logs. It started happening after the sqlalchemy 2.0 bump [1], but that just might be exposing the underlying issue. Running locally I can see via /proc/meminfo that memory is getting consumed: MemTotal: 8123628 kB MemFree: 1108404 kB And via ps it's the coverage processes doing it: PID %MEM RSS PPID TIME NLWP WCHAN COMMAND 4315 30.9 2516348 4314 01:29:07 1 - /opt/stack/neutron/.tox/cover/bin/python /opt/stack/neutron/.tox/cover/bin/coverage run --source neutron --parallel-mode -m stestr.subunit_runner.run discover -t ./ ./neutron/tests/unit --load-list /tmp/tmp0rhqfwhz 4313 30.0 2437500 4312 01:28:50 1 - /opt/stack/neutron/.tox/cover/bin/python /opt/stack/neutron/.tox/cover/bin/coverage run --source neutron --parallel-mode -m stestr.subunit_runner.run discover -t ./ ./neutron/tests/unit --load-list /tmp/tmpfzmqyuub (and the test hasn't even finished yet) Only workaround seems to be reducing concurrency [2]. Have any other projects seen anything similar? (and sorry for the html email) -Brian [0] https://bugs.launchpad.net/neutron/+bug/2065821 [1] https://review.opendev.org/c/openstack/requirements/+/879743 [2] https://review.opendev.org/c/openstack/neutron/+/920766

4 6

A bug about openstack security groups
by renwc＠chinatelecom.cn 29 May '24

29 May '24

hello everyone， Here is a description of a bug I encountered using openstack Security Group,If security groups are enabled for virtual nics on cloud hosts, The outgoing traffic of the VMS enabled in the security group should be sent in unicast mode, but it is eventually forwarded to all ports in the vlan on the ovs br-int bridge. Does the openstack open source community have a patch to fix this bug? Can you provide patch? The following is my debugging process in detail. The unicast packet sent by the remote virtual machine 172.83.160.63 to the local virtual machine 172.83.160.74 is passed to the br-ex->br-int-> VM, Because the security group is enabled on the VM NIC, The br-int cannot learn the entry whose port is patch-ex and mac address is vm2. Therefore those packets sent from vm1 to vm2 are broadcast in vlans because they fail to match mac address entries. 172.83.160.74 patch-int 172.83.160.63 vm1 --- ovs(br-int) ------ ovs(br-ex)--- tor(physical switch) ......vm2 patch-ex The following is the ovs kernel flow table. The mac address of vm1 is fa:16:3e:6c:f3:09,The mac address of vm2 is fa:16:3e:d2:14:b5, the action of the flow table is multiple ports. recirc_id(0x314123),in_port(8),ct_state(-new+est-rel-rpl),eth(src=fa:16:3e:d2:14:b5,dst=fa:16:3e:6c:f3:09),eth_type(0x0800),ipv4(proto=6,frag=no),tcp(dst=2048/0xf800), packets:60100, bytes:14257193, used:2.035s, flags:P., actions:push_vlan(vid=5,pcp=0),3,pop_vlan,push_vlan(vid=1732,pcp=0),1,pop_vlan,7,9,10,15,5,18 recirc_id(0x314123),in_port(8),ct_state(-new+est-rel+rpl-inv+trk),ct_zone(0x5),ct_mark(0),eth(src=fa:16:3e:d2:14:b5,dst=fa:16:3e:6c:f3:09),eth_type(0x0800),ipv4(frag=no), packets:1, bytes:54, used:2.037s, flags:., actions:push_vlan(vid=5,pcp=0),3,pop_vlan,push_vlan(vid=1732,pcp=0),1,pop_vlan,7,9,10,15,5,18 After careful debugging analysis, the openflow action in the flow table 82 added by neutron is the VM port instead of normal. As a result, the ovs br-int bridge cannot learn the mac entry of vm2. table=82, priority=77,ct_state=+new-est,tcp,reg5=0x9,tp_dst=0x4/0xfffc actions=ct(commit,zone=NXM_NX_REG6[0..15]),output:9 table=82, priority=77,ct_state=+est-rel-rpl,tcp,reg5=0x9,tp_dst=0x4/0xfffc actions=output:9 Looking forward to reply thanks. 任维春智能计算产品部/智能云网业务部邮箱：renwc(a)chinatelecom.cn 地址：北京市西城区西直门内大街118-1 中电信数智科技有限公司

1 0

[Diskimage-builder]Supported architectures for creating OS images in Diskimage-builder
by Junya Noguchi (Fujitsu) 29 May '24

29 May '24

To whom it may concern I am investigating which Linux distributions and versions for aarch64 are supported by Diskimage-builder. I found that many newer versions of Linux distributions are supported*, but there is no information about supported architectures in the commit messages. * References: Ubuntu: https://review.opendev.org/c/openstack/project-config/+/916050 RHEL: https://review.opendev.org/c/openstack/diskimage-builder/+/877347 SLES: https://review.opendev.org/c/openstack/diskimage-builder/+/619186 SUSE: https://review.opendev.org/c/openstack/diskimage-builder/+/908421 CentOS: https://review.opendev.org/c/openstack/tripleo-quickstart/+/843102 Does Diskimage-builder support building aarch64 images for those distributions? If not, a list of supported distros for aarch64, would be helpful. Best regards, Junya Noguchi.

2 4

[kolla] cancelling weekly meeting today (29th May 2024)
by Michał Nasiadka 29 May '24

29 May '24

Hello Koalas, We’re cancelling the weekly meeting today (29th May 2024) due to no show of majority key members. Let’s meet next week! Thanks for understanding, Michal

1 0

overcloud deploy fails in step 1 | tripleo | wallaby
by Swogat Pradhan 28 May '24

28 May '24

Hi, I am trying to run a stack update and am executing openstack overcloud deploy, but after reaching step 1 and prefetching the container images the deployment fails with following error: s 2024-05-16 19:58:54.138764 | 525400ff-fd40-2d4d-b69c-000000010c98 | OK | Pre-fetch all the containers | overcloud-controller-1 | item=172.25.201.68:8787/tripleomaster/openstack-cinder-backup:latest 2024-05-16 19:58:54.143338 | 525400ff-fd40-2d4d-b69c-000000010c98 | TIMING | Pre-fetch all the containers | overcloud-controller-1 | 0:23:18.464385 | 43.62s An exception occurred during task execution. To see the full traceback, use -vvv. The error was: KeyError: 'config' s/_base.py\", line 384, in __get_result\n raise self._exception\n File \"/usr/lib64/python3.6/concurrent/futures/thread.py\", line 56, in run\n result = self.fn(*self.args, **self.kwargs)\n File \"/tmp/ansible_tripleo_container_manage_payload_sg7woby1/ansible_tripleo_container_manage_payload.zip/ansible/modules/tripleo_container_manage.py\", line 332, in run_container\n File \"/tmp/ansible_tripleo_container_manage_payload_sg7woby1/ansible_tripleo_container_manage_payload.zip/ansible/modules/tripleo_container_manage.py\", line 318, in manage_container\n File \"/tmp/ansible_tripleo_container_manage_payload_sg7woby1/ansible_tripleo_container_manage_payload.zip/ansible_collections/containers/podman/plugins/module_utils/podman/podman_container_lib.py\", line 1659, in execute\n File \"/tmp/ansible_tripleo_container_manage_payload_sg7woby1/ansible_tripleo_container_manage_payload.zip/ansible_collections/containers/podman/plugins/module_utils/podman/podman_container_lib.py\", line 1572, in make_started\n File \"/tmp/ansible_tripleo_container_manage_payload_sg7woby1/ansible_tripleo_container_manage_payload.zip/ansible_collections/containers/podman/plugins/module_utils/podman/podman_container_lib.py\", line 1351, in different\n File \"/tmp/ansible_tripleo_container_manage_payload_sg7woby1/ansible_tripleo_container_manage_payload.zip/ansible_collections/containers/podman/plugins/module_utils/podman/podman_container_lib.py\", line 692, in __init__\n File \"/tmp/ansible_tripleo_container_manage_payload_sg7woby1/ansible_tripleo_container_manage_payload.zip/ansible_collections/containers/podman/plugins/module_utils/podman/podman_container_lib.py\", line 699, in defaultize\n File \"/tmp/ansible_tripleo_container_manage_payload_sg7woby1/ansible_tripleo_container_manage_payload.zip/ansible_collections/containers/podman/plugins/module_utils/podman/podman_container_lib.py\", line 661, in __init__\nKeyError: 'config'\n", "module_stdout": "", "msg": "MODULE FAILURE\nSee st2024-05-16 19:58:55.487682 | 525400ff-fd40-2d4d-b69c-000000010b27 | FATAL | Manage Puppet containers (generate config) for step 1 | overcloud-novacompute-3 | error={"changed": false, "module_stderr": "Traceback (most recent call last):\n File \"<stdin>\", line 102, in <module>\n File \"<stdin>\", line 94, in _ansiballz_main\n File \"<stdin>\", line 40, in invoke_module\n File \"/usr/lib64/python3.6/runpy.py\", line 205, in run_module\n return _run_module_code(code, init_globals, run_name, mod_spec)\n File \"/usr/lib64/python3.6/runpy.py\", line 96, in _run_module_code\n mod_name, mod_spec, pkg_name, script_name)\n File \"/usr/lib64/python3.6/runpy.py\", line 85, in _run_code\n exec(code, run_globals)\n File \"/tmp/ansible_tripleo_container_manage_payload_sg7woby1/ansible_tripleo_container_manage_payload.zip/ansible/modules/tripleo_container_manage.py\", line 391, in <module>\n File \"/tmp/ansible_tripleo_container_manage_payload_sg7woby1/ansible_tripleo_container_manage_payload.zip/ansible/modules/tripleo_container_manage.py\", line 387, in main\n File \"/tmp/ansible_tripleo_container_manage_payload_sg7woby1/ansible_tripleo_container_manage_payload.zip/ansible/modules/tripleo_container_manage.py\", line 132, in __init__\n File \"/tmp/ansible_tripleo_container_manage_payload_sg7woby1/ansible_tripleo_container_manage_payload.zip/ansible/modules/tripleo_container_manage.py\", line 370, in run\n File \"/tmp/ansible_tripleo_container_manage_payload_sg7woby1/ansible_tripleo_container_manage_payload.zip/ansible/modules/tripleo_container_manage.py\", line 337, in check_failures\n File \"/usr/lib64/python3.6/concurrent/futures/_base.py\", line 586, in result_iterator\n yield fs.pop().result()\n File \"/usr/lib64/python3.6/concurrent/futures/_base.py\", line 425, in result\n return self.__get_result()\n File \"/usr/lib64/python3.6/concurrent/futures/_base.py\", line 384, in __get_result\n raise self._exception\n File \"/usr/lib64/python3.6/concurrent/futures/thread.py\", line 56, in run\n result = self.fn(*self.args, **self.kwargs)\n File \"/tmp/ansible_tripleo_container_manage_payload_sg7woby1/ansible_tripleo_container_manage_payload.zip/ansible/modules/tripleo_container_manage.py\", line 332, in run_container\n File \"/tmp/ansible_tripleo_container_manage_payload_sg7woby1/ansible_tripleo_container_manage_payload.zip/ansible/modules/tripleo_container_manage.py\", line 318, in manage_container\n File \"/tmp/ansible_tripleo_container_manage_payload_sg7woby1/ansible_tripleo_container_manage_payload.zip/ansible_collections/containers/podman/plugins/module_utils/podman/podman_container_lib.py\", line 1659, in execute\n File \"/tmp/ansible_tripleo_container_manage_payload_sg7woby1/ansible_tripleo_container_manage_payload.zip/ansible_collections/containers/podman/plugins/module_utils/podman/podman_container_lib.py\", line 1572, in make_started\n File \"/tmp/ansible_tripleo_container_manage_payload_sg7woby1/ansible_tripleo_container_manage_payload.zip/ansible_collections/containers/podman/plugins/module_utils/podman/podman_container_lib.py\", line 1351, in different\n File \"/tmp/ansible_tripleo_container_manage_payload_sg7woby1/ansible_tripleo_container_manage_payload.zip/ansible_collections/containers/podman/plugins/module_utils/podman/podman_container_lib.py\", line 692, in __init__\n File \"/tmp/ansible_tripleo_container_manage_payload_sg7woby1/ansible_tripleo_container_manage_payload.zip/ansible_collections/containers/podman/plugins/module_utils/podman/podman_container_lib.py\", line 699, in defaultize\n File \"/tmp/ansible_tripleo_container_manage_payload_sg7woby1/ansible_tripleo_container_manage_payload.zip/ansible_collections/containers/podman/plugins/module_utils/podman/podman_container_lib.py\", line 661, in __init__\nKeyError: 'config'\n", "module_stdout": "", "msg": "MODULE FAILURE\nSee stdout/stderr for the exact error", "rc": 1} 2024-05-16 19:58:55.488510 | 525400ff-fd40-2d4d-b69c-000000010b27 | TIMING | Manage Puppet containers (generate config) for step 1 | overcloud-novacompute-3 | 0:23:19.809572 | 82.91s 2024-05-16 19:58:55.859707 | 525400ff-fd40-2d4d-b69c-000000010c98 | OK | Pre-fetch all the containers | overcloud-controller-1 | item=172.25.201.68:8787/tripleomaster/openstack-cinder-volume:latest 2024-05-16 19:58:55.864370 | 525400ff-fd40-2d4d-b69c-000000010c98 | TIMING | Pre-fetch all the containers | overcloud-controller-1 | 0:23:20.185418 | 45.34s 2024-05-16 19:58:57.659959 | 525400ff-fd40-2d4d-b69c-000000010c98 | OK | Pre-fetch all the containers | overcloud-controller-1 | item=172.25.201.68:8787/tripleomaster/openstack-iscsid:latest 2024-05-16 19:58:57.664429 | 525400ff-fd40-2d4d-b69c-000000010c98 | TIMING | Pre-fetch all the containers | overcloud-controller-1 | 0:23:21.985477 | 47.14s 2024-05-16 19:59:00.211286 | 525400ff-fd40-2d4d-b69c-000000010c98 | OK | Pre-fetch all the containers | overcloud-controller-1 | item=172.25.201.68:8787/tripleomaster/openstack-manila-share:latest 2024-05-16 19:59:00.216236 | 525400ff-fd40-2d4d-b69c-000000010c98 | TIMING | Pre-fetch all the containers | overcloud-controller-1 | 0:23:24.537284 | 49.69s 2024-05-16 19:59:02.113037 | 525400ff-fd40-2d4d-b69c-000000010c98 | OK | Pre-fetch all the containers | overcloud-controller-1 | item=172.25.201.68:8787/tripleomaster/openstack-aodh-evaluator:latest 2024-05-16 19:59:02.117498 | 525400ff-fd40-2d4d-b69c-000000010c98 | TIMING | Pre-fetch all the containers | overcloud-controller-1 | 0:23:26.438544 | 51.59s 2024-05-16 19:59:03.853383 | 525400ff-fd40-2d4d-b69c-000000010c98 | OK | Pre-fetch all the containers | overcloud-controller-1 | item=172.25.201.68:8787/tripleomaster/openstack-aodh-listener:latest 2024-05-16 19:59:03.858232 | 525400ff-fd40-2d4d-b69c-000000010c98 | TIMING | Pre-fetch all the containers | overcloud-controller-1 | 0:23:28.179287 | 53.33s 2024-05-16 19:59:05.665169 | 525400ff-fd40-2d4d-b69c-000000010c98 | OK | Pre-fetch all the containers | overcloud-controller-1 | item=172.25.201.68:8787/tripleomaster/openstack-aodh-notifier:latest 2024-05-16 19:59:05.670233 | 525400ff-fd40-2d4d-b69c-000000010c98 | TIMING | Pre-fetch all the containers | overcloud-controller-1 | 0:23:29.991278 | 55.14s An exception occurred during task execution. To see the full traceback, use -vvv. The error was: KeyError: 'config' /futures/_base.py\", line 384, in __get_result\n raise self._exception\n File \"/usr/lib64/python3.6/concurrent/futures/thread.py\", line 56, in run\n result = self.fn(*self.args, **self.kwargs)\n File \"/tmp/ansible_tripleo_container_manage_payload_wnnokrwc/ansible_tripleo_container_manage_payload.zip/ansible/modules/tripleo_container_manage.py\", line 332, in run_container\n File \"/tmp/ansible_tripleo_container_manage_payload_wnnokrwc/ansible_tripleo_container_manage_payload.zip/ansible/modules/tripleo_container_manage.py\", line 318, in manage_container\n File \"/tmp/ansible_tripleo_container_manage_payload_wnnokrwc/ansible_tripleo_container_manage_payload.zip/ansible_collections/containers/podman/plugins/module_utils/podman/podman_container_lib.py\", line 1659, in execute\n File \"/tmp/ansible_tripleo_container_manage_payload_wnnokrwc/ansible_tripleo_container_manage_payload.zip/ansible_collections/containers/podman/plugins/module_utils/podman/podman_container_lib.py\", line 1572, in make_started\n File \"/tmp/ansible_tripleo_container_manage_payload_wnnokrwc/ansible_tripleo_container_manage_payload.zip/ansible_collections/containers/podman/plugins/module_utils/podman/podman_container_lib.py\", line 1351, in different\n File \"/tmp/ansible_tripleo_container_manage_payload_wnnokrwc/ansible_tripleo_container_manage_payload.zip/ansible_collections/containers/podman/plugins/module_utils/podman/podman_container_lib.py\", line 692, in __init__\n File \"/tmp/ansible_tripleo_container_manage_payload_wnnokrwc/ansible_tripleo_container_manage_payload.zip/ansible_collections/containers/podman/plugins/module_utils/podman/podman_container_lib.py\", line 699, in defaultize\n File \"/tmp/ansible_tripleo_container_manage_payload_wnnokrwc/ansible_tripleo_container_manage_payload.zip/ansible_collections/containers/podman/plugins/module_utils/podman/podman_container_lib.py\", line 661, in __init__\nKeyError: 'config'\n", "module_stdout": "", "msg": "MODULE FAILURE\2024-05-16 19:59:06.648301 | 525400ff-fd40-2d4d-b69c-000000010fc3 | FATAL | Manage Puppet containers (generate config) for step 1 | overcloud-controller-no-ceph-3 | error={"changed": false, "module_stderr": "Traceback (most recent call last):\n File \"<stdin>\", line 102, in <module>\n File \"<stdin>\", line 94, in _ansiballz_main\n File \"<stdin>\", line 40, in invoke_module\n File \"/usr/lib64/python3.6/runpy.py\", line 205, in run_module\n return _run_module_code(code, init_globals, run_name, mod_spec)\n File \"/usr/lib64/python3.6/runpy.py\", line 96, in _run_module_code\n mod_name, mod_spec, pkg_name, script_name)\n File \"/usr/lib64/python3.6/runpy.py\", line 85, in _run_code\n exec(code, run_globals)\n File \"/tmp/ansible_tripleo_container_manage_payload_wnnokrwc/ansible_tripleo_container_manage_payload.zip/ansible/modules/tripleo_container_manage.py\", line 391, in <module>\n File \"/tmp/ansible_tripleo_container_manage_payload_wnnokrwc/ansible_tripleo_container_manage_payload.zip/ansible/modules/tripleo_container_manage.py\", line 387, in main\n File \"/tmp/ansible_tripleo_container_manage_payload_wnnokrwc/ansible_tripleo_container_manage_payload.zip/ansible/modules/tripleo_container_manage.py\", line 132, in __init__\n File \"/tmp/ansible_tripleo_container_manage_payload_wnnokrwc/ansible_tripleo_container_manage_payload.zip/ansible/modules/tripleo_container_manage.py\", line 370, in run\n File \"/tmp/ansible_tripleo_container_manage_payload_wnnokrwc/ansible_tripleo_container_manage_payload.zip/ansible/modules/tripleo_container_manage.py\", line 337, in check_failures\n File \"/usr/lib64/python3.6/concurrent/futures/_base.py\", line 586, in result_iterator\n yield fs.pop().result()\n File \"/usr/lib64/python3.6/concurrent/futures/_base.py\", line 425, in result\n return self.__get_result()\n File \"/usr/lib64/python3.6/concurrent/futures/_base.py\", line 384, in __get_result\n raise self._exception\n File \"/usr/lib64/python3.6/concurrent/futures/thread.py\", line 56, in run\n result = self.fn(*self.args, **self.kwargs)\n File \"/tmp/ansible_tripleo_container_manage_payload_wnnokrwc/ansible_tripleo_container_manage_payload.zip/ansible/modules/tripleo_container_manage.py\", line 332, in run_container\n File \"/tmp/ansible_tripleo_container_manage_payload_wnnokrwc/ansible_tripleo_container_manage_payload.zip/ansible/modules/tripleo_container_manage.py\", line 318, in manage_container\n File \"/tmp/ansible_tripleo_container_manage_payload_wnnokrwc/ansible_tripleo_container_manage_payload.zip/ansible_collections/containers/podman/plugins/module_utils/podman/podman_container_lib.py\", line 1659, in execute\n File \"/tmp/ansible_tripleo_container_manage_payload_wnnokrwc/ansible_tripleo_container_manage_payload.zip/ansible_collections/containers/podman/plugins/module_utils/podman/podman_container_lib.py\", line 1572, in make_started\n File \"/tmp/ansible_tripleo_container_manage_payload_wnnokrwc/ansible_tripleo_container_manage_payload.zip/ansible_collections/containers/podman/plugins/module_utils/podman/podman_container_lib.py\", line 1351, in different\n File \"/tmp/ansible_tripleo_container_manage_payload_wnnokrwc/ansible_tripleo_container_manage_payload.zip/ansible_collections/containers/podman/plugins/module_utils/podman/podman_container_lib.py\", line 692, in __init__\n File \"/tmp/ansible_tripleo_container_manage_payload_wnnokrwc/ansible_tripleo_container_manage_payload.zip/ansible_collections/containers/podman/plugins/module_utils/podman/podman_container_lib.py\", line 699, in defaultize\n File \"/tmp/ansible_tripleo_container_manage_payload_wnnokrwc/ansible_tripleo_container_manage_payload.zip/ansible_collections/containers/podman/plugins/module_utils/podman/podman_container_lib.py\", line 661, in __init__\nKeyError: 'config'\n", "module_stdout": "", "msg": "MODULE FAILURE\nSee stdout/stderr for the exact error", "rc": 1} I do not have any idea why this is caused and how to fix it. Can someone please help? With regards, Swogat Pradhan

4 9

OpenInfra Summit Asia'24 CFP closes tomorrow (May 29)!
by Jeremy Stanley 28 May '24

28 May '24

I'll refer you back to my reminder from two weeks ago for details: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… The Summit CFP is still accepting talk proposals through tomorrow, May 29, 2024. If you're interested in presenting in Korea this September, the time to submit your abstract is now! https://openinfrafoundation.formstack.com/forms/openinfra_asia_summit_2024 As always, reply or find me (fungi) in the #openstack channel on the OFTC IRC network if you have questions. -- Jeremy Stanley

1 0

DevStack Setup
by Lohit S 28 May '24

28 May '24

Hi Team, I had tried to execute the ./stack.sh in devstack repo But I got the following error, How to fix this issue. +lib/neutron_plugins/ovn_agent:ovn_sanity_check:358 die 358 'The q-agt/neutron-agt service must be disabled with OVN.' +functions-common:die:285 local exitcode=0 +functions-common:die:286 set +o xtrace [Call Trace] ./stack.sh:979:stack_install_service /home/lohit22/opensource/openstack/devstack/Org/devstack/lib/stack:32:install_neutron /home/lohit22/opensource/openstack/devstack/Org/devstack/lib/neutron:551:install_ovn /home/lohit22/opensource/openstack/devstack/Org/devstack/lib/neutron_plugins/ovn_agent:373:ovn_sanity_check /home/lohit22/opensource/openstack/devstack/Org/devstack/lib/neutron_plugins/ovn_agent:358:die [ERROR] /home/lohit22/opensource/openstack/devstack/Org/devstack/lib/neutron_plugins/ovn_agent:358 The q-agt/neutron-agt service must be disabled with OVN. Error on exit World dumping... see /opt/stack/logs/worlddump-2024-05-26-053930.txt for details

3 7

[neutron] Bug deputy report for week of May 20th
by Brian Haley 28 May '24

28 May '24

Hi, I was Neutron bug deputy last week. Below is a short summary about the reported bugs. -Brian Critical bugs ------------- * None High bugs --------- * https://bugs.launchpad.net/neutron/+bug/2066221 - [dalmatian] skip level grenade jobs fails at keystone-manage db_sync - https://review.opendev.org/c/openstack/neutron/+/920075 * https://bugs.launchpad.net/neutron/+bug/2066263 - functional tests broken with ovsdbapp 2.7.1 - https://review.opendev.org/c/openstack/neutron/+/920101 * https://bugs.launchpad.net/neutron/+bug/2066369 - Validation of the auto allocated topology for member/reader user don't works with new S-RBAC policies - https://review.opendev.org/c/openstack/neutron/+/920174 - https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/920177 * https://bugs.launchpad.net/python-neutronclient/+bug/2067039 - openstack bgp [dragent|speaker] list filter commands dont return - Possibly related to the change to use OpenstackSDK code in https://review.opendev.org/c/openstack/python-neutronclient/+/868321 - Asked to make sure all libraries were updated - Might need further investigation by Lajos Medium bugs ----------- * https://bugs.launchpad.net/neutron/+bug/2066989 - Virtual function is being attached to port regardless of the exclude_devices configuration - Asked for more information * https://bugs.launchpad.net/neutron/+bug/2067183 - Properly Use Network's DNS Domain in Assignment and DHCP - https://review.opendev.org/c/openstack/neutron/+/920459 - I'd like to discuss at Neutron meeting since we've broken things like this in the past Low bugs -------- * None Misc bugs --------- * None Wishlist bugs ------------- * https://bugs.launchpad.net/nova/+bug/2065790 - Nova fails to live migrate instance with dash separated MAC - Request for Neutron to always use :" in MACs, even if API given "-" - Will have to discuss at weekly meeting, I'm inclined to document around it

1 0

[publiccloud-sig] Reminder - next meeting May 29th - 0700 UTC
by Felix Kronlage-Dammers 28 May '24

28 May '24

Hi everyone, This Wednesday (May 29th, tomorrow) the next meeting of the public cloud sig is going to happen. We’ll be meeting at 0700 UTC here: https://meetpad.opendev.org/publiccloud-sig See also here for all other details: https://wiki.openstack.org/wiki/PublicCloudSIG Likely we will pick up the discussions from our Forum Session at OID Berlin. See my summary that I sent to this list[1]. See you tomorrow! felix [1] <url: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack…> -- Felix Kronlage-Dammers Sovereign Cloud Stack — standardized, built and operated by many Ein Projekt der Open Source Business Alliance - Bundesverband für digitale Souveränität e.V. Tel.: +49-30-206539-205 | Matrix: @fkronlage:matrix.org | fkr(a)osb-alliance.com

1 0

Re: [Octavia] octavia not setting up load balancers
by Jaime Ibar 28 May '24

28 May '24

Hi, I have set debug to true and I can see the following but not sure if they're related though Disabling service 'block-storage': Encountered an exception attempting to process config for project 'cinder' (service type 'block-storage'): no such option valid_interfaces in group [cinder]: oslo_config.cfg.NoSuchOptError: no such option valid_interfaces in group [cinder] Disabling service 'compute': Encountered an exception attempting to process config for project 'nova' (service type 'compute'): no such option valid_interfaces in group [nova]: oslo_config.cfg.NoSuchOptError: no such option valid_interfaces in group [nova] 2024-05-27 19:09:32.136 225246 WARNING openstack [None req-588327db-96d5-4377-ba72-b603731f9568 - c2270ba97baa40cbbb17f89d6980a2d6 - - default default] Disabling service 'image': Encountered an exception attempting to process config for project 'glance' (service type 'image'): no such option valid_interfaces in group [glance]: oslo_config.cfg.NoSuchOptError: no such option valid_interfaces in group [glance] Jaime On 27/05/2024 21:20, Winicius Allan wrote: > I understood. Is there any error log level message or anything like that? > > Em seg., 27 de mai. de 2024 às 15:19, Jaime Ibar <jim2k7(a)gmail.com> > escreveu: > > Hi Winicius, > > yes, I have the Octavia:health-mgr interface and it shows as > Active and up, in fact, I can ssh into the amphora from > the management network. > > Thanks > Jaime > > On Mon, 27 May 2024 at 18:54, Winicius Allan > <winiciusab12(a)gmail.com> wrote: > > Hi Jaime, > > In general, a load balancer stuck in the PENDING_CREATE state > could be a network problem. Do you have a network interface on > your control node that belongs to the same network as Amphora? > > Regards. > > Em seg., 27 de mai. de 2024 às 12:51, Jaime Ibar > <jim2k7(a)gmail.com> escreveu: > > Nope, I can't see anything. > > This is what I can see > > [...] > request url / request > /usr/lib/python3/dist-packages/octavia/amphorae/drivers/haproxy/rest_api_driver.py:652 > request url https://172.16.4.56:9443// request > /usr/lib/python3/dist-packages/octavia/amphorae/drivers/haproxy/rest_api_driver.py:655 > Connected to amphora. Response: <Response [200]> request > /usr/lib/python3/dist-packages/octavia/amphorae/drivers/haproxy/rest_api_driver.py:677 > Amphora f3809732-80d8-4795-a5cb-cb36e63bc895 has API > version 1.0 _populate_amphora_api_version > /usr/lib/python3/dist-packages/octavia/amphorae/drivers/haproxy/rest_api_driver.py:104 > > Update DB for loadbalancer id > Marking all listeners of loadbalancer > ce31155c-3484-4ff0-8740-fcd8c0915a1c ACTIVE execute > > Mark ACTIVE in DB for load balancer id: > [...] > > So all seems to be OK but nothing in the amphora. > > Thanks > Jaime > > On Mon, 27 May 2024 at 16:25, Oliver Weinmann > <oliver.weinmann(a)me.com> wrote: > > Ok, anything suspicious in the Octavia worker logs? > > Von meinem iPhone gesendet > >> Am 27.05.2024 um 17:17 schrieb Jaime Ibar >> <jim2k7(a)gmail.com>: >> >> >> Hi Oliver, >> >> thanks for the tip but after increasing the quotas, >> the problem persists :( >> >> Jaime >> >> On Mon, 27 May 2024 at 12:20, Oliver Weinmann >> <oliver.weinmann(a)me.com> wrote: >> >> Hi, >> >> Just a quick guess. Check the quotas for security >> groups of the service tenant. >> >> In our deployment we had a similar issue and saw >> errors indicating this in the logs. >> >> Cheers, >> Oliver >> >> Von meinem iPhone gesendet >> >> > Am 27.05.2024 um 13:16 schrieb Jaime Ibar >> <jim2k7(a)gmail.com>: >> > >> > >> > Hi all, >> > >> > I've been running Octavia with no issues so far >> and now it stopped working >> > with no reasons(no recent upgrades other that OS). >> > When I create a load balancer, sometimes the >> amphora is launched successfully >> > but some others is not. >> > When it's launched, no listeners, backends, >> pools are created and the load balancer >> > gets stuck in either, pending create or pending >> update state, and deleting all the >> > load balancer details from the database is the >> only option of getting rid of it. >> > >> > I can ssh into the amphora but I can't see any >> error, gunicorn is listening >> > on port 9443 but no haproxy instances are >> created(haproxy-<uuid>) on >> > /var/lib/octavia >> > >> > I'm running 2023.2 Bobcat version. >> > >> > Any ideas? >> > >> > TIA >> > Jaime >> > >> > -- >> > salu2 >> > >> > Jaime >> >> >> >> -- >> salu2 >> >> Jaime > > > > -- > salu2 > > Jaime > > > > -- > salu2 > > Jaime > -- Jaime

1 0

[Tempest] [Blazar] Connection Refused Error 111 on Blazar tempest plugin
by Tran, Kenny 28 May '24

28 May '24

First time asking a question on the mailing list, I am trying to set up tempest against a quick start yoga (kolla-ansible) deployment with Keystone, Zun, Heat, Blazar, and Nova (1 controller, 1 compute). Default tempest tests are behaving as expected but when I try to run the blazar plugin tests they fail with Errno 111 Connection Refused. I ran a tcpdump on the tempest server side and saw no issues. Tcpdump on controller showed a reset when trying to connect to keystone. Is this an issue with blazar not being able to authenticate against the openstack deployment? The default tempest tests succeed so I don't think my admin_password admin_username etc. are incorrect. Kenny Tran Iowa State University Student Computer Engineer 515-441-5237 | trantk(a)iastate.edu

2 1

[Octavia] octavia not setting up load balancers
by Jaime Ibar 27 May '24

27 May '24

Hi all, I've been running Octavia with no issues so far and now it stopped working with no reasons(no recent upgrades other that OS). When I create a load balancer, sometimes the amphora is launched successfully but some others is not. When it's launched, no listeners, backends, pools are created and the load balancer gets stuck in either, pending create or pending update state, and deleting all the load balancer details from the database is the only option of getting rid of it. I can ssh into the amphora but I can't see any error, gunicorn is listening on port 9443 but no haproxy instances are created(haproxy-<uuid>) on /var/lib/octavia I'm running 2023.2 Bobcat version. Any ideas? TIA Jaime -- salu2 Jaime

3 7

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

27 May '24

Hello Stackers, We're 18 weeks away from the 2024.2 (Dalmatian) release [1]. The Call for Proposals for the upcoming Open Infra Summit is still open [2], but it will close in a couple of days (May 29th, 2024). If you're planning to attend, I encourage you to submit a talk! In the past week, the OpenStack Technical Committee continued its spring cleaning exercise – this time, the party was on PyPi. We also identified dates for the TC and PTL elections for the 2025.1 ("E") release cycle [3]. The nomination period for the TC and PTL elections will begin on 2024-08-14 at 23:45 UTC and will conclude on 2024-08-28 at 23:45 UTC. The elections will be held between 23:45 UTC on 2024-09-04 and 23:45 UTC on 2024-09-18. === Weekly Meeting === We identified 207 maintainers for removal across 146 PyPi packages [4]. The cleanup task is large and manual due to a lack of API. We've also identified packages where "openstackci" cannot remove maintainers due to a lack of ownership. This is likely a long-drawn effort. I'll keep you posted as we make progress. We had a few remaining project updates pending from the last release cycle, and one of them concerned the OpenStack Charms team. Since the TC didn't have context on the health of the team and its plans, we decided to gather some information on this mailing list. We're also excited to publish the first draft for the next election dates/process, courtesy of our Election Official, Ian Y. Choi (ianychoi). This election will be socialized with early and periodic notifications to address concerns expressed regarding the lack of visibility and poor voter turnout in past elections. This meeting, like all of our IRC meetings, was logged to eavesdrop [5]. Our next weekly IRC meeting is tomorrow! The agenda is pretty light [6], likely owing to the fact that a few TC members are returning from a long weekend holiday. === Governance Proposals === ==== Merged ==== Retire devstack-gate | https://review.opendev.org/c/openstack/governance/+/919629 ==== Open for review/discussion ==== Appoint ChunYang Wu as PTL of Trove | https://review.opendev.org/c/openstack/governance/+/920462 Clarify the project retirement vs. project's repository retirement | https://review.opendev.org/c/openstack/governance/+/919984 Simplifying house rules for project updates | https://review.opendev.org/c/openstack/governance/+/920318 Update to include docs and miscellaneous repos for AC status | https://review.opendev.org/c/openstack/governance/+/915021 Add DPL model & liaison reset policy | https://review.opendev.org/c/openstack/governance/+/916833 Thank you very much for reading! On behalf of the OpenStack TC, Goutham Pacha Ravi (gouthamr) OpenStack TC Chair [1] https://releases.openstack.org/dalmatian/schedule.html [2] https://2024.openinfraasia.org/ [3] https://review.opendev.org/c/openstack/election/+/920092 [4] https://etherpad.opendev.org/p/openstack-pypi-maintainers-cleanup#L52 [5] https://meetings.opendev.org/meetings/tc/2024/tc.2024-05-21-18.00.log.html [6] https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting

1 0

How to assign an ip-address to a server on creation
by Nine, Harmon S 27 May '24

27 May '24

Hello. I'm using the openstack connection api in python to create a server. The server is getting created, but the "create_server" call is not assigning the ip-address to the server that is specified in the call. flavor_id = 'ed88b5d6-150d-4715-8de0-8a2df0a1746a' image_id = '399ae60e-7f73-476e-aad7-13aebcad84a1' networks = [{'uuid': '978ebb40-8ee4-4c0b-932e-83dce7e182dd'}] ip_addresses =[{'subnet_id': '978ebb40-8ee4-4c0b-932e-83dce7e182dd', 'ip_address': '10.0.0.153'}] # also tried ip_addresses = ['10.0.0.153'] instance = conn.compute.create_server( name='testmachine', flavor_id=flavor_id, image_id=image_id, ips=ip_addresses, networks=network_uuid_list, key_name='key_name' ) What is the format of the "ips" argument? Are there other arguments that need to be specified? Thanks for any help you can provide 🙂 -- Harmon

3 5

[kolla][OpenstackAnsible] 2024.1 Caracal cycle-trailing release deadline reminder
by Herve Beraud 27 May '24

27 May '24

Hello teams with trailing projects, The 2024.1 Caracal cycle-trailing release deadline is next week [1], and all projects following the cycle-trailing release model must release their 2024.1 Caracal deliverables by June 6th, 2024. The following trailing projects haven't been released yet for 2024.1 Caracal, convenience patches have been proposed: OSA team's deliverables: - https://review.opendev.org/c/openstack/releases/+/919484 - https://review.opendev.org/c/openstack/releases/+/919483 Kolla team's deliverables: - https://review.opendev.org/c/openstack/releases/+/919486 This is just a friendly reminder to allow you to release these projects in time. Please, ensure to provide feedback or to update these patches before the deadline. Do not hesitate to ping us if you have any questions or concerns. [1] https://releases.openstack.org/dalmatian/schedule.html#d-cycle-trail Thanks, -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/

1 0

[nova][scheduler] nova scheduler to balance vms more randomly
by Satish Patel 27 May '24

27 May '24

Folks, I have noticed when I spin up a bunch of vms then they all go to the same hypervisor until it runs out of resources. I can understand that it's trying to fill the hypervisor before it picks the next one. But it's kind of dangerous behavior. For example one customer created 3 vms to build a mysql galera cluster and all those 3 nodes endup on the same hypervisor (This is dangerous). I would like openstack to pick the hypervisor more randomly if resources are available in the pool instead of trying to fill the hypervisor. How do I change that behavior? ( There is a feature called affinity but again I would like nova to place vm more randomly instead shaving all to a single node). I am not an expert in scheduler logic so please educate me if I am missing something here.

5 5

Difficulty Create/Upload Images
by Cakra Wirabuana 24 May '24

24 May '24

Hi everyone, I have a difficulty when creating image. I have downloaded the file with both .img and .iso formats and I have tried various format options (QCOW2, RAW, ISO, etc) but it still fails and a notification appears as in the image I attached to this email. Does anyone know the cause of this and what is the solution? If it turns out that I have to create an image via CLI, how do I do it? I am using Ubuntu 22.04.4 LTS. Thank you, Cakra Wirabuana [image: image.png]

2 1

[openstack][magnum] Error with QueuePool limit of size
by Nguyễn Hữu Khôi 23 May '24

23 May '24

Hello. I am using Magnum 18.0.0.0rc2.dev2 in OPS 2024.01 with Magnum-Cluster-API(0.17.0) from Vexxhost. But I have these errors as: Ignore error [QueuePool limit of size 1 overflow 50 reached, connection timed out, timeout 30.00 (Background on this error at: https://sqlalche.me/e/14/3o7r) when syncing up cluster status.: sqlalchemy.exc.TimeoutError: QueuePool limit of size 1 overflow 50 reached, connection timed out, timeout 30.00 Full log is in: https://paste.sh/gWg28T2s#zctJBJsW34bX9pG705VR5PMP Thank you. Nguyen Huu Khoi

2 2

[trove][tc] Next step on leaderless project Trove
by Ghanshyam Mann 23 May '24

23 May '24

Hi Wu, This is regarding the Trove project leader assignment. We saw your late candidacy for Trove PTL[1]. The TC has listed Trove as a late candidacy project[2] and can consider a PTL appointment. If you are still interested in serving as Trove PTL, please propose the PTL appointment request to TC. Example: https://review.opendev.org/c/openstack/governance/+/915108 [1] https://review.opendev.org/c/openstack/election/+/910488 [2] https://etherpad.opendev.org/p/2024.2-leaderless#L99 -gmann

1 1

cpu steal
by Gk Gk 22 May '24

22 May '24

Hi, If we create pinned vms, is there a chance of cpu steal in this scenario ? If so what could be the reason since we have dedicated cpu assigned to the guest ? What would happen if it is a physical cpu, directly assigned to the vm ? Does it experience cpu steal in this case as well ? Thanks GK

2 2

[Glance] Cancelling Weekly Meeting (23rd May)
by Pranali Deore 22 May '24

22 May '24

Hello, Since I won't be able to chair tomorrow's meeting due to my PTO, cancelling the same. See you next week! Thanks, Pranali Deore

1 0