September 2024 - openstack-discuss

[all][dev][ops][tc] Bridging the gap between community and contributing orgs
by Jeremy Stanley 25 Apr '25

25 Apr '25

The tl;dr on this is that I'm opening a broad community discussion on how we can, collectively through improved communication, better bring together our established contributors with casual and prospective contributors who struggle to find successful patterns of contribution, so that we might all support each other in order to benefit OpenStack as a whole. Read on for details... OpenStack's TC has requested that foundation staff, when in conversation with representatives of member organizations, encourage participation in the project and collect feedback on any related challenges those organizations encounter in their attempts to do so. In order to better understand the feedback and brainstorm achievable recommendations for the broader community[*], Community Managers on the foundation staff started to work with a small focus group of established contributors with a solid understanding of what successful patterns of contribution look like. It also came to light that established contributors experience many of the same sorts of challenges, even more so if they don't have the luxury of focusing full-time upstream, and so success often comes down to knowing how to effectively navigate those challenges. The community's goal with this exercise is to improve everyone's experience, and your help is needed to do that! The most common themes reported by those struggling to contribute are not related to tooling or workflow confusion, but instead seem to come down to basic communication challenges. Ideas so far to address these gaps include: * Review bandwidth - Ensure contributors and companies understand the importance and benefits of code review - Incentivize and credit meaningful "+1" reviews more - Understand that the volume of changes and limited reviewer bandwidth often means proposals aren't reviewed quickly (or at all), and their proponents may need some additional tenacity and engagement with the team to get their work noticed - Utilize "review dashboards" as a way to find stale changes which have fallen through the cracks * Review strategy and etiquette - Be clear about the meaning of votes on changes, especially negative ones, and set explicit timelines for things like "procedural -2" or WIP blocks when their approval needs to be delayed - Focus on comments and requests that affect whether or not the change can be merged after the fixes are submitted, rather than requesting trivial adjustments to an unsuitable change which has more fundamental problems - Reciprocate with reviews of changes from new reviewers you see leaving insubstantial reviews, demonstrating to them what deeper and more meaningful reviewing looks like * Mentoring newcomers - Established contributors with sufficient bandwidth can help mentoring newcomers, potential core reviewers and new leaders - Mentoring can happen as part of internship programs as well as by helping newcomers determined to become active contributors; both ways should be embraced and utilized What challenges are you facing? And, how would you improve them? Two weeks from now, we'll have a forum session at the OpenInfra Summit Asia in Suwon[**] where our community can refine these possible approaches and integrate others, as well as bring attention to them and promote their application. I've also proposed a similar forum session for OpenInfra Days North America in Indianapolis a month after that, where we can hopefully continue this conversation. The goal for this multi-stage effort is to improve the contribution experience for established participants, casual contributors and newcomers alike. While it's easy to jump to blaming in these situations, it will be far more productive if we can focus on the challenges and experiences that we would each like to remove or improve for ourselves and others in our community. As we find ways together to improve our efficiency, we can reduce the load on all contributors and lower the barriers for people to join and participate. [*] https://etherpad.opendev.org/p/r.2205024e55689bccb82c20c960853cb5 [**] https://2024.openinfraasia.org/a/schedule#view=calendar&title=Bridging%20th… -- Jeremy Stanley

2 8

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 20 Jan '25

20 Jan '25

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

2 2

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

10 Jan '25

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

1 2

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

24 Dec '24

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

4 4

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

26 Nov '24

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

4 3

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

25 Nov '24

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

2 2

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

18 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

[horizon] SCSS compilers
by Radomir Dopieralski 15 Nov '24

15 Nov '24

The openstack dashboard uses scss for styling, and so far we have used a python scss library for compiling those files to css for use in the browser. However, that library (pyscss) had in recent years some problems, and is not developed or supported by the authors anymore. So it's time to switch to something with a better support. The django-compressor plugin that we use for handling the compilation of files allows us to use any command-line tool to do the compilation, so we can switch to an scss compiler that is supported and used by the wider community. However, there are several options we can choose from: sassc python-libsass pysassc ruby-sass ruby-sassc node-node-sass Each of those would introduce a non-python dependency on the dashboard. The question for the packagers and distro maintainer is which of those tools would be preferable in terms of support, packaging, and maintenance for the long term? Do you have opinions? Maybe there is another tool that would be even better that I didn't find?

2 3

OpenStack Cinder - Volume-ID in cinder DB
by Harsh Ailani 12 Nov '24

12 Nov '24

Hello contributors, I am working on clone operation for a volumegroup and in that the volume ID auto-generated by OpenStack is not the one with which the clone volumes are being created on my IBM storage backend. This is as per design that IBM Storage backend will take the source-volume ID in the source-volumegroup and add a suffix to it while cloning. Now since there is a mismatch in the IDs between cinder and storage backend, because of which I am unable to perform any volume operations on this cloned volume. So, I was wondering if I can change the volume ID in cinder DB? I know that it’s a unique key and there is a limit of 36 characters for this field in cinder DB, but since I cannot change the volume in storage backend, I wanted to check if there is a way I can alter the volume ID in cinder DB? Kindly share your thoughts/suggestions on this matter. Thanks and Regards, Harsh Ailani

2 4

[largescale-sig]scaling story
by Alex Song (宋文平) 25 Oct '24

25 Oct '24

Hi everyone, we want to share our scaling story. Please refer the link: https://etherpad.opendev.org/p/large-scale-inspur Thanks, Alex Song

6 8

[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 16 Oct '24

16 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

Improving stestr... or switching to a (better) compatible test runner?
by Thomas Goirand 09 Oct '24

09 Oct '24

Hi, This is the 2nd time I'm opening a thread about it. Sorry for this, but it really bothers me. Today, running tempest, I got these stats from stestr: - Worker 0 (132 tests) => 0:24:49.209885 - Worker 1 (100 tests) => 0:17:14.791845 - Worker 2 (124 tests) => 0:42:52.690906 - Worker 3 (189 tests) => 0:41:21.307241 - Worker 4 (159 tests) => 0:45:49.503031 - Worker 5 (143 tests) => 0:28:13.282371 - Worker 6 (156 tests) => 3:16:52.364976 - Worker 7 (103 tests) => 0:46:05.366089 So, thread #1 ran 17 minutes, sitting idle for the rest of the 3 hours run of thread #6. While I thought stestr was deviding the number of tests by the number of thread, I don't get why worker #1 only had 100 tests assigned. All together, all tests could have been ran within maybe less than an hour of time (rather than 3h16 above), if not-yet-ran-tests were reassigned to idle treads. I'm currently spending a lot of time on running tempest. Indeed, I'm running tempest on each OpenStack upgrade, from Victoria up to Dalmatian. With the current way stestr run, it may take 2 full days to do that (and that's not even counting when upgrade will fail and will need fixing...), when it could be done in maybe 8 hours (if I count 1h per OpenStack release). So, knowing the above, it might be a good use of my time to dig into stestr and see if I can fix this... or not! Does anyone have a suggestion for another test runner, that's compatible with stestr, at least for the tests selection with a regular expression? As much as I know, pytest cannot take a regexp for test selection, can it? Or is there maybe a plugin for it? If there's no compatible test runner, where should I dig in the stestr code to rewrite things in a smarter way? Cheers, Thomas Goirand (zigo) P.S: On Caracal today, I just had this: ============== Worker Balance ============== - Worker 0 (117 tests) => 0:59:32.291385 - Worker 1 (147 tests) => 1:22:28.228980 - Worker 2 (125 tests) => 0:45:20.969397 - Worker 3 (114 tests) => 1:46:21.667579 - Worker 4 (170 tests) => 0:45:27.577738 - Worker 5 (190 tests) => 2:28:39.744920 - Worker 6 (182 tests) => 2:29:01.402255 - Worker 7 (152 tests) => 2:29:10.183359 this looks better, but that's probably 1/ random 2/ still not perfect, with worker #0, #2 and #4 doing nothing 2/3rd of the time.

2 1

[tc][watcher] No leaders for project team, heading to retirement
by Goutham Pacha Ravi 09 Oct '24

09 Oct '24

Hello Stackers, The "watcher" project [1] did not have any volunteers to lead the project in the 2025.1 election cycle. In the past few years, the project's team has slowly disbanded and there have been no significant changes proposed/merged in the project's repositories [2]. We noticed that there were three deployers that noted their use of Watcher in production in the past user survey [3]. It's possible that the project failed to gather any significant adoption, and hence there's less interest in contributing to, and maintaining the project. I'm sending this notification pursuant to the OpenStack governance recommendations [4] to retire project teams. We can mark a project team "inactive", however, an "inactive" project must have some contributors aiming to build-back a maintainers team around it - and it must pick a project team lead, or adopt a distributed project leadership model by nominating liaisons. Since there are no PTL nominees, we think marking this project "inactive" serves no purpose. Is there any objection to retiring the "openstack/watcher" project (and associated deliverables: python-watcherclient, watcher-dashboard and watcher-tempest-plugin)? Once the project is retired, configuration management and deployment projects can drop their integrations as well. Thanks, On behalf of the OpenStack TC, Goutham Pacha Ravi [1] https://wiki.openstack.org/wiki/Watcher [2] https://review.opendev.org/q/(project:%5Eopenstack/watcher.*+OR+project:ope… [3] https://governance.openstack.org/tc/user_survey/analysis-2023.html [4] https://governance.openstack.org/tc/reference/dropping-projects.html

5 7

Stop bumping major versions when dropping EOL Python versions
by Stephen Finucane 05 Oct '24

05 Oct '24

o/ Python 3.8 is going EOL (upstream, anyway) next month. We've been working to drop support for this from various SDK deliverables, and I'm guessing (though don't yet know for sure) that this will happen across other project deliverables before long (if it hasn't started happening already). One side-effect of this change is that we will be expected to raise the major version of the affected dependencies on our next release. This is annoying for projects like openstacksdk that use the release-with-intermediary release model because it forces us to have a major version release earlier than we would like to. To give a concrete example, we have a RemovedInSDK50Warning deprecation warning that we are using to indicate (as you might guess) things that we plan to remove in openstacksdk 5.0.0. We need to wait 6 months/1 OpenStack release before removing anything flagged with this warning, so this has been mainly applied to legacy deprecation warnings to put a concrete timeline on their removal. However, because we just dropped Python 3.8 support, it is currently expected that our next release be 5.0.0. We last deprecated something new ~2 months ago, so this means we either cannot release a new version of openstacksdk for 3-4 months (to allow 6 months to pass) or we need to either rename RemovedInSDK50Warning to RemovedInSDK60Warning or add a new RemovedInSDK60Warning and move the offending deprecations to this. None of these are nice options and to be honest, I don't think the major version bump really provides all that much value to end-users: they already have a much better signal for the removal of a Python version in the 'python_requires' marker in setup.py/setup.cfg/pyproject.toml/(other build system file). By using this, we ensure that a user simply can't install a version of a package that doesn't support their chosen Python version. I'd be in favour of getting rid of this particular constraint, and instead focusing on API changes when deciding whether to bump the major version. Is this a reasonable suggestion, and if so what would we need to do to tweak our policy to allow it? Cheers, Stephen

4 3

[Kolla-Ansible] [Ironic] Node Deploy Failed with MissingAuthPlugin
by Ali Hussain 02 Oct '24

02 Oct '24

Hi Kolla and Ironic folks, While playing with stable/kolla release to fix the No VIF found error. Looks like adding Readers role to ironic user fixed it. But run into Missing Auth plugin [2] issue while image is being deployed to ironic node. Openstack endpoint list command [1] shows the correct IP of the controller. My question is: 1. Kolla-Ansible needs explicite Ironic keystone configuration in Ironic.conf? Following this link <https://docs.openstack.org/kolla-ansible/yoga/reference/bare-metal/ironic-g…> which does not seems to need any keystone configurations. This issue is observed when 1. --boot-interface redfish-virtual-media 2. --deploy-interface ramdisk 3. --driver-info deploy_iso= 4. -instance-info kernel & ramdisk 2. My passwords.yaml has 1. ironic_database_password: 2. ironic_inspector_database_password: 3. ironic_inspector_keystone_password: 4. ironic_keystone_password: Any suggestions please. Thank you. Ali [1] openstack endpoint list | grep ironic | <ID> | <Region> | ironic-inspector | baremetal-introspection | True | internal | http://<IP>:5050 | | <ID> | <Region> | ironic | baremetal | True | public | http://<IP>:6385 | | <ID> | <Region> | ironic-inspector | baremetal-introspection | True | public | http://<IP>:5050 | | <ID> | <Region> | ironic | baremetal | True | internal | http://<IP>:6385 [2] *Error: *Detected change in error condition on node Node1. Deploy step deploy.deploy failed with MissingAuthPlugin: An auth plugin is required to determine endpoint URL.. An unhandled exception was encountered while aborting. More information may be found in the log file.

2 6

[largescale-sig] Next meeting: September 18, 9utc
by Thierry Carrez 01 Oct '24

01 Oct '24

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

3 3

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

01 Oct '24

Hello Stackers, After 26 weeks of effort across the community, we're finally at the release week for the 2024.2 release [1], codenamed 'Dalmatian'. I'll cue "Who Let the Dogs Out" for 2024-10-02 and toast the successful delivery of the 30th release of OpenStack with all of you. Congratulations, and thank you for your contributions in making this yet another on-time release. Please tune into the OpenInfra Live episode at 1400 UTC on 2024-10-03 [2], where you'll hear from a few Project Team Leads about the new and exciting things included in this release. Over the past week, the OpenStack TC assisted the release team in tagging a few deliverables, and on its behalf, I'd like to commend the release team for pulling out all the stops to ensure yet another on-time release. It takes a village, as Jeremy Stanley (fungi) noted on IRC — the happy, buzzing Stackerton village. We also merged some governance changes in the meantime. Notably, we adopted a community goal to move all existing Ubuntu testing to the latest LTS [3], and we retired several charms repositories after their consolidation into the Sunbeam-charms project [4]. I am pleased to welcome Dmitriy Rabotyagov (noonedeadpunk) as the Vice Chair for the TC, and I thank the outgoing Vice Chair, Dr. Jens Harbott (frickler), for his contributions during the 2024.2 release cycle. Next week, as we step into the 2025.1 ("Epoxy") release cycle formally [5], we'll switch into PTG and planning mode and chart out the remaining release priorities early. === Weekly Meeting === The Technical Committee's weekly meeting was held over IRC on 2024-09-24 [6]. We began the meeting by welcoming new members and thanking outgoing ones. We appointed a TC Chair (me) and a Vice Chair (noonedeadpunk) for the 2025.1 release cycle. We then worked through several 2024.2 release issues. We were presented with a peculiar, but familiar problem involving release deliverables that couldn't proceed without help from project maintainers who were unavailable during the release crunch. The release team prepares release candidate patches a week before the RC1 deadline and encourages project maintainers to vote on them. They also submit changes to the respective repositories to verify the state of the CI system to prevent releasing broken code. However, when a project team doesn't respond, there's a risk to the coordinated release. We brainstormed strategies to deal with the current conundrum. Thanks to noonedeadpunk and the attentiveness of project maintainers in Zun and Barbican, we were able to fix broken CI jobs and tag release candidates for some projects. However, we couldn't determine the state of "kuryr-kubernetes" and "kuryr-tempest-plugin." These projects, flagged earlier as unmaintained, are expected to be retired soon, so there are no releases from these projects in the 2024.2 release stream. If you depend on these projects, please let us know. We are looking for maintainers who can commit to reviving the CI and furthering these projects. The next OpenStack TC meeting is on 2024-10-01 at 1800 UTC. This meeting will be held simultaneously via video and IRC. Please find the agenda and other meeting details in our meeting wiki [7]. I hope you'll be able to join us. Remember, you can always edit the agenda and propose new topics! === Governance Proposals === ==== Merged ==== - Retire all single charm repositories | https://review.opendev.org/c/openstack/governance/+/903490 - Select community-wide goal: migrate CI/CD jobs to Ubuntu Noble | https://review.opendev.org/c/openstack/governance/+/929703 - Add 2025.1 TC chair and vice-chair | https://review.opendev.org/c/openstack/governance/+/930376 - Add chair nomination folder for 2025.1 | https://review.opendev.org/c/openstack/governance/+/929970 - Add GouthamR nomination for 2025.1 TC chair | https://review.opendev.org/c/openstack/governance/+/929971 ==== Open for Review ==== - Appoint Tim Burke as PTL for Swift | https://review.opendev.org/c/openstack/governance/+/928881 - Add Axel Vanzaghi as PTL for Mistral | https://review.opendev.org/c/openstack/governance/+/927962 - Mark kuryr-kubernetes and kuryr-tempest-plugin as Inactive | https://review.opendev.org/c/openstack/governance/+/929698 - Retire kuryr-kubernetes and kuryr-tempest-plugin | https://review.opendev.org/c/openstack/governance/+/922507 === Upcoming Events === - 2024-10-02: OpenInfra Live - Introducing OpenStack Dalmatian 2024.2 [2] - 2024-10-08: OpenInfra Monthly Board Meeting: https://board.openinfra.dev/ - 2024-10-15: OpenInfra Days NA, Indianapolis: https://ittraining.iu.edu/explore-topics/titles/oid-iu/ - 2024-10-21: OpenInfra Project Teams Gathering https://openinfra.dev/ptg/ === How to Contact the TC === You can reach the TC in several ways: 1. Email: send an email with the tag [tc] on this mailing list. 2. Ping us using the 'tc-members' keyword on the #openstack-tc IRC channel. 3. Join us at our weekly meeting: The Technical Committee meets every week on Tuesdays at 1800 UTC [7]. Thank you very much for reading! On behalf of the OpenStack TC, Goutham Pacha Ravi (gouthamr) OpenStack TC Chair [1] 2024.2 "Dalmatian" Release Schedule: https://releases.openstack.org/dalmatian/schedule.html [2] Introducing OpenStack Dalmatian 2024.2: https://openinfra.dev/live/ [3] Goal: migrate CI/CD jobs to Ubuntu Noble: https://review.opendev.org/c/openstack/governance/+/929703 [4] Retire all single charm repositories: https://review.opendev.org/c/openstack/governance/+/903490 [5] 2025.1 "Epoxy" Release Schedule: https://releases.openstack.org/epoxy/schedule.html [6] TC Meeting IRC Log, 2024-09-24: https://meetings.opendev.org/meetings/tc/2024/tc.2024-09-24-17.59.log.html [7] TC Meeting Agenda, 2024-10-01: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee

1 0

Nova placement
by engineer2024 30 Sep '24

30 Sep '24

Is there a way to get back the correct used resources allocation data, in case of loosing the db ? Does placement update the allocation details after restarting the compute nodes to get the latest resources usage for that node ? Thanks elinux

2 2

[neutron] Proposing Ihar Hrachyshka as neutron stable core reviewer
by Brian Haley 30 Sep '24

30 Sep '24

Hello Neutrinos, I would like to nominate Ihar Hrachyshka for Neutron stable core reviewer (again). Ihar previously led the neutron stable core reviewer team a number of years ago, and I think he'd be a great re-addition to the team. Please vote with a +1/-1. Thanks, -Brian, Neutron PTL

6 6

[kolla] Proposing Matt Crees for Kayobe core
by William Szumski 30 Sep '24

30 Sep '24

Greetings Kayobians, I would like to propose Matt Crees as a core reviewer for Kayobe. With Mark Goddard stepping back from Kayobe maintenance duties, we have a slot to fill in the core team. In my opinion, Matt Crees is the strongest candidate for the position, having provided numerous reviews and contributions over the past few cycles. Please register any objections to this decision before the kolla meeting on 25th of September, otherwise I will proceed with making formal arrangements to get him added. Thanks Will Szumski will(a)stackhpc.com

6 6

[neutron] Bug Deputy report Sep 23 - 29th
by Oleg Bondarev 30 Sep '24

30 Sep '24

Hello Team, Nothing critical this week, 3 High bugs need assignees, 1 RFE to review by Drivers team. Full report for the week of Sep 23 is below: High: - https://bugs.launchpad.net/neutron/+bug/2081868 - LoggingDBApiTestCase.test_get_logs_bound_sg fails - Confirmed - unassigned - https://bugs.launchpad.net/neutron/+bug/2081870 - TestProcessMonitor.test_respawn_handler failed - Confirmed - unassigned - https://bugs.launchpad.net/neutron/+bug/2081871 - TestHAL3Agent.test_ha_router failed - Confirmed - unassigned - https://bugs.launchpad.net/neutron/+bug/2081945 - [postgresql] AttributeError: 'NoneType' object has no attribute 'id' - In progress: https://review.opendev.org/c/openstack/neutron/+/930408 - assigned to Rodolfo Alonso Medium: - https://bugs.launchpad.net/neutron/+bug/2082066 - Logging not supported in unmaintained branches - In progress: https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/930546 - assigned to Rodolfo Alonso - https://bugs.launchpad.net/neutron/+bug/2082070 - [unmaintained] Errors in the "neutron-tempest-plugin-scenario-ovn" job - In progress: https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/930548 - assigned to Rodolfo Alonso - https://bugs.launchpad.net/neutron/+bug/2082344 - [unmaintained] ``NetworkWritableMtuTest`` test don't work in ML2/OVN - In progress: https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/930594 - assigned to Rodolfo Alonso - https://bugs.launchpad.net/neutron/+bug/2082880 - [ovn-octavia-provider] config registration hit DuplicateOptError - In progress: https://review.opendev.org/c/openstack/ovn-octavia-provider/+/930670 - assigned to Rico Lin Low: - https://bugs.launchpad.net/neutron/+bug/2082883 - neutron-tempest-plugin: KeyError caused by missing 'previous' ref Edit - Confirmed - unassigned RFEs: - https://bugs.launchpad.net/ironic/+bug/2081847 - [RFE] Implement a new DHCP backend for Ironic and Neutron Edit - New - unassigned Thanks, Oleg

1 0

[kolla] [kolla-ansible]
by dariusz.bursztynowski＠pw.edu.pl 30 Sep '24

30 Sep '24

Hello, Are there plans for kolla-ansible to support Ubuntu 24.04 / ARM64 (to have LTS support for Raspberry Pi 5)? Best regards, Dariusz Bursztynowski

4 3

[Openstack] [Keystone] [Shibboleth] Assistance with Configuring Multiple IdPs in DevStack with Shibboleth Integration
by Abubakur Sait 29 Sep '24

29 Sep '24

Hi all, I have installed DevStack (release 2023.2) on Ubuntu 22.04 and integrated Shibboleth (the federation solution) with it. Everything works fine for a single IdP. However, I am looking to expand the setup to support multiple IdPs. I have read the Keystone documentation, but it doesn’t seem to cover this specific case. In my current setup, I have DevStack and Shibboleth integrated for a single IdP. I have read the shib-sp documentation as well. It mentions the need for a Discovery Service (DS) if we intend to use multiple IdPs which will be handled by the shib-SP software. This is the issue I am facing right now. Please see the following comments to get my point. Here’s the scenario I have so far: 1. A user accesses Horizon (Service Provider -- SP) at: http://192.168.4.103/dashboard/auth/login/?next=/dashboard/. 2. A drop-down list allows the user to choose the authentication method. The user selects the SAML IdP method. 3. The user is redirected to the IdP’s page where they authenticate. 4. The user is redirected back to the SP and successfully accesses the system. 5. The issue I’m facing is how to configure multiple IdPs so that users can choose from them at step (2). I understand that we can add a list of IdPs in the ~/horizon/openstack_dashboard/local/local_settings.py file to display in Horizon, but this doesn’t fully resolve the issue since the Shibboleth SP application itself doesn’t seem to handle multiple IdPs. Shibboleth SP typically expects a DS for multiple IdPs, but given that we already have a dropdown list in Horizon, do we still need the DS in this case? If not, how can we proceed with adding multiple IdPs in the system? Any guidance or advice would be greatly appreciated. Thank you for your help! Best regards, Bakur Sait

1 0

[octavia] Lose of some jobs by worker
by Payne Max 29 Sep '24

29 Sep '24

Hi, OpenStack community, I’ve faced a problem when some of our jobs can get lost by a worker, for example from the screenshot, SIGTERM was called in several seconds after receiving a job by a worker. [cid:image001.png@01DB1013.D648A630] Then there were no new log messages related to this job. Then our client complained that LB stucked in PENDING_UPDATE for several days and we started investigation. Our MySQL (persistent storage) is clean, but in our Redis, I can see several jobs without TTL and I think they are related to the «lost» jobs. [cid:image002.png@01DB1014.1DFF1BD0] Is it an ok situation? Can it be related to the https://github.com/openstack/octavia/blob/master/octavia/common/base_taskfl… Let’s discuss it!

4 6

kolla-ansible support for Ubuntu 2024.04/ARM64 ?
by dariusz.bursztynowski＠pw.edu.pl 28 Sep '24

28 Sep '24

Hello, Are there plans for kolla-ansible to support Ubuntu 24.04 / ARM64 (e.g., to have LTS support for Raspberry Pi 5)? Best regards, Dariusz Bursztynowski

1 0

[openstack]Problem with launching instances from VMDK
by Nguyễn Hữu Khôi 27 Sep '24

27 Sep '24

Hello I am trying create instance from vmdk but I have this error: The image format was claimed to be 'vmdk' but the image data appears to be in a different format. My cloud is Openstack 2023.1. This happened when We applied patches for CVE-2024-40767. Nguyen Huu Khoi

3 4

[release] Release countdown for week R+0
by Thierry Carrez 27 Sep '24

27 Sep '24

Development Focus ----------------- We will be releasing the coordinated OpenStack 2024.2 Dalmatian release next week, on October 2nd, 2024. Thanks to everyone involved in the Dalmatian 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 in a few weeks 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: https://ptg.opendev.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 2nd, so that their approval is included in the metadata that goes onto the signed tag. Upcoming Deadlines & Dates -------------------------- Final 2024.2 Dalmatian release: October 2nd, 2024 Project Teams Gathering: October 21-25, 2024 -- Thierry Carrez (ttx)

1 0

help
by Gyan Dev Mishra 27 Sep '24

27 Sep '24

hi sir, was facing an issue with launching an instance in OpenStack. When I try to launch an instance using a Ubuntu Server 22.04 ISO image, I am getting the error. Even if I try with the default Cirros image, the instance launches, but when I attempt to access it from the console, I encounter a network error. I was trying to run it using an IP in the 10.x.x range, but it is fetching an IP in the 192.168.x range. I have attached the screenshot for the your reference. How can I resolve this issue? DISCLAIMER: This communication may contain confidential or copyright information. If you are not an intended recipient, you must not keep, forward, copy, use, save or rely on this communication. Any such action is unauthorized and prohibited. If you have received this communication in error please delete it. Reasonable precautions have been taken to ensure no viruses are present in this email, the company cannot accept responsibility for any loss or damage arising from the use of this email or attachments.

1 0

(외부메일) [heat][heat-cinder] How can I use the Cinder volume extend in Heat?
by 박광우 27 Sep '24

27 Sep '24

3 3

[ptl][release] OpenStack Dalmatian OpenInfra Live
by Allison Price 27 Sep '24

27 Sep '24

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

5 6

Potential Mentorship Opportunities (Jan - May 2025)
by Kendall Nelson 27 Sep '24

27 Sep '24

Hello Party People! It's very early, but I wanted to float the information ahead of time :) Coming up for the next semester (Spring semester in Northern Hemisphere; Jan to May) we have the opportunity to propose projects to students at North Dakota State University to work on. Students will be in the last couple semesters before graduation with a Bachelor's degree in CS. Good projects would be scoped to a small group of students 3-5 working together for around 4.5 months (maybe 4 with onboarding, midterms etc). Mentors on these projects do not have to work alone - often I have two or three community members working together to mentor the students (ask Manila, they are a good example). I will want to start collecting project proposals (and mentor volunteers) in December before everyone leaves for the holidays but that still gives a fair amount of time for questions if anyone has them. I already have one team interested (Hi, Swift!) but would love a couple others to get involved. Let me know what questions you have or if you are interested in mentoring! -Kendall Nelson (diablo_rojo)

1 0

[ironic] [security] Ironic officially vulnerability-managed
by Jay Faulkner 27 Sep '24

27 Sep '24

Hi all, Although for a long time now, in practice, we've been using the Vulnerability Management team (VMT) process to triage, embargo, and resolve Ironic security bugs, we've now done the legwork needed to be officially managed by the VMT. The following Ironic projects are now VMT-managed[0]: - ironic - ironic-inspector - ironic-python-agent - ironic-lib - networking-baremetal - networking-generic-switch - python-ironicclient - python-ironic-inspector-client - sushy As per VMT policy[1]. the launchpad bug trackers for these projects have been updated to only allow access by the VMT to initial private-security bug reports. If there are any questions, please just ask! Thanks, Jay Faulkner 0: https://opendev.org/openstack/ossa/commit/b68aaa0652ec83b1349dddcdc334b7572… 1: https://security.openstack.org/repos-overseen.html#requirements (number 4)

1 0

[ceilometer] What's the general status / recommendation for Telemetry in OpenStack
by Waines, Greg 26 Sep '24

26 Sep '24

Hey ... I am working in OpenStack StarlingX which supports a Kubernetes cluster and a containerized OpenStack cluster (via openstack-helm). Our OpenStack offering is fairly simple ... only running Nova, Cinder, Neutron, Keystone, Glance, Horizon and Heat ... @ Antelope. In a predecessor of StarlingX, maybe in the Queens(?) timeframe ... we had a Telemetry solution that consisted of: - Ceilometer (for basic data polling, notifications and collection) - Panko (for event DB) - Gnocchi (for time-series DB) - Aodh (for alarming based on metric thresholds, etc.) HOWEVER ... today (Caracal) ... - I think Gnocchi is still alive and well ... https://github.com/gnocchixyz/gnocchi * but maintained outside of OpenStack - I think OpenStack Panko was deprecated in ~ Wallaby ? * and don't think(?) it is maintained outside of OpenStack ? - The OpenStack Landscape at https://www.openstack.org/software/ * shows only Ceilometer and Aodh MY QUESTIONs : ----------------------- - so what are the current recommendations for OpenStack Telemetry ? - is it just Ceilometer and Aodh ? * Does Ceilometer provide DBs ? (like it used to a long time ago) - is Gnocchi (although maintained outside of OpenStack) still supported in the OpenStack environment as a DB option ? - what is used for event DB ? ... now that panko is gone ... Gnocchi ? Ceilometer ? - are there actually multiple options/solutions for OpenStack Telemetry ? e.g. * Ceilometer / Gnocchi / Aodh * Ceilometer / External Elastic Solution / Aodh * Others ? Greg.

5 5

[powerflex][glance]Dell PowerFlex: After setting the Glance backend to PowerFlex Cinder, uploading an image and creating an image volume does not result in the image volume being created correctly.
by cuiye.liu＠dell.com 26 Sep '24

26 Sep '24

Description of customer infrastructure (Environment) - MANDATORY PowerFlex 3.6.2, 4.5.2 2023.2(Bobcat) Issue/problem detail and customer impact (Description, Impact, Steps to reproduce the issue, How often it happens) - MANDATORY Provide a clear description of the issue After setting the Glance backend to PowerFlex Cinder, uploading an image and creating an image volume does not result in the image volume being created correctly. Clear statement of customer impact unable to use PowerFlex as the backend for Glance, so additional storage is needed Steps to reproduce the issue i.e. commands #openstack volume create --size 8 --type powerflex --image cirros_flex --bootable test_image_volume2 Frequency of the issue everytime The error information is as following: 2024-09-19 07:03:46.320 24 DEBUG cinder.volume.flows.manager.create_volume [None req-c0a6a1fb-e26e-4925-a338-a4c9a68952f1 9c7543d67e184d51a6a77d5046c9e8a1 379ea5a5d4824c7f85e51e77d7c12add - - - -] Volume 37a4ef47-93b5-4395-8cdc-d04498fde0a0: re-scheduling SchedulerAPI.create_volume attempt 3 due to Failed to download image 87ea548b-80ff-4f7b-802b-042debaae696, reason: IOError: 32 Corrupt image download. Hash was cf83e1357eefb8bdf1542850d66d8007d620e4050b5715dc83f4a921d36ce9ce47d0d13c5d85f2b0ff8318d2877eec2f63b931bd47417a81a538327af927da3e expected 1b03ca1bc3fafe448b90583c12f367949f8b0e665685979d95b004e48574b953316799e23240f4f739d1b5eb4c4ca24d38fdc6f4f9d8247a2bc64db25d6bbdb2 _reschedule /var/lib/kolla/venv/lib64/python3.9/site-packages/cinder/volume/flows/manager/create_volume.py:162 It is similar to this bug that is submmited in 2021: 1936314 – Glance image download fails with the error [Errno 32] Corrupt image download. (redhat.com) https://bugzilla.redhat.com/show_bug.cgi?id=1936314 Does anyone knows if it is fixed?

1 0

Problems with the Placement service
by Ron Gage 26 Sep '24

26 Sep '24

4 6

Openstack deployment on a single node server
by Gyan Dev Mishra 25 Sep '24

25 Sep '24

Hi, I am a newbie to OpenStack deployment, we are looking for a deployment strategy for OpenStack to test all our cloud-based apps to save on testing expenses. I tried it with microstack where I faced some issues related to Available Zones which was always empty. So, is it possible to use only one node to deploy and use complete OpenStack or do we need to follow some different strategy. I am having one server machine on which I want to deploy the complete cloud solutions. Kindly provide me with the necessary insights. I really appreciate any help you can provide. Gyan dev, Sr. Software Developer at eCosmos Solutions DISCLAIMER: This communication may contain confidential or copyright information. If you are not an intended recipient, you must not keep, forward, copy, use, save or rely on this communication. Any such action is unauthorized and prohibited. If you have received this communication in error please delete it. Reasonable precautions have been taken to ensure no viruses are present in this email, the company cannot accept responsibility for any loss or damage arising from the use of this email or attachments.

3 2

Retire sqlalchemy-migrate
by Thomas Goirand 25 Sep '24

25 Sep '24

Hi, As much as I know, there's no active OpenStack project using sqlalchemy-migrate anymore. Can someone retire the project, or at least push some indication in the README.rst that the project is retired? When looking at: https://opendev.org/x/sqlalchemy-migrate nothing says so... Cheers, Thomas Goirand (zigo)

3 3

[trove][zaqar][vitrage] What to do with projects not supporting SQLAlchemy 2.x ?
by Thomas Goirand 25 Sep '24

25 Sep '24

Hi, A number of project still don't have support for SQLAlchemy 2.x, which is currently in Debian testing/unstable, and which will be the version in Debian 13 (aka: Trixie). If these project don't get quickly support for SQLAlchemy 2.x, they are going to drop (well, in fact, they were already kicked out of Debian Testing). Are these project still maintained? IMO, no support for SQLAlchemy 2.x is a reason good enough to declare they aren't... Cheers, Thomas Goirand (zigo)

2 2

Network MTU setting in ovn/ovs
by Łukasz Chrustek 25 Sep '24

25 Sep '24

Hi, I have a question about increasing MTU for tenant network. Now it set to 1442 by default on geneve baked tenant network. Is there any drawbacks or it is some kind of bad practice to increase this MTU to 1500 bytes or higher ? We had an issue with one migrated instance from older version of openstack (where was linuxbrigde configured), there mtu was set to 1500, so the settings for i.e. docker inside the vm was set respectively to the higher value. -- Best regards Lukasz Chrustek

4 11

[oslo.db][magnum] QueuePool hangs in Caracal
by Mohammed Naser 25 Sep '24

25 Sep '24

Hi there! The community has identified a bug (https://bugs.launchpad.net/magnum/+bug/2067345) which makes Magnum unusable / entirely broken in Caracal. There is a proposed workaround here: https://bugs.launchpad.net/magnum/+bug/2067345/comments/35 The majority of the issue seems to be around when the changes to remove autocommit were done, I've attempted to switch to enginefacade to prevent these issues (same as Ironic) but with no avail: https://review.opendev.org/c/openstack/magnum/+/927446 There is also a greenthread stacktrace there which shows where/how it's hanging, would it be possible to have someone who might have a bit more insight to help point us in the right direction? I'm more than happy to take this on and keep pushing it forward but I'm not sure if I know where the fix can go at this point. Thanks, Mohammed

2 1

[release][zun][kuryr-libnetwork][kuryr-kubernetes] Immediate action required for 2024.2 (Dalmatian) release
by Dmitriy Rabotyagov 25 Sep '24

25 Sep '24

Hi, As you might know, R-2 week where Release Candidates for all projects following cycle-with-rc cadence should be created has already passed. Nevertheless there are a couple of projects, which do have broken Zuul Jobs[1], which prevents them from being released (tagged with RC1 and create a stable/2024.2 branch). There is a hard deadline by the end of this week (September 27, 2024) to merge required fixes into projects and update corresponsive release patches [2][3][4] in order to be included into the Dalmatian release. Otherwise the Technical Committee will have to take action on the mentioned projects, which can include preventing them from being released and marking them as Inactive ones. So everyone interested in the future of these projects - please take a look at the gate health and help core teams out fixing outstanding issues. Core teams - please prioritise review of proposed patches or come up with fixes during this week. [1] https://review.opendev.org/q/topic:dalmatian-rc1-deadline+is:open [2] https://review.opendev.org/c/openstack/releases/+/928531 [3] https://review.opendev.org/c/openstack/releases/+/928532 [4] https://review.opendev.org/c/openstack/releases/+/928575

1 0

[manila] Propose Gireesh Awasthi to manila core
by Carlos Silva 25 Sep '24

25 Sep '24

Hello everyone, I would like to add Gireesh Awasthi to the OpenStack Manila core team. Gireesh started his OpenStack journey a couple of cycles ago, and caused great impact from the get go while working on some complex features that impacted all of the manila code base. He's also been consistently participative in the latest PTGs. With the knowledge acquired in the code base, he then started contributing more to reviews, and became a go-to person for providing feedback on the NetApp ONTAP driver changes, and/or third party driver changes. It is important to note that this is yet another step into maintaining a healthy community with people from different affiliations sharing the responsibility of maintaining an open source project. In case there are no objections, I will add him to the core team in 1 week from now. [1] https://bit.ly/manila-reviews-90-days Thank you! Regards, carloss

2 2

[cyborg][zun][masakari][tacker][venus] Pending removal of LegacyEngineFacade
by Stephen Finucane 24 Sep '24

24 Sep '24

o/ Just a heads up to the listed projects that oslo.db's LegacyEngineFacade is pending removal in the Epoxy cycle. I would encourage you to migrate asap to avoid a broken CI. For a minimal example of how to do this, I'd encourage you to look at [1]. Cheers, Stephen [1] https://review.opendev.org/c/openstack/mistral/+/926420

1 0

Looking forward to work with Real-world project!
by Artemio Mendoza 24 Sep '24

24 Sep '24

Hi OpenStackers, As a new OpenStack community member, I read your email very carefully and looking for an opportunity that I can support. After graduating from university, I got a BS degree in computer science. I have been working on web/mobile app development for 10 years and have some reasonable experience in AWS, Azure, and other cloud environments. But I was really interested in OpenStack cloud computing so I started researching this last year and I'm actively keeping an eye on this community email, and trying to find some clues and new ideas about what I am going to do. I'm especially interested in Ceph and VDI development based on OpenStack. For my experience, I have tried to set up devstack on my laptop(20 core i7th, 32GB RAM), and tried run Bumblebee ( https://github.com/NeCTAR-RC/bumblebee) but failed. :( So for now, I'm still going to learn OpenStack doc. But I want to practice myself by jumping into real-world projects. If you are interested in me or looking for someone who can collaborate/research, then I will absolutely dedicate myself to that as a volunteer. Looking forward to hearing many good suggestions. Please feel free to reach out to me through Skype (huknamatata21) or this number (+15124877569) Regards, Artemio (Hony)

1 0

[Neutron] Bug deputy Sept 16 - 23
by Jakub Libosvar 24 Sep '24

24 Sep '24

Hi, I was the bug deputy last week. Was calm, only 3 bugs reported. Here is the breakdown: High ---- * security-groups-rules-belongs-to-default-sg slows down SG GET operations - https://bugs.launchpad.net/neutron/+bug/2081173 - I marked it as high because it’s a performance regression Medium ------ * Tighten / improve rally SG tests to catch performance regressions - mostly a placeholder to improve rally scenarios to prevent regressing in performance - https://bugs.launchpad.net/neutron/+bug/2081108 Wishlist -------- * Neutron OVN support for CARP - https://bugs.launchpad.net/neutron/+bug/2081643 - sounds like a new feature but it also requires some enhancements in the core OVN first

1 0

[publiccloud-sig] Heads-Up: next meeting September 25th - 0700 UTC
by Felix Kronlage-Dammers 23 Sep '24

23 Sep '24

Hi everyone, We are adjusting the schedule for the publiccloud-sig and will switch to odd instead of even weeks. This Wednesday (September 25th) the next meeting of the publiccloud-sig is going to happen. Thanks to Artem (gtema) and Joern (joek-office) who helped prepare the meeting agenda for this wednesday: - Housekeeping - Upcoming vPTG - Reminder to sign up for PTG: https://openinfra.dev/ptg/ - IAM Federation - combination of functional requirements (every CSP is having unique use case so we want to find similarities and differencies to determine the roadmap for Keystone) If you’re interesting in IAM federation, be sure to join! We’ll be meeting at 0700 UTC here: https://meetpad.opendev.org/publiccloud-sig <https://meetpad.opendev.org/publiccloud-sig> See also here for all other details: https://wiki.openstack.org/wiki/PublicCloudSIG <https://wiki.openstack.org/wiki/PublicCloudSIG> See you on Wednesday! felix -- 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

Openstack power off/on process
by Michael Knox 23 Sep '24

23 Sep '24

Hey Folks. I am working through a scenario that requires us to have Openstack in a Pelican Case and deployed in the "field" on a semi regular basis. I guess, portal "edge cloud" if you will? The problem I am trying to clean up is the startup process. We use kolla-ansible and rocky with zed (though we have one with ubuntu and wallaby) in this specific use case. We do the shutdown nicely, kolla-ansible -i inventory stop, then power off the control nodes (we have 3 in the setup). The problem is on the start up. All the containers start and then we still *have* to run the kolla-ansible -i inventory mariadb_recovery step to get the cloud back into a usable state. No matter the order of shut down or start up, MariaDB seems to always need a recovery. Are there any people here doing this or something similar? Is there a more efficient startup process I am not aware of or should consider? The folks in the field aren't Openstack admins, so hoping to figure out a solution that is less dependent on their knowledge of Openstack's undercloud tooling. Thanks in advance Michael

2 2

[cinder][CI] Can't start zuul service
by xuq.fnstxz＠fujitsu.com 23 Sep '24

23 Sep '24

Hello every one, I'm building a CI system on my ubuntu 22 system. Now I've installed the zuul using 'pip install zuul' and configured it. But after running command 'zuul-scheduler', I saw a lot of errors like following in the log. It seems that there is something error in my config file that prevents access to the repo. > 2024-09-20 13:05:06,010 ERROR zuul.TenantParser: Error processing cat job > Traceback (most recent call last): > File "/home/stack/.local/lib/python3.10/site-packages/zuul/configloader.py", line 2157, in _cacheTenantYAML > self._processCatJob(abide, tenant, loading_errors, job, > File "/home/stack/.local/lib/python3.10/site-packages/zuul/configloader.py", line 2249, in _processCatJob > raise TimeoutError(f"Cat job {job} timed out; consider setting " > TimeoutError: Cat job <zuul.zk.event_queues.JobResultFuture object at 0x7fb770341510> timed out; consider setting merger.git_timeout in zuul.conf Following is my zuul.conf. > [zookeeper] > hosts=ZOOKEEPER_HOST > tls_cert=/cert/client-cert.pem > tls_key=/cert/client-key.pem > tls_ca=/cert/ca-cert.pem > > [database] > # Use variable interpolation to supply the password from the > # docker-compose file. > # https://zuul-ci.org/docs/zuul/latest/configuration.html > dburi=mysql+pymysql://DB_USER:DB_PASS@DB_HOST/ZUUL_DB > > [keystore] > password=secret > > [web] > listen_address=0.0.0.0 > port=9000 > root=http://localhost:9000 > log_config=/etc/zuul/logging.conf > > [webclient] > url=http://localhost:9000 > verify_ssl=false > > [scheduler] > tenant_config=/etc/zuul/main.yaml > log_config=/etc/zuul/logging.conf > [merger] > git_user_email=git_user(a)example.com > git_user_name=git_user > log_config=/etc/zuul/logging.conf > > [executor] > private_key_file=/home/stack/.ssh/id_rsa > default_username=executor_user > trusted_rw_paths=/srv/static/logs > > [connection gerrit] > driver=gerrit > server=review.opendev.org > user=git_user > sshkey=/ssh/id_rsa And the following is the tenant_config file. > - tenant: > name: myCI > source: > gerrit: > untrusted-projects: > - openstack/cinder Could you please tell me what I need to modify or add in the config file? Thanks and Regards, Inori.

2 2

[kolla] Weird upgrade procudere ?
by Michal Arbet 23 Sep '24

23 Sep '24

Hi Koalas, I am not sure but is this normal ? In rabbitmq.yml is this +++ b/ansible/rabbitmq.yml @@ -0,0 +1,115 @@ +--- +# For RabbitMQ we need to be careful about restarting services, to avoid losing quorum. +- name: Apply role rabbitmq + gather_facts: false + hosts: + - rabbitmq + - '&enable_rabbitmq_True' But I can see during the upgrade restart every node at the same moment and then ther is some try to do it better ... I mean is that restart before OK ? Thanks TASK [rabbitmq : Enable all stable feature flags] ***************************************************************************************************************************************************************** ok: [controller1] ok: [controller0] ok: [controller2] TASK [rabbitmq : Check rabbitmq containers] *********************************************************************************************************************************************************************** changed: [controller0] => (item={'key': 'rabbitmq', 'value': {'container_name': 'rabbitmq', 'group': 'rabbitmq', 'enabled': True, 'image': 'dockerhub.ultimum.io/kolla-dev/debian-rabbitmq:KB-2023.1', 'bootstrap_environment': {'KOLLA_BOOTSTRAP': None, 'KOLLA_CONFIG_STRATEGY': 'COPY_ALWAYS', 'RABBITMQ_CLUSTER_COOKIE': 'ultimum', 'RABBITMQ_LOG_DIR': '/var/log/kolla/rabbitmq'}, 'environment': {'KOLLA_CONFIG_STRATEGY': 'COPY_ALWAYS', 'RABBITMQ_CLUSTER_COOKIE': 'ultimum', 'RABBITMQ_LOG_DIR': '/var/log/kolla/rabbitmq'}, 'volumes': ['/etc/kolla/rabbitmq/:/var/lib/kolla/config_files/:ro', '/etc/localtime:/etc/localtime:ro', '/etc/timezone:/etc/timezone:ro', 'rabbitmq:/var/lib/rabbitmq/', 'kolla_logs:/var/log/kolla/'], 'dimensions': {}, 'healthcheck': {'interval': '30', 'retries': '3', 'start_period': '5', 'test': ['CMD-SHELL', 'healthcheck_rabbitmq'], 'timeout': '30'}, 'haproxy': {'rabbitmq_management': {'enabled': 'yes', 'mode': 'http', 'port': '15672', 'host_group': 'rabbitmq'}, 'rabbitmq_outward_management': {'enabled': False, 'mode': 'http', 'port': '15674', 'host_group': 'outward-rabbitmq'}, 'rabbitmq_outward_external': {'enabled': False, 'mode': 'tcp', 'external': True, 'port': '5674', 'host_group': 'outward-rabbitmq', 'frontend_tcp_extra': ['timeout client 1h'], 'backend_tcp_extra': ['timeout server 1h']}}}}) changed: [controller2] => (item={'key': 'rabbitmq', 'value': {'container_name': 'rabbitmq', 'group': 'rabbitmq', 'enabled': True, 'image': 'dockerhub.ultimum.io/kolla-dev/debian-rabbitmq:KB-2023.1', 'bootstrap_environment': {'KOLLA_BOOTSTRAP': None, 'KOLLA_CONFIG_STRATEGY': 'COPY_ALWAYS', 'RABBITMQ_CLUSTER_COOKIE': 'ultimum', 'RABBITMQ_LOG_DIR': '/var/log/kolla/rabbitmq'}, 'environment': {'KOLLA_CONFIG_STRATEGY': 'COPY_ALWAYS', 'RABBITMQ_CLUSTER_COOKIE': 'ultimum', 'RABBITMQ_LOG_DIR': '/var/log/kolla/rabbitmq'}, 'volumes': ['/etc/kolla/rabbitmq/:/var/lib/kolla/config_files/:ro', '/etc/localtime:/etc/localtime:ro', '/etc/timezone:/etc/timezone:ro', 'rabbitmq:/var/lib/rabbitmq/', 'kolla_logs:/var/log/kolla/'], 'dimensions': {}, 'healthcheck': {'interval': '30', 'retries': '3', 'start_period': '5', 'test': ['CMD-SHELL', 'healthcheck_rabbitmq'], 'timeout': '30'}, 'haproxy': {'rabbitmq_management': {'enabled': 'yes', 'mode': 'http', 'port': '15672', 'host_group': 'rabbitmq'}, 'rabbitmq_outward_management': {'enabled': False, 'mode': 'http', 'port': '15674', 'host_group': 'outward-rabbitmq'}, 'rabbitmq_outward_external': {'enabled': False, 'mode': 'tcp', 'external': True, 'port': '5674', 'host_group': 'outward-rabbitmq', 'frontend_tcp_extra': ['timeout client 1h'], 'backend_tcp_extra': ['timeout server 1h']}}}}) changed: [controller1] => (item={'key': 'rabbitmq', 'value': {'container_name': 'rabbitmq', 'group': 'rabbitmq', 'enabled': True, 'image': 'dockerhub.ultimum.io/kolla-dev/debian-rabbitmq:KB-2023.1', 'bootstrap_environment': {'KOLLA_BOOTSTRAP': None, 'KOLLA_CONFIG_STRATEGY': 'COPY_ALWAYS', 'RABBITMQ_CLUSTER_COOKIE': 'ultimum', 'RABBITMQ_LOG_DIR': '/var/log/kolla/rabbitmq'}, 'environment': {'KOLLA_CONFIG_STRATEGY': 'COPY_ALWAYS', 'RABBITMQ_CLUSTER_COOKIE': 'ultimum', 'RABBITMQ_LOG_DIR': '/var/log/kolla/rabbitmq'}, 'volumes': ['/etc/kolla/rabbitmq/:/var/lib/kolla/config_files/:ro', '/etc/localtime:/etc/localtime:ro', '/etc/timezone:/etc/timezone:ro', 'rabbitmq:/var/lib/rabbitmq/', 'kolla_logs:/var/log/kolla/'], 'dimensions': {}, 'healthcheck': {'interval': '30', 'retries': '3', 'start_period': '5', 'test': ['CMD-SHELL', 'healthcheck_rabbitmq'], 'timeout': '30'}, 'haproxy': {'rabbitmq_management': {'enabled': 'yes', 'mode': 'http', 'port': '15672', 'host_group': 'rabbitmq'}, 'rabbitmq_outward_management': {'enabled': False, 'mode': 'http', 'port': '15674', 'host_group': 'outward-rabbitmq'}, 'rabbitmq_outward_external': {'enabled': False, 'mode': 'tcp', 'external': True, 'port': '5674', 'host_group': 'outward-rabbitmq', 'frontend_tcp_extra': ['timeout client 1h'], 'backend_tcp_extra': ['timeout server 1h']}}}}) RUNNING HANDLER [rabbitmq : Restart rabbitmq container] *********************************************************************************************************************************************************** [WARNING]: Failure using method (v2_playbook_on_handler_task_start) in callback plugin (<ansible.plugins.callback.ara_default.CallbackModule object at 0x7f66542e0100>): 'NoneType' object is not subscriptable changed: [controller0] changed: [controller1] changed: [controller2] PLAY [Restart rabbitmq services] ********************************************************************************************************************************************************************************** TASK [rabbitmq : Get info on RabbitMQ container] ****************************************************************************************************************************************************************** ok: [controller0] TASK [rabbitmq : Put RabbitMQ node into maintenance mode] ********************************************************************************************************************************************************* changed: [controller0] TASK [rabbitmq : Restart rabbitmq container] ********************************************************************************************************************************************************************** changed: [controller0] TASK [rabbitmq : Waiting for rabbitmq to start] ******************************************************************************************************************************************************************* changed: [controller0] PLAY [Restart rabbitmq services] ********************************************************************************************************************************************************************************** TASK [rabbitmq : Get info on RabbitMQ container] ****************************************************************************************************************************************************************** ok: [controller1] TASK [rabbitmq : Put RabbitMQ node into maintenance mode] ********************************************************************************************************************************************************* changed: [controller1] TASK [rabbitmq : Restart rabbitmq container] ********************************************************************************************************************************************************************** changed: [controller1] TASK [rabbitmq : Waiting for rabbitmq to start] ******************************************************************************************************************************************************************* changed: [controller1] PLAY [Restart rabbitmq services] ********************************************************************************************************************************************************************************** TASK [rabbitmq : Get info on RabbitMQ container] ****************************************************************************************************************************************************************** ok: [controller2] TASK [rabbitmq : Put RabbitMQ node into maintenance mode] ********************************************************************************************************************************************************* changed: [controller2] TASK [rabbitmq : Restart rabbitmq container] ********************************************************************************************************************************************************************** changed: [controller2] TASK [rabbitmq : Waiting for rabbitmq to start] ******************************************************************************************************************************************************************* changed: [controller2] PLAY [Apply rabbitmq post-configuration] ************************************************************************************************************************************************************************** TASK [Include rabbitmq post-deploy.yml] *************************************************************************************************************************************************************************** TASK [rabbitmq : Enable all stable feature flags] ************************* Michal Arbet Openstack Engineer Ultimum Technologies a.s. Na Poříčí 1047/26, 11000 Praha 1 Czech Republic +420 604 228 897 michal.arbet(a)ultimum.io *https://ultimum.io <https://ultimum.io/>* LinkedIn <https://www.linkedin.com/company/ultimum-technologies> | Twitter <https://twitter.com/ultimumtech> | Facebook <https://www.facebook.com/ultimumtechnologies/timeline>

1 0

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

22 Sep '24

Hello Stackers, We're in the home stretch of the 2024.2 ("Dalmatian") release cycle this week [1]. OpenStack services will be tagging their final release candidates in preparation for the final release next week. Since the release train never stops, I'd direct your attention to the 2025.1 ("Epoxy") release cycle's schedule [2], active feature development has already begun across the board. We concluded elections for four seats on the OpenStack Technical Committee last week [3]. I'm pleased to welcome first-time TC members Doug Goldstein (cardoe) and Sylvain Bauza (bauzas), and welcome back Ghanshyam Mann (gmann) and Dr. Jens Harbott (frickler). I'd also like to extend congratulations to the PTLs of 37 project teams who volunteered to lead their teams. Most of these leaders have served in the past cycle, and on behalf of the TC, I'd like to thank them for their dedication. I also welcome Guillaume Boutry (gboutry), who will be the PTL for the Sunbeam project for the first time. Last week, the TC merged a goal proposal to move all Ubuntu-based testing in the Zuul CI system to the latest LTS release: 24.04 LTS (Noble Numbat). Ghanshyam Mann (gmann) is expected to lead this goal and is asking project teams to help resolve test failures and incompatibilities when transitioning both unit and functional test jobs to this distribution. This goal may be selected for implementation during the 2025.1 ("Epoxy") release cycle. Several minor governance changes were also merged and proposed, as listed below. === Weekly Meeting === The OpenStack TC weekly meeting was held over IRC on 2024-09-17. The IRC meeting logs are available on eavesdrop [4]. We continued to populate topics for the upcoming virtual Project Teams Gathering [5] and began addressing leadership appointments for two projects with volunteers (Swift and Mistral). We're also checking the community's interest in maintaining the "Watcher" project [6], and waiting on the Tacker team to drop its dependency on "kuryr-kubernetes" so that project can be retired. Amy Marrich (spotz) and Sylvain Bauza (bauzas) recapped the OpenInfra Summit in Suwon, noting the packed rooms and commending the organizers for a great job. Feedback from hallway discussions highlighted the need for improved documentation translation, as the lack of translated materials makes it difficult for new users and contributors, especially in non-English-speaking regions. We’ll discuss this further at the PTG in October. bauzas also raised the need for better tracking and communication regarding the etherpads used in the community for various tasks and contributor work. The next OpenStack TC meeting will be held over IRC in OFTC's #openstack-tc channel on 2024-09-24 at 1800 UTC. I hope you'll be able to attend and participate in the discussions. The agenda for the meeting is on the meeting wiki [7]. Please remember that you can always edit the wiki and propose new topics. === Governance Proposals === ==== Merged ==== - Add goal to migrate CI/CD jobs to Ubuntu Noble | https://review.opendev.org/c/openstack/governance/+/928078 - PTI: Project-first wording | https://review.opendev.org/c/openstack/governance/+/929644 - Charms: Retire unmaintained charms | https://review.opendev.org/c/openstack/governance/+/926793 - Add TC/PTL results from the 2025.1 election | https://review.opendev.org/c/openstack/governance/+/929940 ==== Open for Review ==== - Appoint Tim Burke as PTL for Swift | https://review.opendev.org/c/openstack/governance/+/928881 - Add Axel Vanzaghi as PTL for Mistral | https://review.opendev.org/c/openstack/governance/+/927962 - Retire all single charm repositories | https://review.opendev.org/c/openstack/governance/+/903490 - Add gouthamr nomination for 2025.1 TC chair | https://review.opendev.org/c/openstack/governance/+/929971 - Add chair nomination folder for 2025.1 | https://review.opendev.org/c/openstack/governance/+/929970 - Select community-wide goal: Migrate CI/CD jobs to Ubuntu Noble | https://review.opendev.org/c/openstack/governance/+/929703 - Mark kuryr-kubernetes and kuryr-tempest-plugin inactive | https://review.opendev.org/c/openstack/governance/+/929698 === Upcoming Events === - 2024-10-08: OpenInfra Monthly Board Meeting: https://board.openinfra.dev/ - 2024-10-15: OpenInfra Days NA, Indianapolis: https://ittraining.iu.edu/explore-topics/titles/oid-iu/ - 2024-10-21: OpenInfra Project Teams Gathering: https://openinfra.dev/ptg/ Thank you very much for reading! On behalf of the OpenStack TC, Goutham Pacha Ravi (gouthamr) OpenStack TC Chair [1] 2024.2 "Dalmatian" Release Schedule: https://releases.openstack.org/dalmatian/schedule.html [2] 2025.1 "Epoxy" Release Schedule: https://releases.openstack.org/epoxy/schedule.html [3] 2025.1 TC and PTL Election Results: [4] TC Meeting IRC Log, 2024-09-17: https://meetings.opendev.org/meetings/tc/2024/tc.2024-09-17-18.00.log.html [5] 2025.1 OpenStack TC/PTG planning etherpad: https://etherpad.opendev.org/p/oct2024-ptg-os-tc [6] Retirement of openstack/watcher: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… [7] TC Meeting Agenda, 2024-09-24: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee

1 0

[upgrade][openstack] OpenStack Upgrade Procedure
by Ammar Al-Sayegh 21 Sep '24

21 Sep '24

Hello, I need to upgrade an OpenStack installation for the first time. The system Admin who performed the original installation is no longer available. How can I determine the current OpenStack version, modules installed, type of installation, and networking paradigm from OpenStack Horizon? Once determined, where I can find the appropriate upgrade procedure? Thank you. -ammar

2 1

[networking-mlnx] Project Health
by William Szumski 21 Sep '24

21 Sep '24

Hi all, I've noticed that there hasn't been any stable releases of networking-mlnx since stable/zed and was just wondering if this project still has any active maintainers. I would be interested in helping to keep this project going, so please give me a shout if you require any assistance. Thanks for all your hard work, Will

3 3

[unmaintained][cinder] question about zuul jobs for unmaintained branches
by Brian Rosmaita 20 Sep '24

20 Sep '24

Hello Unmaintained maintenance team, I was reviewing a cinder-tempest-plugin patch (which is in an un-branched repository), and noticed that we have a bunch of Zuul cinder jobs defined for stable branches that no longer exist, for example, stable/wallaby [0]. Where this impacts the unmaintained branches is that, for example, unmaintained/wallaby's .zuul.yaml is configured to run (for example) cinder-tempest-plugin-lvm-lio-barbican in the check [1], but you can see on this review, it's not actually running: https://review.opendev.org/c/openstack/cinder/+/926279?tab=change-view-tab-… So, my question is what to do about these unused jobs: (a) delete them (b) only delete stable/x for x <= ussuri, and update the jobs for stable/x for victoria <= x <= zed to unmaintained/x (c) delete them all, but propose a patch to the appropriate unmaintained branches zuul.yaml files that contain the job definition so that the Unmaintained team can make any changes needed to get them running without having to go through the cinder-tempest-plugin-core team's review/approval process (d) something I haven't thought of Thanks! brian [0] https://opendev.org/openstack/cinder-tempest-plugin/src/branch/master/.zuul… [1] https://opendev.org/openstack/cinder/src/branch/unmaintained/wallaby/.zuul.…

2 1

New to OpenStack. Test environment with 1 control node and 2 compute nodes. Unable to migrate or resize instances
by collinl＠churchofjesuschrist.org 20 Sep '24

20 Sep '24

As the subject says, I am new to OpenStack, and have spun up a test cluster with one control node, and two compute nodes. It seems to work for several tasks (i.e. I can spin up a cirros instance on both of the compute nodes, which seems to work just fine) However, when I attempt to migrate an instance from one compute node to the other, the instance goes in to an error state. (In order to get it running again, I have to set the state to active, then reboot the instance) I am not sure which logs will have the required information to help debug this issue, but I have looked through nova and cinder and keystone logs. Nothing I am seeing is obvious to me as to the cause of the failures. Also taking a snapshot seems to fail as well, with this error: Error: Unable to create snapshot. Details Invalid input received: Invalid volume: Volume e12b3ff8-9870-45f9-b59a-c6fb194ed517 status must be available, in-use, but current status is: attaching. (HTTP 400) (Request-ID: req-499d3bf9-97a0-48b2-8565-254a87287cff) (HTTP 400) (Request-ID: req-d0cd5aed-894e-40b2-8a2f-4b22188ec372) Looking at the volumes in my environment, both volumes show a status of "attaching" (both are for a test cirros instance, both are type nfs, and both instances seem to work just fine (meaning I can connect to them either on the console or via ssh and run commands without errors) Is the reason that each of those tasks is failing because of the "attaching" status of the volumes? I spun up the cluster using packstack and all the nodes are installed on Rocky Linux 9.4. I added an nfs backend after packstack was all done, and that does seem to be working, as the ephemeral volumes used to spin up the test instances does seem to be on the nfs storage, rather than the default lvm storage backend. I have installed openstack using the bobcat release of openstack (from the centos-openstack-bobcat repository). I have been crawling through the standalone install documentation to see if I can find something that explains why the instance migration isn't working, but, again, nothing is jumping out at me. Any guidance on where I should be looking, or advice on what I may be missing would be greatly appreciated.

4 10

upper-constraints (< $latest) considered harmful
by Stephen Finucane 20 Sep '24

20 Sep '24

o/ I'll jump straight into it. For those of you not in the loop we're currently going through a situation where it looks like OSC will be held back due to a bug that the Nova gates are highlighted. The actual details aren't hugely important, but what is important is the fact that this bug was first included in the OSC 7.0.0 release, which was released on August 6th. For those of you who are better at mental calendar maths than I am (or already looked at your calendar), you'll know this was over 6 weeks ago, well before the various feature freeze deadlines . and you might ask why did we only spot this last week? That would be because the upper-constraint (henceforth referred to as u-c) bump failed [1] due a different issue, meaning u-c kept us pinned at <= 6.6.1 which in turn meant every CI job *except* the ones running in the OSC gate itself kept testing the old release instead of the thing we were supposed to be released as part of Dalmatian. That only changed last week when 7.1.0 was released and the u-c bump for *that* merged [2], at which point people started shouting and hollering. Now, there is one other important consideration to factor into this, namely that, due to a flaw in our tooling, we didn't end up cutting a release branch for OSC alongside the rest of the client-library deliverables. Had we done so, we'd have seen 7.1.0 much earlier than we actually did [3]. That 7.1.0 release fixed the initial issue that prevented us releasing 7.0.0. However, this doesn't change the fact that 7.0.0 came out 6 weeks ago and not once did we get to test it outside of OSC's gate, and what's worse, we (the SDK team) were totally oblivious to the fact). Had it been known, we'd have cut a new release as soon as the fix [4] for that issue had merged (August 12th, which for the record is over 5 weeks ago). This is not the first time this has happened to us with one of our own dependencies. We had a very similar issue in Bobcat (2023.2) where we cut an oslo.db 13.0.0 release very early in that cycle, followed by a number of subsequent releases, only to have none of them end up making their way into u-c due to issues with some services. We then got to the end of the cycle, realized this, and had to do a frenzied mega revert to get us back to a pre-13.x state and allow us to release an oslo.db deliverable for Bobcat. It also happened with Castellan, whose 4.2.0 release sat waiting to merge for 4 months [4] before undergoing a similar mass revert. Adding more fuel to this fire, it's not just a problem with our own dependencies either. In fact, the problem is probably worse there. Need I remind people that it took 5 releases or 2 years, 8 months and change to uncap SQLAlchemy 2.x (a contributing factor in the oslo.db issue, fwiw). We had to struggle to get Sphinx uncapped in Bobcat [5] and fight to not revert that cap. You currently can't build docs for many projects on Fedora hosts since we're capping, among many other things, the Pillow library. The list goes on. Which brings me to my main points, of which there are three. Firstly: * There needs to be a clear time limit for how long a u-c bump can remain unmerged and a plan for what happens if affected projects have not resolved their issues within that time. There will always be exceptions - no one could rightly have asked services to switch to SQLAlchemy 2.x in a fortnight, and libraries can have legit bugs that justify a block - but those exceptions should be well-understood and, as with the bumps themselves, time-limited. A project that needs 4 releases to adapt to a crucial new library version is not a healthy project. secondly: * Caps or u-c bump reverts should similarly be clearly time-limited. We should not be defaulting to e.g re-capping Sphinx because your docs build has started to fail and then leaving that cap in place for months. Cap, fix the issue, and remove the cap asap. and, finally: * A failing u-c bump for an openstack deliverable should be treated with the highest priority 🚨🚨🚨 and should be something that the corresponding team should be made aware of immediately so they can start coordinating a resolution. We should not have u-c patches languishing for weeks, let alone months, only for there to be a last minute panic like this. I have ideas on the above (which basically warrant to more stick/[7]) but, perhaps fortunately, this isn't something I can decide on my own. Nor, should I add, is it something I expect the understaffed and oversubscribed release team to be able to do themselves. Instead, I think it's something that the TC and community as a whole need to settle on. So as soon as we get Dalmatian out the door, let's do that. Cheers, Stephen [1] https://review.opendev.org/c/openstack/requirements/+/925763 [2] https://review.opendev.org/c/openstack/requirements/+/928948 [3] https://review.opendev.org/c/openstack/releases/+/928838 [4] https://review.opendev.org/c/openstack/requirements/+/883141 [5] https://review.opendev.org/c/openstack/requirements/+/891694 [6] https://review.opendev.org/c/openstack/requirements/+/927102 [7] https://y.yarn.co/dbdc0d5b-04e6-4c39-9cd3-44c3be3729ab.mp4

8 9

[release] Release countdown for week R-1, Sep 23-27
by Elõd Illés 20 Sep '24

20 Sep '24

Development Focus ----------------- We are on the final mile of the 2024.2 Dalmatian development cycle! Remember that the 2024.2 Dalmatian final release will include the latest release candidate (for cycle-with-rc deliverables) or the latest intermediary release (for cycle-with-intermediary deliverables) available. September 26th, 2024 is the deadline for final 2024.2 Dalmatian release candidates as well as any last cycle-with-intermediary deliverables. We will then enter a quiet period until we tag the final release on October 2nd, 2024. Teams should be prioritizing fixing release-critical bugs, before that deadline. Otherwise it's time to start planning the 2025.1 Epoxy development cycle, including discussing PTG sessions content, in preparation of Project Teams Gathering. Actions ------- Watch for any translation patches coming through on the stable/2024.2 branch and merge them quickly. If you discover a release-critical issue, please make sure to fix it on the master branch first, then backport the bugfix to the stable/2024.2 branch before triggering a new release. Please drop by #openstack-release with any questions or concerns about the upcoming release ! Upcoming Deadlines & Dates -------------------------- Final 2024.2 Dalmatian release: October 2nd, 2024 Project Teams Gathering: October 21-25, 2024 Előd Illés irc: elodilles @ #openstack-release

1 0

[cinder] Retype encrypted cinder volume to non-encrypted volume
by Jan Wasilewski 20 Sep '24

20 Sep '24

Hi, I would like to ask about the procedure to retype a Cinder volume that is in-use (bootable volume, connected to a VM) from an encrypted (LUKS) type to a non-encrypted type (1000 IOPS). I tried to do this via the CLI[1], and while it seemed to work (at least according to the CLI output), the process didn’t complete successfully. Cinder logs[2] indicate that everything looks more or less fine: the volume is created, the volume migration is OK, and the retype is marked as completed. However, in the end, it doesn’t work (final output of [1]). I reviewed the blueprint at https://blueprints.launchpad.net/cinder/+spec/retype-encrypted-volume, which appears to be implemented. Am I doing something wrong, or does this functionality not work as expected? Thanks in advance for your help and guidance. /JW *[1] Retype from CLI: https://paste.openstack.org/show/bVpFT82oURnanXkixreT/ <https://paste.openstack.org/show/bVpFT82oURnanXkixreT/>[2] cinder-logs: https://paste.openstack.org/show/b5rZpWNMqdi6qdpjaDfg/ <https://paste.openstack.org/show/b5rZpWNMqdi6qdpjaDfg/>*

4 6

[glance] Still not working over uwsgi
by Thomas Goirand 20 Sep '24

20 Sep '24

Hi, I've been told in the past in this very list, that Glance would now work over uwsgi. Though that's not the case. Normal image upload works, but doing a "openstack server backup" fails, as well as shelving (it's the same operation...). We get: "Failed to upload image data due to HTTP error: webob.exc.HTTPRequestEntityTooLarge: Image storage media is full: Object PUT failed" even though the Swift user Glance is configured for isn't over quota. Is there any configuration options that we missed? Or should we still consider that Glance over uwsgi is broken? Cheers, Thomas Goirand (zigo)

3 2

[neutron] Drivers meeting canceled today and next Friday, September 27th
by Brian Haley 20 Sep '24

20 Sep '24

Hello Neutrinos: I'm going to cancel today's and next Friday's drivers meeting as there is no agenda and I have conflicts both days/times. We can spend the time making sure 2024.2 RC is in a good place :) Have a nice weekend! -Brian

1 0

[debian] Dalmatian release validated from the Debian point of view
by Thomas Goirand 20 Sep '24

20 Sep '24

Hi, This is probably a breaking record from my side: I've finished packaging even with all project not being tagged for RC1 ! :) Indeed, I have just finished running tempest on a new Dalmatian release today. Result is: no new tempest failure, so hopefully, no regression. Feel free to start consuming the Debian package of OpenStack for Dalmatian the usual way (for example with extrepo on Bookworm): extrepo enable openstack_dalmatian apt-get update I'll be uploading Dalmatian to Unstable in the next following days. This OpenStack release will be the one in Debian 13, aka Trixie. This will run under Python 3.13, so I'm getting ready to fix Python 3.13 bugs as soon as I can, both upstream and in Debian. Cheers, Thomas Goirand (zigo)

3 2

Farewell o/
by Mark Goddard 19 Sep '24

19 Sep '24

Dear OpenStack, Tomorrow will be my final day working at StackHPC before I move to a new role outside of the OpenStack community. My journey with OpenStack began at Cray 10 years ago, trying to coerce a very fresh Ironic project into managing a rack of PCs and resulting in the SNMP power driver [1]. Since then I moved to StackHPC where I've deployed and maintained many OpenStack systems of different sizes, generally with an element of High Performance Computing (HPC). I've been lucky enough to have had the opportunity to get involved in upstream OpenStack development. Over time I grew from contributor to Kolla & Ironic core to Kolla PTL for 5 cycles. I attended several summits and PTGs, and this really helped in working out how to navigate and get more involved in the community. More recently I have been more focussed on downstream than upstream work, but still marvel at the way so many people around the world come together to volunteer their time and effort to build complex software ecosystems. I'd like to thank everyone in this community who has helped me over the years. It really is a special place. To anyone standing on the sidelines wondering how to get more involved - speak up on IRC, join the PTG, triage bugs, review some code. It doesn't need to take up too much of your time. If you're like me you'll feel self-conscious at first, and unsure about the value you're providing. But keep at it, and over time you'll become an important part of the community. All the best, Mark [1] https://review.opendev.org/c/openstack/ironic/+/118404

8 7

[ironic] [neutron] [ptg] DHCP cross-project session?
by Jay Faulkner 19 Sep '24

19 Sep '24

HI all, Myself and CID from the GR-OSS team are planning on, community willing, adding a new, more reliable DHCP backend to both Ironic and Neutron. Right now, that looks like kea, but we are less concerned about the specific project as much as we are about it not being dnsmasq ( https://bugs.launchpad.net/ironic/+bug/2026757 ). Given neither of us are incredibly familiar with the Neutron codebase, we wanted to get buy in and some general implementation advice. As a note; if desired this can happen outside PTG, but this DHCP conversation is a PTG topic for Ironic so I thought this would be a good place to do it. -- Jay Faulkner

5 7

[Glance] Cancelling Weekly Meeting (Sept 19)
by Pranali Deore 19 Sep '24

19 Sep '24

Hi All, Cancelling today's glance meeting since there is nothing much on agenda & I will also not be around as I've Dr. appointment around the same time. Thanks & Regards, Pranali Deore

1 0

[all][elections][tc][ptl] 2025.1 Epoxy: Technical Committee & PTL Election Conclusion & Results
by Ian Y. Choi 19 Sep '24

19 Sep '24

Thank you to the electorate, to all those who supported and to all candidates who put their name forward for Technical Committee (TC) & Project Team Lead (PTL) in this election. A healthy, open process breeds trust in our decision making capability. Thank you to all those who make this process possible. 1. Please join me in congratulating the 4 newly elected members of the Technical Committee (TC). Ghanshyam Mann (gmann) Jens Harbott (frickler) Sylvain Bauza (bauzas) Doug Goldstein (cardoe) Full results: https://civs1.civs.us/cgi-bin/results.pl?id=E_079cc0f0dda5010c 2. For the results of the PTL election process, please join me in extending congratulations to the following PTLs: * Adjutant: Dale Smith (dalees) * Barbican: Grzegorz Grasza (xek) * Blazar: Pierre Riteau (priteau) * Cinder: Jon Bernard () * Cloudkitty: Rafael Weingartner () * Cyborg: alex song (songwenping) * Designate: Michael Johnson (johnsom) * Glance: Pranali Deore (pdeore) * Heat: Takashi Kajinami (tkajinam) * Horizon: Tatiana Ovchinnikova (tmazur) * Ironic: Riccardo Pittau (rpittau) * Keystone: Dave Wilde (d34dh0r53) * Kolla: Michal Nasiadka (mnasiadka) * Magnum: Jake Yip (jakeyip) * Manila: Carlos Silva (carloss) * Masakari: sam sue () * Monasca: Hasan Acar () * Neutron: Brian Haley (haleyb) * Nova: Sylvain Bauza (bauzas) * Octavia: Gregory Thiemonge (gthiemonge) * OpenStack Charms: James Page (jamespage) * OpenStack Helm: Vladimir Kozhukalov (kozhukalov) * OpenStackAnsible: Dmitriy Rabotyagov (noonedeadpunk) * OpenStackSDK: Artem Goncharov (gtema) * Puppet OpenStack: Takashi Kajinami (tkajinam) * Quality Assurance: Martin Kopec (kopecmartin) * Rally: Andrey Kurilin (andreykurilin) * Skyline: Wenxiang Wu (wu_wenxiang) * Storlets: Takashi Kajinami (tkajinam) * Sunbeam: Guillaume Boutry (gboutry) * Tacker: Yasufumi Ogawa (yasufum) * Telemetry: Erno Kuvaja (jokke_) * Trove: wu chunyang (wuchunyang) * Venus: Eric Zhang () * Vitrage: Dmitriy Rabotyagov (noonedeadpunk) * Zaqar: Hao Wang (wanghao) * Zun: Hongbin Lu () PTL Election: no election required. For remaining projects (without PTL candidates), TC will work on the appointment. Election process details and results are also available here: https://governance.openstack.org/election/ Thank you to all of the candidates, having a good group of candidates helps engage the community in our democratic process. Thank you to all who voted and who encouraged others to vote. We need to ensure your voice is heard. Thank you for another great round. Thank you, /Ian, an election official

2 1

[cinder] No meeting today (9/18)
by Jon Bernard 18 Sep '24

18 Sep '24

Hello all, there will be no meeting today (I have a conflict). If there is something that needs attention feel free to raise it in IRC or reach out directly. Thanks, -- Jon

1 0

[horizon][ironic][swift][qa] cycle-with-intermediary deliverables without recent release
by Elõd Illés 18 Sep '24

18 Sep '24

Hi, Quick reminder that for deliverables following the cycle-with-intermediary model, the release team will use the latest 2024 Dalmatian release available on release week. The following deliverables have done a 2024.2 Dalmatian release, but it was not refreshed in the last two months: * horizon * ironic-inspector * swift * tempest (Note that swift haven't had a release so far in this cycle) You should consider making a new one very soon, so that we don't use an outdated version for the final release. Thanks, Előd Illés irc: elodilles @ #openstack-release

2 1

[keystone] Weekly meeting cancelled 18-Sep-2024
by Dave Wilde 18 Sep '24

18 Sep '24

Hello, I’m on PTO today and will not be conducting the weekly meeting, please reach out on IRC/Matrix should you need anything. Thanks! /Dave

1 0

Volume Detachment issue
by Dipongkor Roy 18 Sep '24

18 Sep '24

Volume not detach from instance fc drive on storage nimble server. Can one help me with this? -- Regards, Dipongkor Roy Cloud Engineer PLEXUS CLOUD Dhaka, Bangladesh

1 0

[openstack][kolla-ansible]Collection ansible.posix does not support Ansible version 2.14.17
by Nguyễn Hữu Khôi 18 Sep '24

18 Sep '24

Hello/ I am deploying openstack 2023.1 with kolla customized images but I get this error: FAILED! => {"changed": false, "msg": "Can not parse the inner module output: b'[WARNING]: Collection ansible.posix does not support Ansible version 2.14.17\\n These images were built from kolla 16.5.1.dev1. Thank you. Nguyen Huu Khoi

4 6

Openstack projects
by engineer2024 18 Sep '24

18 Sep '24

Hi All, Can anyone pont me to some interesting openstack based projects which r not yet implemented and those which need improvement ? Any such websites, information etc.... Thanks elinux

2 1

Opensearch Service Update
by Daniel Pawlik 17 Sep '24

17 Sep '24

Hello, We would like to notify you that the Opensearch service [1] would be updated to a newer version on 17 September 2024 at 12:00 PM UTC. This procedure might take a while, depending of the cluster size. During that time, the Opensearch service would not be available. If anyone has any doubts, please reply to the email. Dan [1] - https://opensearch.logs.openstack.org/_dashboards/app/home

1 1

openstack-ansible
by engineer2024 17 Sep '24

17 Sep '24

In the playbook at https://opendev.org/openstack/openstack-ansible/src/branch/stable/2023.1/pl… , after the play "Basic host setup", it is going to the role 'apt_package_pinning' as shown below: --- PLAY [Gather host facts] ************************************************************************************************************************************************* META: ran handlers META: ran handlers META: ran handlers Read vars_file 'defaults/{{ install_method }}_install.yml' Read vars_file 'defaults/{{ install_method }}_install.yml' Read vars_file 'defaults/{{ install_method }}_install.yml' PLAY [Basic host setup] ************************************************************************************************************************************************** Read vars_file 'defaults/{{ install_method }}_install.yml' TASK [Check for a supported Operating System] **************************************************************************************************************************** task path: /opt/openstack-ansible/playbooks/openstack-hosts-setup.yml:54 container_name: "aio1" physical_host: "aio1" ok: [aio1] => { "changed": false, "msg": "All assertions passed" } [aio1] TASK: Check for a supported Operating System (debug)> c Read vars_file 'defaults/{{ install_method }}_install.yml' META: ran handlers Read vars_file 'defaults/{{ install_method }}_install.yml' TASK [apt_package_pinning : Add apt pin preferences] ********************************************************************************************************************* task path: /etc/ansible/roles/apt_package_pinning/tasks/main.yml:16 container_name: "aio1" ---- Why is it going to the apt pinning role, when it is not mentioned in the playbook anywhere ? Please explain.. Thanks elinux

2 2

[publiccloud-sig] Reminder - next meeting September 18th - 0700 UTC
by Felix Kronlage-Dammers 17 Sep '24

17 Sep '24

Hi everyone, This Wednesday (September 18th) 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 <https://meetpad.opendev.org/publiccloud-sig> See also here for all other details: https://wiki.openstack.org/wiki/PublicCloudSIG <https://wiki.openstack.org/wiki/PublicCloudSIG> See you on Wednesday (-> tomorrow)! felix -- 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

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

17 Sep '24

Hello Stackers, This week, the community has been actively testing the release candidates from the 2024.2 release cycle [1]; you might notice projects re-spin their RCs if blocking bugs are reported. Our 2025.1 election season will conclude tomorrow, 2024-09-18. If you haven't already voted, please check your emails for a ballot [2]. There haven't been any governance changes made by the OpenStack Technical Committee this week. However, there are several proposals available for the community's review. === Weekly Meeting === Last week's meeting of the OpenStack Technical Committee was held on OFTC's #openstack-tc channel on 2024-09-10. The meeting logs are available on eavesdrop [3]. At this meeting, we started compiling a set of topics for the 2025.2 Project Teams' Gathering in October [4]. Please feel free to suggest any topics that may be of interest to you. Dr. Jens Harbott (frickler) shared a tracker organized by the release management team [5]. The tracker highlighted several projects where PTLs or release management liaisons had not reviewed releases for their projects. The release management team has the authority to tag releases of OpenStack software at any time, but it relies on the release liaisons (and Project Team Leads) to vet any release proposals that they make. If you are a Project Team Lead or a release liaison of an OpenStack deliverable that has releases, please take a look at the tracker and the guide on Liaison Responsibilities [6]. Your timely action will help ensure a smooth delivery process for the software you work on. The next meeting of the OpenStack TC is today, 2024-09-17, at 1800 UTC on OFTC's #openstack-tc channel. Please find the agenda for the meeting on the meeting wiki [7]. === Governance Proposals === ==== Open for review ==== - Add goal to migrate CI/CD jobs to Ubuntu Noble | https://review.opendev.org/c/openstack/governance/+/928078 - charms: retire unmaintained charms | https://review.opendev.org/c/openstack/governance/+/926793 - Appoint Tim Burke as PTL for Swift | https://review.opendev.org/c/openstack/governance/+/928881 - Add Axel Vanzaghi as PTL for Mistral | https://review.opendev.org/c/openstack/governance/+/927962 - Retire all single charm repositories | https://review.opendev.org/c/openstack/governance/+/903490 === Upcoming Events === - 2024-09-18: OpenStack 2025.1 Election Polling Ends - 2024-10-15: OpenInfra Days NA, Indianapolis: https://ittraining.iu.edu/explore-topics/titles/oid-iu/ - 2024-10-21: OpenInfra Project Teams Gathering https://openinfra.dev/ptg/ Thank you very much for reading! On behalf of the OpenStack TC, Goutham Pacha Ravi (gouthamr) OpenStack TC Chair [1] Release Schedule: https://releases.openstack.org/dalmatian/schedule.html [2] Combined PTL/TC 2025.1 cycle Election Voting Last Days email: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… [3] TC Meeting IRC Log, 2024-09-10: https://meetings.opendev.org/meetings/tc/2024/tc.2024-09-10-18.00.log.html [4] 2025.1 OpenStack TC/PTG planning Etherpad: https://etherpad.opendev.org/p/oct2024-ptg-os-tc [5] Relmgmt Score Card for Project Teams: https://etherpad.opendev.org/p/r.68bf834e08ac22df93204808812cb166#L479 [6] Relmgmt Liaison Responsibilities: https://docs.openstack.org/project-team-guide/release-management.html#liais… [7] TC Meeting Agenda, 2024-09-17: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee

1 0

[tacker] Cancelling IRC meeting
by Yasufumi Ogawa 17 Sep '24

17 Sep '24

Hi tacker team, I'd like to skip IRC meeting this week since I'm out of office today. Thanks, Yasufumi

1 0

[dev][ptl][release] Cycle highlights reminder (2024.2/Dalmatian)
by Jeremy Stanley 17 Sep '24

17 Sep '24

Just a reminder in case anyone missed it: we're technically a week past the deadline for merging 2024.2/Dalmatian release highlights, but if anyone has something they want to mention then now is the time to write, push and approve it! The OpenInfra marketing machine is getting ready to digest what they find at https://releases.openstack.org/dalmatian/highlights.html and put together a press release and package for news outlets. They're interested in whatever you're excited to include, but especially anything related to AI, digital sovereignty, security, or VMware feature parity. Please get your remaining highlights in ASAP!!! -- Jeremy Stanley

1 0

[cloudkitty] Proposing Matt Crees as core reviewer
by Pierre Riteau 16 Sep '24

16 Sep '24

Hello, I would like to nominate Matt Crees as core reviewer for the CloudKitty project. He has been involved for around a year now and has provided valuable contributions, both as reviews and commits. He is also actively participating in our bi-weekly meetings. Cheers, Pierre Riteau (priteau)

2 1

[all][elections][ptl][tc] Combined PTL/TC 2025.1 cycle Election Voting Last Days
by Slawek Kaplonski 16 Sep '24

16 Sep '24

Hi, We are coming down to the last hours for voting in the TC elections. Voting ends Sep 18, 2024 23:45 UTC. Search your Gerrit preferred email address[0] for the messages with subjects like... Poll: OpenStack 2025.1 Cycle Technical Committee Election Poll That is your ballot and links you to the voting application. Please vote. If you have voted, please encourage your colleagues to vote. Candidate statements are linked to the names of all confirmed candidates: https://governance.openstack.org/election/ What to do if you don't see the email and have a commit in at least one of the official project teams' deliverable repositories[1]: * check the trash of your gerrit Preferred Email address[0], in case it went into trash or spam * find the ID of at least one commit merged to an official deliverable repo[1] over the current and previous cycles, confirm you are an OpenStack Foundation Individual Member[2], and then email the election officials[3] or get in touch in the #openstack-elections channel on the OFTC IRC network. If we can confirm that you are entitled to vote, we will add you to the voters list and you will be emailed a ballot. Please vote! Thank you, [0] Sign into review.openstack.org and go to Settings > Contact Information. Look at the email listed as your Preferred Email. That is where the ballot has been sent. [1] https://opendev.org/openstack/governance/src/tag/to-be-released/reference/p… [2] https://www.openstack.org/profile/ [3] https://governance.openstack.org/election/#election-officials -- Slawek Kaplonski Principal Software Engineer Red Hat

1 0

[sdk] possible bug in the openstacksdk/cloud?
by astepanov2007＠gmail.com 16 Sep '24

16 Sep '24

Hello, Recently, I was debugging an issue related to the ansible openstack.cloud.server module while creating an instance with floating ip attached. A part of stack trace goes below: ... File "/home/user/venv/lib/python3.11/site-packages/openstack/cloud/_compute.py", line 1013, in create_server server = self.wait_for_server( File "/home/user/venv/lib/python3.11/site-packages/openstack/cloud/_compute.py", line 1153, in wait_for_server server = self.get_active_server( File "/home/user/venv/lib/python3.11/site-packages/openstack/cloud/_compute.py", line 1200, in get_active_server return self.add_ips_to_server( File "/home/user/venv/lib/python3.11/site-packages/openstack/cloud/_network_common.py", line 1412, in add_ips_to_server server = self._add_ip_from_pool( File "/home/user/venv/lib/python3.11/site-packages/openstack/cloud/_network_common.py", line 1247, in _add_ip_from_pool f_ip = self.create_floating_ip( File "/home/user/venv/lib/python3.11/site-packages/openstack/cloud/_network_common.py", line 765, in create_floating_ip return self._neutron_create_floating_ip( File "/home/user/venv/lib/python3.11/site-packages/openstack/cloud/_network_common.py", line 824, in _neutron_create_floating_ip network_id = network['id'] ~~~~~~~^^^^^^ TypeError: 'NoneType' object is not subscriptable Tracing this down to openstacksdk python module I have found a suspicious place in the openstacksdk code: if network_name_or_id: try: network = self.network.find_network(network_name_or_id) except exceptions.NotFoundException: raise exceptions.NotFoundException( "unable to find network for floating ips with ID " "{}".format(network_name_or_id) ) network_id = network['id'] https://github.com/openstack/openstacksdk/blob/de07fd02639eb565f10956b612ed… I suppose that this call to self.network.find_network lacks "ignore_missing=True" param. E.g.: network = self.network.find_network(network_name_or_id, ignore_missing=True) This fixed my issue with floating ips, but I'm not sure such patch is suitable for the mainline code of the openstacksdk. Am I correct? Regards, Alexander.

2 2

[neutron] Bug Deputy Report September 9 - 15
by Lucas Alvares Gomes 16 Sep '24

16 Sep '24

Hi, This is the Neutron bug report from September 9th to 15th. *High:* * https://bugs.launchpad.net/neutron/+bug/2080072 - "Failed to delete vpnaas ipsec-site-connections with 502 error, ORM session: SQL execution without transaction in progress" Unassigned * https://bugs.launchpad.net/neutron/+bug/2080199 - "Functional jobs failing with "Too many open files"" Assigned to: Lajos Katona * https://bugs.launchpad.net/neutron/+bug/2080447 - "Update firewall policy interface timeout when it's associated with a large number of rules " Assigned to: dongdong *Medium:* * https://bugs.launchpad.net/neutron/+bug/2080314 - "ML2 plugin: No consumers for q-agent-notifier-port-delete_fanout exchange result in unroutable RabbitMQ messages" Unassigned *Low:* * https://bugs.launchpad.net/neutron/+bug/2079996 - "[OVN] OVN metadata agent check to restart the HAProxy container" Assigned to: Rodolfo Alonso *Needs further triage:* * https://bugs.launchpad.net/neutron/+bug/2080492 - "[OVN] VIP port does not come up when its virtual-parents are trunk sub-ports" Cheers, Lucas

1 0

Re: Migratekit: near-live migrations from VMware to OpenStack
by Oliver Weinmann 14 Sep '24

14 Sep '24

Hi Mohammed, We struggled using virt-v2v directly with OpenStack. Our approach was using ovftool to export the VM as OVA and then create a qcow2 image that we can import in OpenStack. So many manual steps involved. So I tested your tool aganst vsphere 7.x vcenter. But I just can't manage to get it working. It keeps complaining about the path of the source VM. I can use the following just fine with virt-v2v: virt-v2v -v -x --password-file pass.txt -ic vpx:// user123(a)vcenter.somedomain.local /GE%Office%20One/Projects/esx01.somedomain.local?no_verify=1 test-vm-01 Using the same in your tool: docker run -it --rm --privileged \ -v /dev:/dev \ -v /usr/lib64/vmware-vix-disklib/:/usr/lib64/vmware-vix-disklib:ro \ --env-file <(env | grep OS_) registry.atmosphere.dev/library/migratekit:latest migrate \ --vmware-endpoint vcenter.somedomain.local \ --vmware-username user123 \ --vmware-password XXXXXX \ --vmware-path /GE%Office%20One/Projects/esx01.somedomain.local/test-vm-01 Results in: Error: vm '/GE%Office%20One/Projects/ esx01.somedomain.local/test-vm-01 ' not found I tried many different variants of the path none has worked. Is there a way to lookup the path of a VM? I can also use: virsh -c 'vpx:// user123(a)vcenter.somedomain.local /GE%Office%20One/Projects/esx01.somedomain.local?no_verify=1 list --all which shows me all VMs running on that particular ESXi host. Best Regards, Oliver

2 9

neutron
by Saeed 14 Sep '24

14 Sep '24

I run some scenarios with ML2/OVN and ML2/OVS (in all tests security-group has no rule) With the OVN backend, when port security is enabled I can NOT watch the unicast traffic of other instances by tcpdump, but when port security is disabled I can watch other unicast traffic for other instances. I also run the same scenarios when the backend is Openvswitch only (not OVN) I can watch unicast traffic of other instances (enabling or disabling port security has no impact). Is there any link or reference that explicitly explains this issue and the impact of OVN in OpenStack for dropping other traffic? I dump flow rules from openvswitch and compare them, and I'm pretty sure that the OVN adds some rules to drop other unicast traffic. Can I drop the unicast traffic of other instances in Openvswitch when I do not use OVN as the backend? (automatically or by configuration)

1 0

[neutron] OpenStack compute nodes L3 agent reconfiguration `dvr` mode to `dvr_no_external`
by frantisek.reznicek.szn＠gmail.com 14 Sep '24

14 Sep '24

Dear upstream OpenStack colleagues, we recently identified a lot of allocated "network:floatingip_agent_gateway ports" as we were running in pure dvr / dvr_snat modes (compute/network nodes) as also discussed in thread [1]. As we want to reduce amount of "network:floatingip_agent_gateway ports", our approach is to migrate majority of compute nodes from L3 agent `dvr` to `dvr_no_external` mode. Although we have success with empty nodes where we can see the node working as expected so north/south traffic now goes via network nodes on the non-empty compute nodes we struggle. The reconfiguration steps we are taking: 1. our maintenance per each compute node (still in `dvr` mode) 1.1. we first identify all VMs with FIP addresses, keep track of the FIPs and connected ports 1.2. we disconnect each FIP from port 1.3. all VMs on the compute node does not have FIPs 1.4. compute node L3 agent configuration is switched `dvr` -> `dvr_no_external` 1.5 delete `hypervisor network:floatingip_agent_gateway` port 1.6. re-attach all tracked FIPs 1.7. test FIP traffic At the step 1.7. we can see FIPs are not accessible after L3 agent re-configuration. Revert of the L3 agent configuration into `dvr` mode helps to get back the FIP connectivity. Our questions are: 1. Principally, can we get rid of `hypervisor network:floatingip_agent_gateway` ports by switching L3 agent to dvr_no_external mode? Can you think of a better way? 2. Would you recommend other steps how to migrate drom `dvr` to `dvr_no_external`? [2] Is it necesary to restart whole neutron / OVS or reconfigured L3 agent is just enough? Hope for your reply. ;-) Kind Regards, František [1] https://lists.openstack.org/pipermail/openstack-dev/2016-June/096384.html [2] https://opendev.org/openstack/neutron/src/branch/master/releasenotes/notes/…

3 2

[release] Release countdown for week R-2
by Thierry Carrez 13 Sep '24

13 Sep '24

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

1 0

PTG October 2024 Teams List
by Kendall Nelson 13 Sep '24

13 Sep '24

Hello Everyone! The October 2024 Project Teams List is official! The following teams will be attending our Project Team Gathering, taking place October 21-25, 2024! Projects + Teams - OpenInfra Foundation Teams - - Diversity WG - Kata Containers - StarlingX - OpenStack - - Services - - Blazar - Cinder - CloudKitty - Designate - Glance - Horizon - Ironic - Keystone - Kolla - Manila - Neutron - Nova - Octavia - OpenStack-Ansible - OpenStack-Helm - QA - SDK/CLI - Sunbeam - Tacker - Other OpenStack Teams - OpenStack Security SIG - OpenStack Technical Committee - Public Cloud SIG - Adjacent Open Source Communities - - OceanBase If your team was planning to meet and isn’t in this list, please contact ptg(a)openinfra.dev IMMEDIATELY. Soon I will be contacting moderators to sign up for time via the PTGBot[1] once I have it configured for the teams that are signed up to attend the event. Otherwise, please don't forget to register[2] — its FREE! As usual, feel free to let us know if you have any questions! Thanks! [1] PTGBot Docs: https://github.com/openstack/ptgbot#open-infrastructure-ptg-bot [2] PTG Registration: http://ptg.openinfra.dev/

1 0

On pre-commit, black, ruff, ruff-format and everything else $linter related
by Stephen Finucane 13 Sep '24

13 Sep '24

o/ Seeing as we've been doing quite a bit of experimentation on this topic in the SDK team recently, and it's come up in random discussions a few times over recent days, I thought it might be helpful to share a few tips and tricks on how our linting stored has evolved across SDK deliverables. Hopefully it's helpful to someone. Historically, teams have provided a `pep8` tox target to run their linters. Originally this would have run flake8 or the hacking wrapper, but over the years these targets have expanded to cover other linters like bandit, doc8 and mypy, as well as various flake8 plugins. In recent times, we have been slowly introducing use of the pre-commit tool [1]. Initially this was purely additive, as it's a nice help for users working in a terminal (like me!) and mostly duplicated what was defined in the `pep8` target. This duplication led to issues where pre-commit was doing slightly different things from the `pep8` target, so we have evolved this so that the `pep8` target now simply calls pre-commit. This is pretty easy to do now since most if not all of the linters in common use across OpenStack - flake8, hacking, doc8, bandit, etc. - provides pre-commit hooks. I recommend anyone using pre-commit does the same thing otherwise these thing can drift. For example, your pep8 target can become: [testenv:pep8] description = Run style checks. skip_install = true deps = pre-commit commands = pre-commit run --all-files --show-diff-on-failure We've since evolved this further to start changing the linters we've used in general. We first introduced black [2], the automatic code formatting tool. The rationale behind this was to remove the need to even think about code style and focus on the actual semantic change. We're already overburdened, and going back and forth on style issues is a waste of everyone's time. Contributors (particularly new ones) can simply install pre-commit or use the `pep8` tox target and their code will be automatically restyled in a generally non- offensive manner. Is it perfect? No, but it's close enough that we've decided we don't care. When we have introduced black, we have typically kept the changes introduced by black separate from the changes to e.g. the `.pre-commit- config.yaml` or `tox.ini` file. This allows us to introduce a `.git-blame- ignore-revs` file afterwards which some software forges (like GitHub, though sadly not Gittea (yet!)) can use to ignore these bulk update changes when using `git-blame`. You can also configure git locally to ignore this, and I've made an effort to place comments in the files whenever I've added them. In addition to black, we also added other linters like bandit [3] and pyupgrade [4], including these in pre-commit so that they would run automatically on commit and in CI. However, as anyone reading the orange site or surveying the broader Python landscape might be aware, the ruff [5] linter and formatter has been gaining steam and is pretty mature at this point. In recent weeks, we have been migrating pretty much all our linters and formatters - black, pyupgrade, bandit and (most of) flake8 - to ruff and ruff-format. We have kept hacking but only enable the H (hacking) ruleset plus any custom rules for now, but at some point we will explore getting these few hacking rules into ruff or writing them off. In any case, this migration has resulted in a significantly trimmer pre- commit-config.yaml file (and much faster runtime to boot). You can see the end result on a repo like e.g. osc-lib [6]. All in all, I think I can recommend this approach for anyone interested in pursuing it. Linters are far from the most important aspect of development, but I've found these tools to yield a nice improvement in developer experience. Top tips: * Have your 'pep8' target (and any other linter-related target run 'pre-commit' rather than the linters themselves), and don't forget to remove linters from test-requirements.txt once you do (with the exception of hacking if you have custom hacking rules) * Consider using ruff and ruff-format in place of all non-hacking linters/formatters: it's seriously fast and provides rules to cover most of these. * When applying ruff-format or the UP (pyupgrade) ruff rules, do it separately so you can add the commit ID to a .git-blame-ignore-revs file. You should be able to do this pre-merge since Gerrit/Zuul merge patches rather than rebasing them so the commit ID won't change. Other points: * When we first introduced pre-commit, some people noted that installing from Git rather than PyPI introduced a possible attack vector since tags can be changed. Given we only use a small, curated set of linters from trusted sources, I don't know how much of an issue this is but I'll raise it here. * Difficulty backporting code has been highlighted as an blocker for running a formatter like black or ruff-format. We don't do many backports in SDK, OSC etc. so this hasn't been a huge issue. If it were though, we would simply apply the formatter to the stable branch first before backporting. Hope this helps, Stephen [1] https://pre-commit.com/ [2] https://github.com/psf/black [3] https://github.com/PyCQA/bandit [4] https://github.com/asottile/pyupgrade [5] https://github.com/astral-sh/ruff [6] https://opendev.org/openstack/osc-lib/

3 3

[horizon] Weekly meeting cancelled Sept 18
by Tatiana Ovchinnikova 12 Sep '24

12 Sep '24

Hello team, I'm on PTO next week, so I'm cancelling the weekly meeting on September 18. See you on September 25! Regards, Tatiana

1 0

[kolla] Proposing Sven Kieske as Kolla and Kolla-Ansible core
by Michał Nasiadka 12 Sep '24

12 Sep '24

Hello Koalas, I would like to propose Sven Kieske as a core reviewer for Kolla and Kolla-Ansible Sven has been very active and providing insightful feedback to reviews as well as code contributions. If I won’t receive any negative votes until 11th of September - I’ll add Sven in Gerrit on the Kolla weekly meeting on that day. Thanks! Michał Nasiadka mnasiadka(a)gmail.com

7 7

[API] Gitea API return 404
by tzing0013＠gmail.com 11 Sep '24

11 Sep '24

Hi everyone， I'm testing Gitea API, I visit the web[1], and click "Try is out", no matter what I enter there, it returns 404, and I also test "/contents" [2], that's ok. [1] https://opendev.org/api/swagger#/repository/repoListPullRequests [2] https://opendev.org/api/swagger#/repository/repoGetContentsList

2 4

[openstack-ansible]: Move one control node to different chasis
by Ram Ram 11 Sep '24

11 Sep '24

Hi All We are currently running 3 control nodes with LXC containers deployed using openstack-ansible release ussuri and need to move 1 control node on HP blade from one chasis to another chasis. Is there any recommended way/procedure to do that? can we directly move the HP blade from one chasis to another? or we need to install new control node and decommission the older one? Regards Rambo

3 3

[kolla][vpn-as-a-service] docker container missing
by garcetto 10 Sep '24

10 Sep '24

good afternoon, installed all-in-one ubuntu 22.04 based kolla-ansible version 2024.1, so far so good. tried to enable vpnaas, folllowing the instructions here https://docs.openstack.org/kolla-ansible/2024.1/reference/networking/neutro… but still missing the container "neutron_vpnaas_agent". i checked the ansible playbook but see no evidence of deployment of this container, what am i doing wrong? thank you.

3 2

[charms] Proposing Rodrigo Barbieri for OpenStack Charms stable core
by Edward Hope-Morley 10 Sep '24

10 Sep '24

Hi everyone, I'd like to propose Rodrigo Barbieri for the OpenStack Charms stable maintenance team. Rodrigo has been a contributor to the charms for many years and has an impressive history of contributions to across all the OpenStack charms. He always demonstrates an attention to detail and provides insightful feedback in reviews and as such I believe he would make a valuable addition to our charms-stable maintenance core team. Thank you for your contributions to the project Rodrigo! Regards, Ed

2 1