April 2023 - openstack-discuss - lists.openstack.org

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

23 Apr '25

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

3 2

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

22 Apr '25

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

2 1

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

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

10 Oct '24

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

5 9

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

06 Aug '24

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

5 16

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

16 May '24

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

18 27

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

06 Mar '24

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

3 5

[designate] Proposal to deprecate the agent framework and agent based backends
by Michael Johnson 09 Jan '24

09 Jan '24

TLDR: The Designate team would like to deprecate the backend agent framework and the agent based backends due to lack of development and design issues with the current implementation. The following backends would be deprecated: Bind9 (Agent), Denominator, Microsoft DNS (Agent), Djbdns (Agent), Gdnsd (Agent), and Knot2 (Agent). Designate includes many backend DNS server drivers[1], many of which are "native" (also known as xfr type backends) backend implementations. In addition to the "native" backends, Designate has an agent backend[2] that supports other backends via an agent process. To quote the agent backend documentation[2]: This backend uses an extension[3] of the DNS protocol itself to send management requests to the remote agent processes, where the requests will be actioned. The rpc traffic between designate and the agent is both unauthenticated and unencrypted. Do not run this traffic over unsecured networks. Here are the reasons we are proposing to deprecate the agent framework now: 1. The agent protocol used by Designate is using an "unassigned"[4][5] DNS opcode (14) that is causing problems with the dnspython library >= 2.3.0 which is now validating the opcode when building DNS messages. It is a bad practice to use "unassigned" values as they may be officially assigned at any time, likely with an incompatible message format. 2. The agent backends are not tested in the OpenStack jobs[1]. 3. Many of the agent backends have been marked as "Experimental" since 2016 with no additional contributions beyond general repository code maintenance. 4. The protocol between the Designate worker process and the agent process is unauthenticated and unencrypted. 5. We do not know of a development resource to rewrite the agent framework protocol to address issue #1 and #4 above. 6. The introduction of catalog zones[6] may eliminate the need for some of the agent based backend drivers. By marking the agent framework and agent based backends "deprecated" in the Antelope cycle, we would remove the code no earlier than the "C" release of OpenStack (per the OpenStack deprecation policy[7]). In the meantime, issue #1 has been worked around by overriding the dnspython opcode validation[7] as needed in the Designate code (similar to a monkey patch). This is not a sustainable long term solution. The following backend agent based drivers would be marked "deprecated" in addition to the agent framework itself: Bind9 (Agent) Denominator Microsoft DNS (Agent) Djbdns (Agent) Gdnsd (Agent) Knot2 (Agent) We plan to propose patches for the deprecation over the next week, but will not merge them until at least January 24th to allow time for comment from the community. If you have concerns about this deprecation plan or are interested in rewriting the agent framework protocol to address the above issues, please reply to this announcement. Michael [1] https://docs.openstack.org/designate/latest/admin/support-matrix.html [2] https://docs.openstack.org/designate/latest/admin/backends/agent.html [3] https://github.com/openstack/designate/blob/master/designate/backend/privat… [4] https://www.rfc-editor.org/rfc/rfc6895.html#section-2.2 [5] https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-pa… [6] https://www.ietf.org/archive/id/draft-ietf-dnsop-dns-catalog-zones-08.txt [7] https://docs.openstack.org/project-team-guide/deprecation.html [8] https://review.opendev.org/c/openstack/designate/+/870678

3 13

[ptl][tc][winstackers] Final call for Winstackers PTL and maintainers
by James Page 11 Sep '23

11 Sep '23

Hi All As announced by Lucian last November (see [0]) Cloudbase Solutions are no longer in a position to maintain support for running OpenStack on Windows and have also ceased operation of their 3rd party CI for the windows support across a number of OpenStack projects. This situation has resulted in the Winstackers project becoming PTL-less for the 2023.2 cycle with no volunteers responding to the TC's call to fill this role and take this feature in OpenStack forward (see [1]). This is the final call for any maintainers to step forward if this feature is important to them in OpenStack. The last user survey in 2022 indicated that 2% of respondents were running on Hyper-V so this might be important enough to warrant a commitment from someone operating OpenStack on Windows to maintain these features going forward. Here is a reminder from Lucian's original email on the full list of projects which are impacted in some way: * nova hyper-v driver - in-tree plus out-of-tree compute-hyperv driver * os-win - common Windows library for Openstack * neutron hyperv ml2 plugin and agent * ovs on Windows and neutron ovs agent support * cinder drivers - SMB and Windows iSCSI * os-brick Windows connectors - iSCSI, FC, SMB, RBD * ceilometer Windows poller * manila Windows driver * glance Windows support * freerdp gateway The lack of 3rd party CI for testing all of this really needs to be addressed as well. If no maintainers are forthcoming between now and the next PTG in June the TC will need to officially retire the project and start the process of removing support for Windows across the various projects that support this operating system in some way - either directly or through the use of os-win. For clarity this call refers to the use of the Hyper-V virtualisation driver and associated Windows server components to provide WIndows based OpenStack Hypervisors and does not relate to the ability to run Windows images as guests on OpenStack. Regards James [0] https://lists.openstack.org/pipermail/openstack-discuss/2022-November/03104… [1] https://lists.openstack.org/pipermail/openstack-discuss/2023-March/032888.h…

5 9

[openstack-ansible] Recommended branch for a production environment?
by Roger Rivera 05 Sep '23

05 Sep '23

Hello, We have deployed Openstack-Ansible in a test environment and we were wondering what the recommended repository branch is to deploy in a production environment that will be integrated with a separate Ceph cluster. 1. We are thinking about pinning to the stable/zed. Is that recommended over the master branch? 2. Are bugs ironed out on both master and stable/zed with the same cadence? 3. Additionally, is Debian 11 a better alternative than Ubuntu 22 for target hosts? We noticed Ubuntu 22.04 support was added recently, whereas Debian 11 has been supported for quite some time now which leads us to believe its stability/integration could be more mature at this point? Any suggestions will be appreciated. Thank you, -- *Roger *

3 7

[puppet] Proposing core team clean up
by Takashi Kajinami 23 Aug '23

23 Aug '23

Hello, I went through the current core reviewers and found out that the current list includes some people no longer working in the OpenStack community. I'd like to propose removing the following persons from the core reviewer team as we haven't seen these people making any activity in the community recently. * Pradeep Kilambi - puppet-aodh, puppet-ceilometer, puppet-gnocchi, puppet-panko * Richard Megginson - puppet-keystone * Denis Egorenko - puppet-murano * Serg Melikyan - puppet-murano * Sergey Kolekonov - puppet-neutron * David Moreau Simard - puppet-openstack-integration * Yu xingchao - all modules Also, I confirmed that Wes Hayutin is no longer working for OpenStack and he agreed to retire from the core reviewer position. Thus I'll remove him as well. I'll be open for any feedback for one week to hear any thoughts/feedback about this removal. I'd like to take this moment to thank all people for their past work. We always welcome them back if they resume their work in this project. Thank you, Takashi KAJINAMI

3 4

[cloudkitty] question to the scope_key in cloudkitty
by Noah Elias Feldt 28 Jul '23

28 Jul '23

Hello! I am currently trying to get CloudKitty to work with the Prometheus Collector and PyScripts. I noticed that the scope_key for Prometheus can only be changed once in the global configuration file. This was a problem for me because we need different scope_keys for different metrics. Many of the metrics still need the scope key "tenant_id" and some others "project_id". I have found in the documentation of CloudKitty no way to change this for each metric, so I have internally changed something in the source code and added the function to set the scope_key for each metric individually. I just wanted to ask if you would be interested if I submit the small change upstream? Thank you. Regards Noah Feldt

3 3

[cinder] cinder-backup volume stuck in creating
by Satish Patel 27 Jul '23

27 Jul '23

Folks, I have configured nova and cinder with ceph storage. VMs running on ceph storage but now when i am trying to create a backup of cinder volume its getting stuck on creating and doing nothing. Logs also do not give any indication of bad. My cinder.conf [DEFAULT] enabled_backends = rbd-1 backup_driver = cinder.backup.drivers.ceph.CephBackupDriver backup_ceph_conf = /etc/ceph/ceph.conf backup_ceph_user = cinder-backup backup_ceph_chunk_size = 134217728 backup_ceph_pool = backups backup_ceph_stripe_unit = 0 backup_ceph_stripe_count = 0 restore_discard_excess_bytes = true osapi_volume_listen = 10.73.0.181 osapi_volume_listen_port = 8776 Output of "openstack volume service list" showing cinder-backup service is up but when i create a backup it's getting stuck in this stage and no activity. I am not seeing anything getting transferred to the ceph backups pool also. Any clue? or method to debug? # openstack volume backup list --all +--------------------------------------+------+-------------+----------+------+ | ID | Name | Description | Status | Size | +--------------------------------------+------+-------------+----------+------+ | bc844d55-8c5a-4bd3-b0e9-7c4c780c95ad | foo1 | | creating | 20 | +--------------------------------------+------+-------------+----------+------+

5 7

Re: [all] [oslo.messaging] Interest in collaboration on a NATS driver
by Tobias Urdin 22 Jul '23

22 Jul '23

Hello Kai, Great to hear that you’re interested! I’m currently just testing this as a POC directly in devstack so there is real-world testing (not should it yet I think, needs more development first). Best regards Tobias > On 30 Aug 2022, at 18:32, Kai Bojens <kb(a)kbojens.de> wrote: > > Am 29.08.22 um 15:46 schrieb Tobias Urdin: > >> If anybody, or any company, out there would be interested in collaborating in a project to bring this support and maintain it feel free to >> reach out. I’m hoping somebody will bite but atleast I’ve put it out there for all of you. > > Hi, > I am very much interested to take a closer look at your work and maybe contribute to it. Although I'm working with OpenStack for my employer at the moment, I'd do this in my spare time as I'm not sure that I can convince him to add another staging system with a full OpenStack installation just for developing a RabbitMQ replacement. That's not on our agenda as we are mostly users and not developers of OpenStack. > > As I'm pretty new to the messaging topic and had just heard of NATS and your idea, I'll first would have to dive into NATS and then I would take a closer look at your code and maybe try to create some documentation or tests. So, I can't promise anything but as I said I'm very interested in your approach as I also see the massive load from RabbitMQ. > > This brings me to the most important question: Where do you run and test your code? > > Greetings, > Kai

8 30

[ptl] Need PTL volunteer for OpenStack Vitrage
by Ghanshyam Mann 11 Jul '23

11 Jul '23

Hi Eyal, I am reaching out to you as you were PTL for OpenStack Vitrage project in the last cycle. There is no PTL candidate for the next cycle (2023.2), and it is on the leaderless project list. Please check if you or anyone you know would like to lead this project. - https://etherpad.opendev.org/p/2023.2-leaderless Also, if anyone else would like to help leading this project, this is time to let TC knows. -gmann

3 3

Experience with VGPUs
by Oliver Weinmann 22 Jun '23

22 Jun '23

Dear All, we are planning to have a POC on VGPUs in our Openstack cluster. Therefore I have a few questions and generally wanted to ask how well VGPUs are supported in Openstack. The docs, in particular: https://docs.openstack.org/nova/zed/admin/virtual-gpu.html explain quite well the general implementation. But I am more interested in general experience with using VGPUs in Openstack. We currently have a small YOGA cluster, planning to upgrade to Zed soon, with a couple of compute nodes. Currently our users use consumer cards like RTX 3050/3060 on their laptops and the idea would be to provide VGPUs to these users. For this I would like to make a very small POC where we first equip one compute node with an Nvidia GPU. Gladly also a few tips on which card would be a good starting point are highly appreciated. I know this heavily depends on the server hardware but this is something I can figure out later. Also do we need additional software licenses to run this? I saw this very nice presentation from CERN on VGPUs: https://indico.cern.ch/event/776411/contributions/3345183/attachments/18516… In the table they are listing Quadro vDWS licenses. I assume we need these in order to use the cards? Also do we need something like Cyborg for this or is VGPU fully implemented in Nova? Best Regards, Oliver

17 36

[ironic] ARM Support in CI: Call for vendors / contributors / interested parties
by Jay Faulkner 14 Jun '23

14 Jun '23

Hi stackers, Ironic has published an experimental Ironic Python Agent image for ARM64 ( https://tarballs.opendev.org/openstack/ironic-python-agent-builder/dib/file…) and discussed promoting this image to supported via CI testing. However, we have a problem: there are no Ironic developers with easy access to ARM hardware at the moment, and no Ironic developers with free time to commit to improving our support of ARM hardware. So we're putting out a call for help: - If you're a hardware vendor and want your ARM hardware supported? Please come talk to the Ironic community about setting up third-party-CI. - Are you an operator or contributor from a company invested in ARM bare metal? Please come join the Ironic community to help us build this support. Thanks, Jay Faulkner Ironic PTL

6 11

[storlets] Proposal to make Train/Ussuri/Victoria EOL
by Takashi Kajinami 13 Jun '23

13 Jun '23

Hello, Currently we have multiple stable branches open but we haven't seen any backport proposed so far. To reduce number of branches we have to maintain, I'd like to propose retiring old stable branches(train, ussuri and victoria). In case you have any concerns, please let me know. Thank you, Takashi Kajinami

1 1

Kubernetes Conformance 1.24 + 1.25
by Kendall Nelson 05 Jun '23

05 Jun '23

Hello All! First of all, I want to say a huge thanks to Guilherme Steinmuller for all his help ensuring that OpenStack Magnum remains Kubernetes Certified [1]! We are certified for v1.24! However, in digging into the set of conformance tests this round, it appears that we will not be able to get 1.25 certified with the current Magnum. This means that in May when we have to re-cert (every 3 months they reach an EOL because that's k8s release cadence) we will not be able to maintain this which is the other part of why I wanted to write this email - to raise awareness and ask for help digging into what needs to happen to make sure we can retain this. Tangentially related, Guilherme has posted a patch with documentation for how to run the conformance tests for yourself and it could use some reviews [2]. And one last thing, I have begun conversation with the opendev folks about what it might take to setup jobs to run the conformance tests periodically so that we don't have to manually run them when it's time to recert. I am planning on submitting a forum topic for this for those interested :) Long live LOKI! - Kendall Nelson [1] https://github.com/cncf/k8s-conformance/pull/2446 [2] https://review.opendev.org/c/openstack/magnum/+/849156

5 10

[ironic][stable] Proposing EOL of ironic project branches older than Wallaby
by Jay Faulkner 01 Jun '23

01 Jun '23

Hi all, Ironic has a large amount of stable branches still in EM. We need to take action to ensure those branches are either retired or have CI repaired to the point of being usable. Specifically, I'm looking at these branches across all Ironic projects: - stable/queens - stable/rocky - stable/stein - stable/train - stable/ussuri - stable/victoria In lieu of any volunteers to maintain the CI, my recommendation for all the branches listed above is that they be marked EOL. If someone wants to volunteer to maintain CI for those branches, they can propose one of the below paths be taken instead: 1 - Someone volunteers to maintain these branches, and also report the status of CI of these older branches periodically on the Ironic whiteboard and in Ironic meetings. If you feel strongly that one of these branches needs to continue to be in service; volunteering in this way is how to save them. 2 - We seriously reduce CI. Basically removing all tempest tests to ensure that CI remains reliable and able to merge emergency or security fixes when needed. In some cases; this still requires CI fixes as some older inspector branches are failing *installing packages* in unit tests. I would still like, in this case, that someone volunteers to ensure the minimalist CI remains happy. My intention is to let this message serve as notice and a waiting period; and if I've not heard any response here or in Monday's Ironic meeting (in 6 days), I will begin taking action on retiring these branches. This is simply a start; other branches (including bugfix branches) are also in bad shape in CI, but getting these retired will significantly reduce the surface area of projects and branches to evaluate. I know it's painful to drop support for these branches; but we've provided good EM support for these branches for a long time and by pruning them away, we'll be able to save time to dedicate to other items. Thanks, Jay Faulkner

3 5

[Cinder][LVM backend] LVM vg backed by a shared LUN
by wodel youchi 31 May '23

31 May '23

Hi, The examples I could find on the internet using LVM as backend for Cinder, they expose a local disk using lvm via Cinder. I did this configuration and I am wondering if it's correct, especially from a "simultaneous access" point of view. I have an iSCSI target backed by targetcli that exposes a LUN to my compute nodes. I did configure the iscsi connexion manually on each one of them and they all see the LUN, then on one of them I created the cinder-volumes VG (the other nodes can see the modifications), then I configured Cinder with lvm backend using this VG and it worked. I created some volumes on it without issues using my account. But what about when there are multiple tenants that try to create multiple volumes on it, is this configuration safe? Regards.

3 2

[cinder] - Test cases or procedure for active/active support validation
by Roquesalane, Jean-Pierre 30 May '23

30 May '23

Hi community! Here at Dell, we're in the process of certifying our Dell PowerMax storage platform against cinder volume Active/active configuration. I was wondering how vendors who already support this functionality have managed to handle this and if they can share their testing scenario. Thank you. JP Jean-Pierre Roquesalane SW System Sr Principal Engineer - OpenStack Champion Dell Technologies | Security and Ecosystem Software Mobile +33 6 21 86 79 04<tel:1-613-314-8106> Email : jeanpierre.roquesalane(a)dell.com<mailto:jeanpierre.roquesalane@dell.com> [cid:image001.png@01D976C9.D5B91180] Internal Use - Confidential Dell S.A, Si?ge Social 1 rond point Benjamin Franklin 34000 Montpellier. Capital 1,782,769 Euros, 351 528 229 RCS Montpellier -APE 4651Z -TVA Intracommunautaire FR 20 351 528 229, SIRET 351 528 229 00088 Vat Number : FR 20351528229 (France) / IT00001709997 (Italy) / ESN0012622G (Spain)

2 1

[kolla-ansible][yoga] Does glance support cinder-nfs as backend?
by wodel youchi 30 May '23

30 May '23

Hi, The openstak documentation says that glance supports cinder as backend, but it does not exclude any backend used by cinder itself. I'm having trouble configuring glance to use a cinder backend which is backed by an nfs share. Is this configuration supported? First, the rootwrap was missing, after adding it, I faced the lack of privileges, which was corrected by starting the glance-api container in privileged mode and finally I am facing a non existing filter error. Glance is trying to mount the nfs share to use it!!! Which I don't understand , why mount a share that is already mounted by cinder which glance is supposed to use as an intermediary!!!? When I push an image I get this error: Stderr: '/var/lib/kolla/venv/bin/glance-rootwrap: Unauthorized command: mount -t nfs 20.1.0.32:/kolla_nfs /var/lib/glance/mnt/nfs/f6f6b4ee42b4f3522a75f422887010ad2c47f8624 f97bf3623b13014f22186b7 (no filter matched)\n' Regards.

3 3

[kolla-ansible][yoga] Glance backend cinder Privsep daemon failed to start operation not permitted
by wodel youchi 30 May '23

30 May '23

Hi, I am trying to configure glance to use cinder as a backend. This is my glance-api.conf [cinder] cinder_store_auth_address = https://dashint.example.com:5000/v3 cinder_store_user_name = cinder cinder_store_password = cinderpass cinder_store_project_name = service cinder_volume_type = nfstype rootwrap_config = /etc/glance/rootwrap.conf ==> /var/log/kolla/glance/glance-api.log <== > 2023-04-12 18:02:20.842 64 INFO oslo.privsep.daemon > [req-62883866-1b53-4032-bdc4-d9a294a837c4 0439953e7cfe4a13a1b4bb118b5dc3c4 > b0f76b5c6dcb457fa716762bbf954837 - default default] Spawned new privsep > daemon via rootwrap > 2023-04-12 18:02:20.733 360 INFO oslo.privsep.daemon [-] privsep daemon > starting > 2023-04-12 18:02:20.735 360 INFO oslo.privsep.daemon [-] privsep process > running with uid/gid: 0/0 > > *2023-04-12 18:02:20.737 360 ERROR oslo.privsep.daemon [-] [Errno 1] > Operation not permitted Traceback (most recent call last): * > File > "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_privsep/daemon.py", > line 584, in helper_main > Daemon(channel, context).run() > File > "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_privsep/daemon.py", > line 394, in run > self._drop_privs() > File > "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_privsep/daemon.py", > line 430, in _drop_privs > capabilities.drop_all_caps_except(self.caps, self.caps, []) > File > "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_privsep/capabilities.py", > line 156, in drop_all_caps_except > raise OSError(errno, os.strerror(errno)) > PermissionError: [Errno 1] Operation not permitted > 2023-04-12 18:02:20.844 64 WARNING oslo_privsep.comm > [req-62883866-1b53-4032-bdc4-d9a294a837c4 0439953e7cfe4a13a1b4bb118b5dc3c4 > b0f76b5c6dcb457fa716762bbf954837 - default > default] Unexpected error: <class 'BrokenPipeError'>: BrokenPipeError: > [Errno 32] Broken pipe > 2023-04-12 18:02:20.844 64 ERROR oslo.privsep.daemon > [req-62883866-1b53-4032-bdc4-d9a294a837c4 0439953e7cfe4a13a1b4bb118b5dc3c4 > b0f76b5c6dcb457fa716762bbf954837 - default > default] Error while sending initial PING to privsep: [Errno 32] Broken > pipe: BrokenPipeError: [Errno 32] Broken pipe > 2023-04-12 18:02:20.844 64 ERROR oslo.privsep.daemon Traceback (most > recent call last): > 2023-04-12 18:02:20.844 64 ERROR oslo.privsep.daemon File > "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_privsep/daemon.py", > line 192, in exchange_ping > 2023-04-12 18:02:20.844 64 ERROR oslo.privsep.daemon reply = > self.send_recv((comm.Message.PING.value,)) > 2023-04-12 18:02:20.844 64 ERROR oslo.privsep.daemon File > "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_privsep/comm.py", > line 186, in send_recv > 2023-04-12 18:02:20.844 64 ERROR oslo.privsep.daemon > self.writer.send((myid, msg)) > 2023-04-12 18:02:20.844 64 ERROR oslo.privsep.daemon File > "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_privsep/comm.py", > line 60, in send > 2023-04-12 18:02:20.844 64 ERROR oslo.privsep.daemon > self.writesock.sendall(buf) > 2023-04-12 18:02:20.844 64 ERROR oslo.privsep.daemon File > "/var/lib/kolla/venv/lib/python3.6/site-packages/eventlet/greenio/base.py", > line 407, in sendall > 2023-04-12 18:02:20.844 64 ERROR oslo.privsep.daemon tail = > self.send(data, flags) > 2023-04-12 18:02:20.844 64 ERROR oslo.privsep.daemon File > "/var/lib/kolla/venv/lib/python3.6/site-packages/eventlet/greenio/base.py", > line 401, in send > 2023-04-12 18:02:20.844 64 ERROR oslo.privsep.daemon return > self._send_loop(self.fd.send, data, flags) > 2023-04-12 18:02:20.844 64 ERROR oslo.privsep.daemon File > "/var/lib/kolla/venv/lib/python3.6/site-packages/eventlet/greenio/base.py", > line 388, in _send_loop > 2023-04-12 18:02:20.844 64 ERROR oslo.privsep.daemon return > send_method(data, *args) > 2023-04-12 18:02:20.844 64 ERROR oslo.privsep.daemon BrokenPipeError: > [Errno 32] Broken pipe > 2023-04-12 18:02:20.844 64 ERROR oslo.privsep.daemon > 2023-04-12 18:02:20.846 64 CRITICAL oslo.privsep.daemon > [req-62883866-1b53-4032-bdc4-d9a294a837c4 0439953e7cfe4a13a1b4bb118b5dc3c4 > b0f76b5c6dcb457fa716762bbf954837 - defau > lt default] Privsep daemon failed to start > 2023-04-12 18:02:20.847 64 ERROR glance_store._drivers.cinder > [req-62883866-1b53-4032-bdc4-d9a294a837c4 0439953e7cfe4a13a1b4bb118b5dc3c4 > b0f76b5c6dcb457fa716762bbf954837 - > default default] Failed to write to volume > 46316c12-6c24-40af-afde-1c16edd616b6.: > oslo_privsep.daemon.FailedToDropPrivileges: Privsep daemon failed to start > 2023-04-12 18:02:20.890 64 ERROR glance.api.v2.image_data > [req-62883866-1b53-4032-bdc4-d9a294a837c4 0439953e7cfe4a13a1b4bb118b5dc3c4 > b0f76b5c6dcb457fa716762bbf954837 - def > ault default] *Failed to upload image data due to internal error: > oslo_privsep.daemon.FailedToDropPrivileges: Privsep daemon failed to start * > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi > [req-62883866-1b53-4032-bdc4-d9a294a837c4 0439953e7cfe4a13a1b4bb118b5dc3c4 > b0f76b5c6dcb457fa716762bbf954837 - default d > efault] Caught error: Privsep daemon failed to start: > oslo_privsep.daemon.FailedToDropPrivileges: Privsep daemon failed to start > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi Traceback (most recent > call last): > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi File > "/var/lib/kolla/venv/lib/python3.6/site-packages/glance/common/wsgi.py", > line 1332, in __call__ > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi request, > **action_args) > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi File > "/var/lib/kolla/venv/lib/python3.6/site-packages/glance/common/wsgi.py", > line 1370, in dispatch > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi return > method(*args, **kwargs) > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi File > "/var/lib/kolla/venv/lib/python3.6/site-packages/glance/common/utils.py", > line 414, in wrapped > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi return func(self, > req, *args, **kwargs) > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi File > "/var/lib/kolla/venv/lib/python3.6/site-packages/glance/api/v2/image_data.py", > line 303, in upload > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi > self._restore(image_repo, image) > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi File > "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py", > line 227, in __exit__ > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi > self.force_reraise() > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi File > "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py", > line 200, in force_reraise > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi raise self.value > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi File > "/var/lib/kolla/venv/lib/python3.6/site-packages/glance/api/v2/image_data.py", > line 163, in upload > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi > image.set_data(data, size, backend=backend) > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi File > "/var/lib/kolla/venv/lib/python3.6/site-packages/glance/notifier.py", line > 497, in set_data > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi > _send_notification(notify_error, 'image.upload', msg) > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi File > "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py", > line 227, in __exit__ > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi > self.force_reraise() > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi File > "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py", > line 200, in force_reraise > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi raise self.value > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi File > "/var/lib/kolla/venv/lib/python3.6/site-packages/glance/notifier.py", line > 444, in set_data > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi > set_active=set_active) > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi File > "/var/lib/kolla/venv/lib/python3.6/site-packages/glance/quota/__init__.py", > line 323, in set_data > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi > set_active=set_active) > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi File > "/var/lib/kolla/venv/lib/python3.6/site-packages/glance/location.py", line > 585, in set_data > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi > self._upload_to_store(data, verifier, backend, size) > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi File > "/var/lib/kolla/venv/lib/python3.6/site-packages/glance/location.py", line > 485, in _upload_to_store > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi verifier=verifier) > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi File > "/var/lib/kolla/venv/lib/python3.6/site-packages/glance_store/multi_backend.py", > line 399, in add_with_multihash > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi image_id, data, > size, hashing_algo, store, context, verifier) > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi File > "/var/lib/kolla/venv/lib/python3.6/site-packages/glance_store/multi_backend.py", > line 481, in store_add_to_backe > nd_with_multihash > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi image_id, data, > size, hashing_algo, context=context, verifier=verifier) > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi File > "/var/lib/kolla/venv/lib/python3.6/site-packages/glance_store/driver.py", > line 279, in add_adapter > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi metadata_dict) = > store_add_fun(*args, **kwargs) > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi File > "/var/lib/kolla/venv/lib/python3.6/site-packages/glance_store/capabilities.py", > line 176, in op_checker > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi return > store_op_fun(store, *args, **kwargs) > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi File > "/var/lib/kolla/venv/lib/python3.6/site-packages/glance_store/_drivers/cinder.py", > line 985, in add > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi with > self._open_cinder_volume(client, volume, 'wb') as f: > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi File > "/usr/lib64/python3.6/contextlib.py", line 81, in __enter__ > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi return > next(self.gen) > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi File > "/var/lib/kolla/venv/lib/python3.6/site-packages/glance_store/_drivers/cinder.py", > line 739, in _open_cinder_vol > ume > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi root_helper, > my_ip, use_multipath, enforce_multipath, host=host) > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi File > "/var/lib/kolla/venv/lib/python3.6/site-packages/os_brick/utils.py", line > 169, in trace_logging_wrapper > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi return f(*args, > **kwargs) > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi File > "/var/lib/kolla/venv/lib/python3.6/site-packages/os_brick/initiator/connector.py", > line 240, in get_connector_pr > operties > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi execute=execute)) > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi File > "/var/lib/kolla/venv/lib/python3.6/site-packages/os_brick/initiator/connectors/iscsi.py", > line 70, in get_connec > tor_properties > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi initiator = > iscsi.get_initiator() > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi File > "/var/lib/kolla/venv/lib/python3.6/site-packages/os_brick/initiator/connectors/iscsi.py", > line 963, in get_initi > ator > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi > root_helper=self._root_helper) > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi File > "/var/lib/kolla/venv/lib/python3.6/site-packages/os_brick/executor.py", > line 53, in _execute > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi result = > self.__execute(*args, **kwargs) > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi File > "/var/lib/kolla/venv/lib/python3.6/site-packages/os_brick/privileged/rootwrap.py", > line 172, in execute > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi return > execute_root(*cmd, **kwargs) > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi File > "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_privsep/priv_context.py", > line 269, in _wrap > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi self.start() > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi File > "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_privsep/priv_context.py", > line 283, in start > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi channel = > daemon.RootwrapClientChannel(context=self) > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi File > "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_privsep/daemon.py", > line 374, in __init__ > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi > super(RootwrapClientChannel, self).__init__(sock, context) > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi File > "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_privsep/daemon.py", > line 187, in __init__ > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi > self.exchange_ping() > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi File > "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_privsep/daemon.py", > line 201, in exchange_ping > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi raise > FailedToDropPrivileges(msg) > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi *oslo_privsep.daemon.FailedToDropPrivileges: > Privsep daemon failed to start * > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi > 2023-04-12 18:02:20.927 64 INFO eventlet.wsgi.server > [req-62883866-1b53-4032-bdc4-d9a294a837c4 0439953e7cfe4a13a1b4bb118b5dc3c4 > b0f76b5c6dcb457fa716762bbf954837 - default > default] 20.3.0.34,127.0.0.1 - - [12/Apr/2023 18:02:20] "PUT > /v2/images/52ed7ed7-330e-4249-abb9-5ec99712846f/file HTTP/1.1" 500 430 > 2.727683 > It seems like a lack of privileges, any ideas? Regards.

4 11

[neutron] Deprecate networking-odl project
by Rodolfo Alonso Hernandez 24 May '23

24 May '23

Hello all: During the last releases, the support for "networking-odl" project has decreased. Currently there is no active developer or maintainer in the community. This project depends on https://www.opendaylight.org/; the latest version released is Sulfur (16) while the version still used in the CI is Sodium (11) [1]. I would like first to make a call for developers to update this project. But if this is not possible, I will then start the procedure to deprecate it [2] (**not to retire it**). Regards. [1] https://github.com/openstack/networking-odl/blob/db5c79b3ee5054feb8a17df130… [2] https://docs.openstack.org/project-team-guide/repository.html#deprecating-a…

3 3

Re: 答复: [ptl] Need PTL volunteer for OpenStack Sahara
by Ghanshyam Mann 18 May '23

18 May '23

Thanks Jerry, Brin for the updates and showing interest in Sahara project. In PTG discussion, there were some concern on Sahara maintenance even we had PTL volunteer to lead this project but not much things got merged and gate was broken many times. But let me discuss it in TC meeting tomorrow and update here. -gmann ---- On Mon, 10 Apr 2023 00:22:08 -0700 Brin Zhang(张百林) wrote --- > Hi Gmann, > Jerry Zhou works the same company as qiujunting (Qiujunting has out of the office, so he cannot response us, I am so sorry), and he will be involved in Sahara. > Hope TC can add him in Sahara team, let him gradually complete the maintenance of the Sahara project. > Thanks. > > brinzhang > > -----邮件原件----- > 发件人: Jerry Zhou (周鑫勇) zhouxinyong(a)inspur.com> > 发送时间: 2023年4月7日 11:10 > 收件人: gmann(a)ghanshyammann.com; Juntingqiu Qiujunting (邱军婷) qiujunting(a)inspur.com> > 抄送: openstack-discuss(a)lists.openstack.org; Tom Guo(郭涛2810) guotao.bj(a)inspur.com>; Brin Zhang(张百林) zhangbailin(a)inspur.com>; Weiting Kong (孔维亭) kongweiting(a)inspur.com> > 主题: 答复: [ptl] Need PTL volunteer for OpenStack Sahara > > Hi Gmann, > I can lead this project. > > -----邮件原件----- > 发件人: Ghanshyam Mann gmann(a)ghanshyammann.com> > 发送时间: 2023年3月23日 2:35 > 收件人: Qiujunting qiujunting(a)inspur.com>; openstack-discuss openstack-discuss(a)lists.openstack.org> > 主题: [ptl] Need PTL volunteer for OpenStack Sahara > > Hi Qiu, > > I am reaching out to you as you were PTL for OpenStack Sahara project in the last cycle. > > There is no PTL candidate for the next cycle (2023.2), and it is on the leaderless project list. Please check if you or anyone you know would like to lead this project. > > - https://etherpad.opendev.org/p/2023.2-leaderless > > Also, if anyone else would like to help leading this project, this is time to let TC knows. > > -gmann > >

4 7

[heat][magnum][tacker] Future of SoftwareDeployment support
by Takashi Kajinami 09 May '23

09 May '23

Hello, We discussed this briefly in the past thread where we discussed maintenance of os-*-agent repos, and also talked about this topic during Heat PTG, but I'd like to formalize the discussion to get a clear agreement. Heat has been supporting SoftwareDeployment resources to configure software in instances using some agents such as os-collect-config[1]. [1] https://docs.openstack.org/heat/latest/template_guide/software_deployment.h… This feature was initially developed to be used by TripleO (IIUC), but TripleO is retired now and we are losing the first motivation to maintain the feature. # Even TripleO replaced most of its usage of softwaredeployment by config-download lately. Because the heat project team has drunk dramatically recently, we'd like to put more focus on core features. For that aim we are now wondering if we can deprecate and remove this feature, and would like to hear from anyone who has any concerns about this. Quickly looking through the repos, it seems currently Magnum and Tacker are using SoftwareDeployment, and it'd be nice especially if we can understand their current requirements. 1. Magnum It seems SoftwareDeployment is used by k8s_fedora_atomic_v1 driver but I'm not too sure whether this driver is still supported, because Fedora Atomic was EOLed a while ago, right ? 2. Tacker SoftwareDeployment can be found in only test code in the tacker repo. We have some references kept in heat-translator which look related to TOSCA templates. Thank you, Takashi Kajinami

4 8

[all][tc][release] Hold the Python3.8 dropping
by Ghanshyam Mann 08 May '23

08 May '23

Hello Everyone, As you know the gate is breaking due to Python3.8 drop[1][2], which we discussed in the TC channel and meeting[3]. TC is preparing the guidelines on not dropping Python3.8 in 2023.2 pti. Meanwhile, governance guidelines are prepared, this email is a heads-up to hold the dropping of Python3.8 from your project/repo. Do not bump the min py version in setup.cfg (do not bump version in python_requires ). @Release team, It will be helpful if you can check/hold the release of any project/lib dropping the Python3.8. [1] https://lists.openstack.org/pipermail/openstack-discuss/2023-April/033450.h… [2] https://lists.openstack.org/pipermail/openstack-discuss/2023-April/033454.h… [3] https://meetings.opendev.org/meetings/tc/2023/tc.2023-04-25-18.00.log.html#… -gmann

1 1

[openstack-ansible] Proposing Neil Hanlon for core reviewer
by Dmitriy Rabotyagov 04 May '23

04 May '23

Hi everyone, I'm pleased to propose Neil Hanlon as OpenStack-Ansible Core Reviewer. Neil has helped us a lot lately with maintenance of RHEL-like distros - both CentOS Stream and Rocky Linux, and basically has brought in support for the last one. Neil is present at meetings and always is responsive in IRC. At the same time they were providing useful reviews lately [1] If there are no objections, I will add Neil to the team on 25th of April 2023. Until then, please feel free to provide your feedback/opinions on the matter. [1] https://www.stackalytics.io/report/contribution?module=openstackansible-gro…

6 7

[all][tc][vitrage] Final call for Vitrage project maintainers
by Ghanshyam Mann 03 May '23

03 May '23

Hello Everyone, You might have noticed that the Vitrage project is leaderless in this cycle[1]. Eyal, who was the previous PTL and the only maintainer of this project for more than two years[2], will not be able to continue in this project[3]. We thank and appreciate all previous maintainers' work on this project. This is the final call for maintainers. If anyone is using or interested in this project, this is the right time to step up and let us know in this email or IRC(OFTC) #openstack-tc channel. If there is no response by the end of April 2023, we will discuss the retirement of this project. [1] https://etherpad.opendev.org/p/2023.2-leaderless [2] https://www.stackalytics.io/?module=vitrage-group&release=wallaby [3] https://lists.openstack.org/pipermail/openstack-discuss/2023-April/033333.h… -gmann

2 2

[OpenvSwitch][Neutron] native flow based firewall Vs LinuxBridge Iptables firewall
by Satish Patel 02 May '23

02 May '23

Folks, As we know, openvswitch uses a linuxbridge based firewall to implement security-groups on openstack. It works great but it has so many packet hops. It also makes troubleshooting a little complicated. OpenvSwitch does support native firewall features in flows, Does it mature enough to implement in production and replace it with LinuxBridge based IPtables firewall? ~S

3 3

[horizon][nova][masakari] Instances created with "Any AZ" problem
by Nguyễn Hữu Khôi 02 May '23

02 May '23

Hello guys. I playing with Nova AZ and Masakari https://docs.openstack.org/nova/latest/admin/availability-zones.html Masakari will move server by nova scheduler. Openstack Docs describe that: If the server was not created in a specific zone then it is free to be moved to other zones, i.e. the AvailabilityZoneFilter <https://docs.openstack.org/nova/latest/admin/scheduling.html#availabilityzo…> is a no-op. I see that everyone usually creates instances with "Any Availability Zone" on Horzion and also we don't specify AZ when creating instances by cli. By this way, when we use Masakari or we miragrated instances( or evacuate) so our instance will be moved to other zones. Can we attach AZ to server create requests API based on Any Availability Zone to limit instances moved to other zones? Thank you. Regards Nguyen Huu Khoi

5 20

[kolla-ansible][all][nova][zed][latest] USB passthrough / Hot-plug / Cold-plug
by Modyngs 02 May '23

02 May '23

090c090cFolks, A USB device (not necessarily a mass/Flash drive) needs to be connected to one of the VMs (an openstack instance). Openstack installed with kolla-ansible{Latest version/ Also tested on Zed} ALL IN ONE Deployments on ubuntu server 22.04 ( Core i9 12900K). I found the [nova-libvirt] container which contains *virsh *and is able to edit it or use custom config for VMs. I've gone through lots of the docs, to name a few: https://libvirt.org/formatdomain.html https://wiki.openstack.org/wiki/Nova/USB_device_hot_cold_plug https://wiki.openstack.org/wiki/Nova/proposal_about_usb_passthrough https://documentation.suse.com/sles/15-SP1/html/SLES-all/cha-libvirt-config… https://wiki.openstack.org/wiki/Nova/USB_device_hot_cold_plug https://docs.nxp.com/bundle/GUID-487B2E69-BB19-42CB-AC38-7EF18C0FE3AE/page/… but none of them worked for me!! To reproduce: *Cold-Plug :* *$ lsusb (on host)* Bus 001 Device 014: ID 090c:1000 Silicon Motion >>>> Note Device number changed every time I disconnect the device. So it might be different in the changed attempt shown below) *$ docker exec -it nova_libvirt /bin/bash* *%Turn the Desired VM off* *# virsh list --all* Id Name State --------------------------------------------- 2 instance-00000002 running 19 instance-00000008 running - instance-0000000a shut off *# virsh edit instance-0000000a* Add the changes [1][2][3][4],... ( many efforts have been done but few samples of them are) [1]: under <devices> added <hostdev mode='subsystem' type='usb'> <source> <vendor id='0x090c'/> <product id='0x1000'/> </source> </hostdev> [2]:under <devices> added <controller type='usb' index='0'/> <hostdev mode='subsystem' type='usb'> <source> <vendor id='0x090c'/> <product id='0x1000'/> </source> </hostdev> [3]: under <devices> added <hostdev mode='subsystem' type='usb' managed='yes'> <source> <vendor id='0x090c'/> <product id='0x1000'/> </source> <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x0'/> </hostdev> [4]: under <devices> added <controller type='usb' model='nec-xhci' index='0'/> <hostdev mode='subsystem' type='usb' managed='yes'> <source> <vendor id='0x090c'/> <product id='0x1000'/> </source> <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x0'/> </hostdev> [5]: <controller type='usb' index='0'> <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x2'/> </controller> <hostdev mode='subsystem' type='usb' managed='yes'> <source> <vendor id='0x090c'/> <product id='0x1000'/> </source> <address type='usb' bus='1' port='2'/> <controller type='usb' index='0'/> </hostdev> *%Start the VM* *expected behavior:* when login to the VM, lsusb or df -h shows the USB *what happened:* it wont show the USB from the VM *OR *virsh dumpxml instance-0000000a > instance-0000000a.xml and then change the configs as above and then virsh attach-device instance-0000000a --file /path/to/updated-instance-0000000a.xml --config *Hot-Plug :* *$ lsusb (on host)* Bus 001 Device 014: ID 090c:1000 Silicon Motion >>>> Note Device number changed every time I disconnect the device. So it might be different in the changed attempt shown below) *$ docker exec -it nova_libvirt /bin/bash* *# virsh list --all* Id Name State --------------------------------------------- 2 instance-00000002 running 19 instance-00000008 running 20 instance-0000000a running *#nano USB.xml* *%add changes explained in *[1][2][3][4],... *$ virsh attach-device instance-0000000a /path/to/USB.xml/file* *expected behavior:* lsusb or df -h shows the USB *what happened:* it wont show the USB from the VM *Can you please guide me through this? Any recommendation would be much appreciated!Any custom changes comes to your mind ( Reply it) would be solution for this problem /;* Thanks Best regards

2 1

Offline Openstack Release:Train Deployment
by Vineet Thakur 02 May '23

02 May '23

Greetings openstack community members, It's regarding the deployment of openstack release: train on CentoOS 7.9 environment by using openstack-ansible tool. (Offline environment) We are facing challenges to download the packages, some package links are not accessible or somewhere PIP packages are not available as per the constraint requirement list. See: https://artifacts.ci.centos.org/sig-cloudinstance/centos-7-191001/x86-64/ce… For pip packages: https://opendev.org/openstack/requirements/raw/0cfc2ef6318b639bb4287fa051ea… During installation we are facing a lot of errors, and not sure what would be the best approach in such scenarios where packages are not available or need to be downloaded from random sites. We are in the mid of a mega deployment and appreciate it if you can guide us through. Awaiting your response, thank you. Kind Regards, Vineet Thakur

3 3

[kolla-ansible][zed][15.1.0] Horizon failed to load trunk and QoS
by Stefan Bryzga 01 May '23

01 May '23

Hi all, Some time ago I deployed a small cluster with kolla-ansible v15.1.0. Before deployment I enabled neutron_qos and neutron_trunk flags in /etc/kolla/globals.yml. Both functions work fine via cli and I can create new entries via dashboard however horizon won't display created trunks/qos on the page (It shows "No items to display"). In web browser console I get this error while loading page: TypeError: Cannot read properties of undefined (reading 'data') at addTrackBy (output.0a9483334bbd.js:1115:59) at processQueue (output.43a09e34a303.js:1581:786) at output.43a09e34a303.js:1585:110 at Scope.$digest (output.43a09e34a303.js:1636:200) at Scope.$apply (output.43a09e34a303.js:1643:269) at done (output.43a09e34a303.js:1356:123) at completeRequest (output.43a09e34a303.js:1375:20) at XMLHttpRequest.requestLoaded (output.43a09e34a303.js:1368:1) 'Possibly unhandled rejection: {}' Does anyone knows how to fix this? Should I modify any configs to display new entries in horizon? Best Regards, Stefan

2 1

[neutron] Neutron CI not working
by Rodolfo Alonso Hernandez 28 Apr '23

28 Apr '23

Hello Neutrinos: There are some problems in a set of nodes that we are using for tempest tests. This is also affecting other projects like Octavia. Please follow [1] for more information. Yatin has collected information of the error and the affected nodes. Actions: * Temporarily disable these nodes from the pool [2]. That will allow us (Neutron) to continue the CI testing. * Send a support ticket to the node provider. Once we have more information, we'll provide it. Before [2] is merged, please hold your rechecks for the tempest jobs in Neutron. Regards. [1]https://bugs.launchpad.net/neutron/+bug/2017992 [2]https://review.opendev.org/c/openstack/project-config/+/881810

1 1

[neutron] CI meeting on May 2nd cancelled
by Slawek Kaplonski 28 Apr '23

28 Apr '23

Hi, I will be on PTO next Tuesday so lets cancel CI meeting this time. See You on the meeting on May 9th. -- Slawek Kaplonski Principal Software Engineer Red Hat

1 0

[tripleo] Nominate dbengt for tripleo-core !
by Lukas Bezdicka 28 Apr '23

28 Apr '23

Hello, I'd like to nominate Daniel Bengtsson as tripleo-core. He works in upgrades and he'll have to maintain train, wallaby and zed for quite a while. He is a long term contributor to tripleo and oslo. I trust his judgement and I hope you'll support his nomination! Thanks, Lukas Bezdicka

6 6

[CloudKitty] Cancelling weekly meeting 1st May
by Rafael Weingärtner 28 Apr '23

28 Apr '23

Hello guys, May 1st is a public holiday for most of the core reviewers. Therefore, we will be canceling that meeting. If you need any assistance until the next meeting, you can reach me via e-mail. Best regards, -- Rafael Weingärtner

1 0

[kolla] Cancelling weekly meeting 3rd May
by Michał Nasiadka 28 Apr '23

28 Apr '23

Hello Koalas, Since 3rd of May is public holiday in Poland and other cores are on vacation - cancelling weekly meeting. Let’s meet again on 10th May. Best regards, Michal

1 0

[magnum] Propose deprecation of Docker Swarm, CoreOS, fedora-ironic
by Jake Yip 28 Apr '23

28 Apr '23

Hi, Due to limited resources, Magnum team has decided to put most effort into supporting the most popular use case - Kubernetes on Fedora CoreOS. In light of that, we are seeking maintainers for the less well maintained drivers / COE - Docker Swarm, CoreOS and fedora-ironic drivers. The reasons are as follows: - Docker Swarm - It uses Fedora Atomic which has been EOL [1] - CoreOS - It is EOL [2] - fedora-ironic - Not tested, unsure if it is still working If anyone wants to take up maintenance of any of the above, we will be glad. Please let us know either through the ML or at the Magnum meetings. If there are no suitable maintainers, we will start the deprecation of these before end of Antelope. Regards, Jake [1]: https://projectatomic.io/blog/2019/11/fedora-atomic-host-nearing-eol/ [2]: https://www.redhat.com/en/technologies/cloud-computing/openshift/what-was-c… -- Jake Yip Magnum Team

2 3

[neutron] Neutron drivers meeting cancelled
by Rodolfo Alonso Hernandez 28 Apr '23

28 Apr '23

Hello Neutrinos: Due to the lack of agenda, today's drivers meeting is cancelled. Have a nice weekend!

1 0

Re: openstack-discuss Digest, Vol 54, Issue 88
by BEDDA Fadhel 28 Apr '23

28 Apr '23

Good morning, I am still looking for a complete and clear procedure to set up an openstack solution on a vmware worksation virtual machine: ubuntu or centos. THANKS Le lun. 17 avr. 2023 à 17:30, <openstack-discuss-request(a)lists.openstack.org> a écrit : > Send openstack-discuss mailing list submissions to > openstack-discuss(a)lists.openstack.org > > To subscribe or unsubscribe via the World Wide Web, visit > > https://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss > > or, via email, send a message with subject or body 'help' to > openstack-discuss-request(a)lists.openstack.org > > You can reach the person managing the list at > openstack-discuss-owner(a)lists.openstack.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of openstack-discuss digest..." > > > Today's Topics: > > 1. Re: [Kolla-ansible][Yoga] Cannot live migrate VMs (wodel youchi) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 11 Apr 2023 12:57:47 +0100 > From: wodel youchi <wodel.youchi(a)gmail.com> > To: Pierre Riteau <pierre(a)stackhpc.com> > Cc: OpenStack Discuss <openstack-discuss(a)lists.openstack.org> > Subject: Re: [Kolla-ansible][Yoga] Cannot live migrate VMs > Message-ID: > <CAJV_UBDH4tJ11pkOagYpWNVCrZHruTmA6A-k9P= > DLrqchPvNPg(a)mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Hi, > > Indeed, there was a mistake in the cinder.conf file. > Thanks. > > Regards. > > < > https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai… > > > Virus-free.www.avast.com > < > https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai… > > > <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> > > Le mar. 11 avr. 2023 ? 10:45, Pierre Riteau <pierre(a)stackhpc.com> a ?crit > : > > > You should check the status of your Cinder services. > > > > On Sun, 9 Apr 2023 at 19:43, wodel youchi <wodel.youchi(a)gmail.com> > wrote: > > > >> Hi, > >> > >> I cannot live-migrate any VM I have. > >> All my compute nodes are enabled. I have a few VMs, I am in the testing > >> phase. > >> I tried to live-migrate toward an empty node, then toward a node which > >> already had a VM in it. It is the same problem. > >> > >> In the log files I have : > >> > >> Source node : > >> Source > >> > >>> ==> /var/log/kolla/nova/nova-compute.log <== > >>> 2023-04-09 11:32:49.419 7 INFO nova.compute.resource_tracker > >>> [req-4e91d562-d7ad-4585-a827-3db6277fd81e - - - - -] [instance: > >>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7] Updating resource usage from > >>> migration f60eb077-8e1c-404a-aca5-64e5609ca02c > >>> 2023-04-09 11:33:30.118 7 ERROR nova.compute.manager [-] [instance: > >>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7] Pre live migration failed at > >>> computehci02: oslo_messaging.rpc.client.RemoteError: Remote error: > >>> ClientException Gateway Time-out (HTTP 504) > >>> ['Traceback (most recent call last):\n', ' File > >>> > "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_messaging/rpc/server.py", > >>> line 165, in _process_incoming\n res = > >>> self.dispatcher.dispatch(message)\n', ' File > >>> > "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_messaging/rpc/dispatcher.py", > >>> line 309, in dispatch\n return self._do_dispatch(endpoint, method, > ctxt, > >>> args)\n', ' File > >>> > "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_messaging/rpc/dispatcher.py", > >>> line 229, in _do_dispatch\n result = func(ctxt, **new_args)\n', ' > File > >>> > "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/exception_wrapper.py", > >>> line 72, in wrapped\n context, exc, binary)\n', ' File > >>> > "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py", > >>> line 227, in __exit__\n self.force_reraise()\n', ' File > >>> > "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py", > >>> line 200, in force_reraise\n raise self.value\n', ' File > >>> > "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/exception_wrapper.py", > >>> line 63, in wrapped\n return f(self, context, *args, **kw)\n', ' > File > >>> > "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/utils.py", > >>> line 1439, in decorated_function\n return function(self, context, > *args, > >>> **kwargs)\n', ' File > >>> > "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/manager.py", > >>> line 213, in decorated_function\n kwargs[\'instance\'], e, > >>> sys.exc_info())\n', ' File > >>> > "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py", > >>> line 227, in __exit__\n self.force_reraise()\n', ' File > >>> > "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py", > >>> line 200, in force_reraise\n raise self.value\n', ' File > >>> > "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/manager.py", > >>> line 201, in decorated_function\n return function(self, context, > *args, > >>> **kwargs)\n', ' File > >>> > "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/manager.py", > >>> line 8367, in pre_live_migration\n bdm.save()\n', ' File > >>> > "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py", > >>> line 227, in __exit__\n self.force_reraise()\n', ' File > >>> > "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py", > >>> line 200, in force_reraise\n raise self.value\n', ' File > >>> > "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/manager.py", > >>> line 8304, in pre_live_migration\n connector=connector, > >>> mountpoint=bdm.device_name)\n', ' File > >>> > "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/volume/cinder.py", > >>> line 395, in wrapper\n res = method(self, ctx, *args, **kwargs)\n', > ' > >>> File > >>> > "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/volume/cinder.py", > >>> line 433, in wrapper\n res = method(self, ctx, volume_id, *args, > >>> **kwargs)\n', ' File > >>> > "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/volume/cinder.py", > >>> line 813, in attachment_create\n instance_uuid=instance_id)\n', ' > File > >>> > "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py", > >>> line 227, in __exit__\n self.force_reraise()\n', ' File > >>> > "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py", > >>> line 200, in force_reraise\n raise self.value\n', ' File > >>> > "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/volume/cinder.py", > >>> line 801, in attachment_create\n volume_id, _connector, > instance_id)\n', > >>> ' File > >>> > "/var/lib/kolla/venv/lib/python3.6/site-packages/cinderclient/api_versions.py", > >>> line 421, in substitution\n return method.func(obj, *args, > **kwargs)\n', > >>> ' File > >>> > "/var/lib/kolla/venv/lib/python3.6/site-packages/cinderclient/v3/attachments.py", > >>> line 39, in create\n retval = self._create(\'/attachments\', body, > >>> \'attachment\')\n', ' File > >>> "/var/lib/kolla/venv/lib/python3.6/site-packages/cinderclient/base.py", > >>> line 306, in _create\n resp, body = self.api.client.post(url, > >>> body=body)\n', ' File > >>> > "/var/lib/kolla/venv/lib/python3.6/site-packages/cinderclient/client.py", > >>> line 227, in post\n return self._cs_request(url, \'POST\', > **kwargs)\n', > >>> ' File > >>> > "/var/lib/kolla/venv/lib/python3.6/site-packages/cinderclient/client.py", > >>> line 215, in _cs_request\n return self.request(url, method, > >>> **kwargs)\n', ' File > >>> > "/var/lib/kolla/venv/lib/python3.6/site-packages/cinderclient/client.py", > >>> line 201, in request\n raise exceptions.from_response(resp, > body)\n', > >>> 'cinderclient.exceptions.ClientException: Gateway Time-out (HTTP > 504)\n']. > >>> 2023-04-09 11:33:30.118 7 ERROR nova.compute.manager [instance: > >>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7] Traceback (most recent call > last): > >>> 2023-04-09 11:33:30.118 7 ERROR nova.compute.manager [instance: > >>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7] File > >>> > "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/manager.py", > >>> line 8501, in _do_pre_live_migration_from_source > >>> 2023-04-09 11:33:30.118 7 ERROR nova.compute.manager [instance: > >>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7] block_migration, disk, dest, > >>> migrate_data) > >>> 2023-04-09 11:33:30.118 7 ERROR nova.compute.manager [instance: > >>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7] File > >>> > "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/rpcapi.py", > >>> line 948, in pre_live_migration > >>> 2023-04-09 11:33:30.118 7 ERROR nova.compute.manager [instance: > >>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7] **msg_args) > >>> 2023-04-09 11:33:30.118 7 ERROR nova.compute.manager [instance: > >>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7] File > >>> > "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_messaging/rpc/client.py", > >>> line 192, in call > >>> 2023-04-09 11:33:30.118 7 ERROR nova.compute.manager [instance: > >>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7] retry=self.retry, > >>> transport_options=self.transport_options) > >>> 2023-04-09 11:33:30.118 7 ERROR nova.compute.manager [instance: > >>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7] File > >>> > "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_messaging/transport.py", > >>> line 128, in _send > >>> 2023-04-09 11:33:30.118 7 ERROR nova.compute.manager [instance: > >>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7] > >>> transport_options=transport_options) > >>> 2023-04-09 11:33:30.118 7 ERROR nova.compute.manager [instance: > >>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7] File > >>> > "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_messaging/_drivers/amqpdriver.py", > >>> line 691, in send > >>> 2023-04-09 11:33:30.118 7 ERROR nova.compute.manager [instance: > >>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7] > >>> transport_options=transport_options) > >>> 2023-04-09 11:33:30.118 7 ERROR nova.compute.manager [instance: > >>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7] File > >>> > "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_messaging/_drivers/amqpdriver.py", > >>> line 681, in _send > >>> 2023-04-09 11:33:30.118 7 ERROR nova.compute.manager [instance: > >>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7] raise result > >>> 2023-04-09 11:33:30.118 7 ERROR nova.compute.manager [instance: > >>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7] > >>> oslo_messaging.rpc.client.RemoteError: Remote error: ClientException > >>> Gateway Time-out (HTTP 504) > >>> 2023-04-09 11:33:30.118 7 ERROR nova.compute.manager [instance: > >>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7] ['Traceback (most recent call > >>> last):\n', ' File > >>> > "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_messaging/rpc/server.py", > >>> line 165, in _process_incoming\n res = > >>> self.dispatcher.dispatch(message)\n', ' File > >>> > "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_messaging/rpc/dispatcher.py", > >>> line 309, in dispatch\n return self._do_dispatch(endpoint, method, > ctxt, > >>> args)\n', ' File > >>> > "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_messaging/rpc/dispatcher.py", > >>> line 229, in _do_dispatch\n result = func(ctxt, **new_args)\n', ' > File > >>> > "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/exception_wrapper.py", > >>> line 72, in wrapped\n context, exc, binary)\n', ' File > >>> > "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py", > >>> line 227, in __exit__\n self.force_reraise()\n', ' File > >>> > "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py", > >>> line 200, in force_reraise\n raise self.value\n', ' File > >>> > "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/exception_wrapper.py", > >>> line 63, in wrapped\n return f(self, context, *args, **kw)\n', ' > File > >>> > "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/utils.py", > >>> line 1439, in decorated_function\n return function(self, context, > *args, > >>> **kwargs)\n', ' File > >>> > "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/manager.py", > >>> line 213, in decorated_function\n kwargs[\'instance\'], e, > >>> sys.exc_info())\n', ' File > >>> > "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py", > >>> line 227, in __exit__\n self.force_reraise()\n', ' File > >>> > "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py", > >>> line 200, in force_reraise\n raise self.value\n', ' File > >>> > "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/manager.py", > >>> line 201, in decorated_function\n return function(self, context, > *args, > >>> **kwargs)\n', ' File > >>> > "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/manager.py", > >>> line 8367, in pre_live_migration\n bdm.save()\n', ' File > >>> > "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py", > >>> line 227, in __exit__\n self.force_reraise()\n', ' File > >>> > "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py", > >>> line 200, in force_reraise\n raise self.value\n', ' File > >>> > "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/manager.py", > >>> line 8304, in pre_live_migration\n connector=connector, > >>> mountpoint=bdm.device_name)\n', ' File > >>> > "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/volume/cinder.py", > >>> line 395, in wrapper\n res = method(self, ctx, *args, **kwargs)\n', > ' > >>> File > >>> > "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/volume/cinder.py", > >>> line 433, in wrapper\n res = method(self, ctx, volume_id, *args, > >>> **kwargs)\n', ' File > >>> > "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/volume/cinder.py", > >>> line 813, in attachment_create\n instance_uuid=instance_id)\n', ' > File > >>> > "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py", > >>> line 227, in __exit__\n self.force_reraise()\n', ' File > >>> > "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py", > >>> line 200, in force_reraise\n raise self.value\n', ' File > >>> > "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/volume/cinder.py", > >>> line 801, in attachment_create\n volume_id, _connector, > instance_id)\n', > >>> ' File > >>> > "/var/lib/kolla/venv/lib/python3.6/site-packages/cinderclient/api_versions.py", > >>> line 421, in substitution\n return method.func(obj, *args, > **kwargs)\n', > >>> ' File > >>> > "/var/lib/kolla/venv/lib/python3.6/site-packages/cinderclient/v3/attachments.py", > >>> line 39, in create\n retval = self._create(\'/attachments\', body, > >>> \'attachment\')\n', ' File > >>> "/var/lib/kolla/venv/lib/python3.6/site-packages/cinderclient/base.py", > >>> line 306, in _create\n resp, body = self.api.client.post(url, > >>> body=body)\n', ' File > >>> > "/var/lib/kolla/venv/lib/python3.6/site-packages/cinderclient/client.py", > >>> line 227, in post\n return self._cs_request(url, \'POST\', > **kwargs)\n', > >>> ' File > >>> > "/var/lib/kolla/venv/lib/python3.6/site-packages/cinderclient/client.py", > >>> line 215, in _cs_request\n return self.request(url, method, > >>> **kwargs)\n', ' File > >>> > "/var/lib/kolla/venv/lib/python3.6/site-packages/cinderclient/client.py", > >>> line 201, in request\n raise exceptions.from_response(resp, > body)\n', > >>> 'cinderclient.exceptions.ClientException: Gateway Time-out (HTTP > 504)\n']. > >>> 2023-04-09 11:33:30.118 7 ERROR nova.compute.manager [instance: > >>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7] > >>> 2023-04-09 11:33:30.157 7 INFO nova.compute.manager [-] [instance: > >>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7] Swapping old allocation on > >>> dict_keys(['2857ae62-3519-4b13-b700-858c827dd78d']) held by migration > >>> f60eb077-8e1c-404a-aca5-64e5609ca02c for instance > >> > >> > >> > >> In the destination node : > >> > >>> nova-compute.log > >>> > >>> > >>> > >>> > >>> *2023-04-09 11:32:30.052 7 WARNING os_brick.initiator.connectors.nvmeof > >>> [req-69822759-d982-4d01-b448-232796077002 > 0439953e7cfe4a13a1b4bb118b5dc3c4 > >>> b0f76b5c6dcb457fa716762bbf954837 - default default] Process execution > error > >>> in _get_host_uuid: Unexpected error while running command.Command: > blkid > >>> overlay -s UUID -o valueExit code: 2Stdout: ''Stderr: '': > >>> oslo_concurrency.processutils.ProcessExecutionError: Unexpected error > while > >>> running command.* > >>> > >>> 2023-04-09 11:33:05.354 7 INFO nova.compute.resource_tracker > >>> [req-9d480442-87f7-4d4e-a866-c46d645ac7f2 - - - - -] [instance: > >>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7] Updating resource usage from > >>> migration f60eb077-8e1c-404a-aca5-64e5609ca02c > >>> 2023-04-09 11:33:05.392 7 WARNING nova.compute.resource_tracker > >>> [req-9d480442-87f7-4d4e-a866-c46d645ac7f2 - - - - -] Instance > >>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7 has been moved to another host > >>> computehci01(computehci01). There are allocations remaining against the > >>> source host that might need to be removed: {'resources': {'VCPU': 1, > >>> 'MEMORY_MB': 2048}}. > >>> 2023-04-09 11:33:30.086 7 ERROR nova.volume.cinder > >>> [req-69822759-d982-4d01-b448-232796077002 > 0439953e7cfe4a13a1b4bb118b5dc3c4 > >>> b0f76b5c6dcb457fa716762bbf954837 - default default] [instance: > >>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7] Create attachment failed for > volume > >>> 3d7bd0af-5e4c-48fc-a027-f6c9dd6280bb. Error: Gateway Time-out (HTTP > 504) > >>> Code: 504: cinderclient.exceptions.ClientException: Gateway Time-out > (HTTP > >>> 504) > >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server > >>> [req-69822759-d982-4d01-b448-232796077002 > 0439953e7cfe4a13a1b4bb118b5dc3c4 > >>> b0f76b5c6dcb457fa716762bbf954837 - default default] Exception during > >>> message handling: cinderclient.exceptions.ClientException: Gateway > Time-out > >>> (HTTP 504) > >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server Traceback > >>> (most recent call last): > >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server File > >>> > "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_messaging/rpc/server.py", > >>> line 165, in _process_incoming > >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server res = > >>> self.dispatcher.dispatch(message) > >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server File > >>> > "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_messaging/rpc/dispatcher.py", > >>> line 309, in dispatch > >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server return > >>> self._do_dispatch(endpoint, method, ctxt, args) > >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server File > >>> > "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_messaging/rpc/dispatcher.py", > >>> line 229, in _do_dispatch > >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server result = > >>> func(ctxt, **new_args) > >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server File > >>> > "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/exception_wrapper.py", > >>> line 72, in wrapped > >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server context, > >>> exc, binary) > >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server File > >>> > "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py", > >>> line 227, in __exit__ > >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server > >>> self.force_reraise() > >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server File > >>> > "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py", > >>> line 200, in force_reraise > >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server raise > >>> self.value > >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server File > >>> > "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/exception_wrapper.py", > >>> line 63, in wrapped > >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server return > >>> f(self, context, *args, **kw) > >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server File > >>> > "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/utils.py", > >>> line 1439, in decorated_function > >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server return > >>> function(self, context, *args, **kwargs) > >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server File > >>> > "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/manager.py", > >>> line 213, in decorated_function > >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server > >>> kwargs['instance'], e, sys.exc_info()) > >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server File > >>> > "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py", > >>> line 227, in __exit__ > >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server > >>> self.force_reraise() > >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server File > >>> > "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py", > >>> line 200, in force_reraise > >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server raise > >>> self.value > >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server File > >>> > "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/manager.py", > >>> line 201, in decorated_function > >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server return > >>> function(self, context, *args, **kwargs) > >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server File > >>> > "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/manager.py", > >>> line 8367, in pre_live_migration > >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server > bdm.save() > >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server File > >>> > "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py", > >>> line 227, in __exit__ > >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server > >>> self.force_reraise() > >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server File > >>> > "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py", > >>> line 200, in force_reraise > >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server raise > >>> self.value > >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server File > >>> > "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/manager.py", > >>> line 8304, in pre_live_migration > >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server > >>> connector=connector, mountpoint=bdm.device_name) > >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server File > >>> > "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/volume/cinder.py", > >>> line 395, in wrapper > >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server res = > >>> method(self, ctx, *args, **kwargs) > >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server File > >>> > "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/volume/cinder.py", > >>> line 433, in wrapper > >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server res = > >>> method(self, ctx, volume_id, *args, **kwargs) > >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server File > >>> > "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/volume/cinder.py", > >>> line 813, in attachment_create > >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server > >>> instance_uuid=instance_id) > >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server File > >>> > "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py", > >>> line 227, in __exit__ > >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server > >>> self.force_reraise() > >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server File > >>> > "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py", > >>> line 200, in force_reraise > >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server raise > >>> self.value > >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server File > >>> > "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/volume/cinder.py", > >>> line 801, in attachment_create > >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server > volume_id, > >>> _connector, instance_id) > >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server File > >>> > "/var/lib/kolla/venv/lib/python3.6/site-packages/cinderclient/api_versions.py", > >>> line 421, in substitution > >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server return > >>> method.func(obj, *args, **kwargs) > >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server File > >>> > "/var/lib/kolla/venv/lib/python3.6/site-packages/cinderclient/v3/attachments.py", > >>> line 39, in create > >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server retval = > >>> self._create('/attachments', body, 'attachment') > >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server File > >>> "/var/lib/kolla/venv/lib/python3.6/site-packages/cinderclient/base.py", > >>> line 306, in _create > >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server resp, > body > >>> = self.api.client.post(url, body=body) > >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server File > >>> > "/var/lib/kolla/venv/lib/python3.6/site-packages/cinderclient/client.py", > >>> line 227, in post > >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server return > >>> self._cs_request(url, 'POST', **kwargs) > >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server File > >>> > "/var/lib/kolla/venv/lib/python3.6/site-packages/cinderclient/client.py", > >>> line 215, in _cs_request > >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server return > >>> self.request(url, method, **kwargs) > >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server File > >>> > "/var/lib/kolla/venv/lib/python3.6/site-packages/cinderclient/client.py", > >>> line 201, in request > >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server raise > >>> exceptions.from_response(resp, body) > >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server > >>> cinderclient.exceptions.ClientException: Gateway Time-out (HTTP 504) > >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server > >>> 2023-04-09 11:33:30.238 7 INFO nova.virt.block_device > >>> [req-69822759-d982-4d01-b448-232796077002 > 0439953e7cfe4a13a1b4bb118b5dc3c4 > >>> b0f76b5c6dcb457fa716762bbf954837 - default default] [instance: > >>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7] Attempting to driver detach > volume > >>> 3d7bd0af-5e4c-48fc-a027-f6c9dd6280bb from mountpoint /dev/vda > >>> 2023-04-09 11:33:30.239 7 WARNING nova.virt.block_device > >>> [req-69822759-d982-4d01-b448-232796077002 > 0439953e7cfe4a13a1b4bb118b5dc3c4 > >>> b0f76b5c6dcb457fa716762bbf954837 - default default] [instance: > >>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7] Detaching volume from unknown > instance > >>> 2023-04-09 11:33:30.240 7 WARNING nova.virt.libvirt.driver > >>> [req-69822759-d982-4d01-b448-232796077002 > 0439953e7cfe4a13a1b4bb118b5dc3c4 > >>> b0f76b5c6dcb457fa716762bbf954837 - default default] [instance: > >>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7] During detach_volume, instance > >>> disappeared.: nova.exception.InstanceNotFound: Instance > >>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7 could not be found. > >>> 2023-04-09 11:33:30.678 7 INFO nova.virt.libvirt.driver [-] [instance: > >>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7] Instance destroyed successfully. > >>> 2023-04-09 11:33:30.682 7 INFO os_vif > >>> [req-69822759-d982-4d01-b448-232796077002 > 0439953e7cfe4a13a1b4bb118b5dc3c4 > >>> b0f76b5c6dcb457fa716762bbf954837 - default default] Successfully > unplugged > >>> vif > >>> > VIFBridge(active=True,address=fa:16:3e:9b:92:46,bridge_name='qbr46651303-65',has_traffic_filtering=True,id=46651303-65e1-4809-95cc-7c2d97acf16b,network=Network(532470c1-dd2f-4505-8557-ba24e9d4062b),plugin='ovs',port_profile=VIFPortProfileOpenVSwitch,preserve_on_delete=False,vif_name='tap46651303-65') > >>> > >> > >> All I can see is > >> > >> > >> > >> > >> *b0f76b5c6dcb457fa716762bbf954837 - default default] Process execution > >> error in _get_host_uuid: Unexpected error while running command.Command: > >> blkid overlay -s UUID -o valueExit code: 2Stdout: ''Stderr: '': > >> oslo_concurrency.processutils.ProcessExecutionError: Unexpected error > while > >> running command.* > >> > >> Searching the web I didn't find anything useful about this error, and I > >> don't know if it's the origin of the problem. > >> > >> My default storage is ceph rbd, I have an HCI deployment, and all my VMs > >> are for now created on Ceph only. But I have configured two other cinder > >> backends, NFS and LVM, but they are node used for now. > >> > >> Thanks in advance. > >> > >> Regards. > >> > > >

2 1

[release][cinder] please delete cinderlib stable/ussuri branch
by Brian Rosmaita 27 Apr '23

27 Apr '23

Hello Release Team, Some changes were bot-proposed recently to the cinderlib stable/ussuri branch, which was weird because that branch was tagged EOL by change I75092342fe684892f8a73eab9ad5da4515cb1da5. The change merged on 2022-08-31, and the ussuri-eol tag exists in the code repository, but apparently the branch was never deleted. Could you please delete the branch? thanks!

2 3

OpenStack Swift quota
by Xu, Wei [E CPE] 27 Apr '23

27 Apr '23

Hello OpenStack community, Right now, because we tend to limit each user's individual storage capacity, we're trying to implement account and container-level quotas on our OpenStack Swift cluster (Yoga version). Every time we tried to execute a command like "swift post -m quota-bytes: 500" using the Swift CLI client to implement account quotas, it returned a 403 error saying "403 Forbidden [first 60 chars of response] <html><h1>Forbidden</h1><p>Access was denied to this resourc", even if we are using an account already with the reseller/ResellerAdmin role, and both quotas added to the [pipeline:main] on our proxy server. Could you help us identify what could be behind this issue and how to resolve it? Also, it seems like default OpenStack Swift only supports account-level and container-level quota implementation. Is it possible to implement not only user-level but also project-level and domain-level quotas? I'm looking forward to hearing back from you. Thank you very much! Yours sincerely, Wei Xu, M.S. Research Assistant Department of ECpE, Iowa State University

3 9

[kolla-ansible][watcher]Time zone issue in container
by Stefan Bryzga 27 Apr '23

27 Apr '23

Hi all, Recently I created fresh deployment based on kolla-ansible yoga and debian 11. Everything works correctly except Watcher services. Containers are in constant restart loop. On Debian host OS time-related files are as follows: lrwxrwxrwx 1 root root 33 Mar 21 07:53 localtime -> /usr/share/zoneinfo/Europe/Warsaw -rw-r--r-- 1 root root 14 Mar 21 07:53 timezone x@control01:/etc$ cat timezone Europe/Warsaw However every container have: lrwxrwxrwx 1 root root 27 Apr 11 02:00 localtime -> /usr/share/zoneinfo/Etc/UTC -rw-r--r-- 1 root root 14 Mar 21 07:53 timezone (nova-api)[root@control01 etc]# cat timezone Europe/Warsaw In watcher logs I found error: 2023-04-27 10:08:12.607 7 ERROR python-watcher tzlocal.utils.ZoneInfoNotFoundError: 'Multiple conflicting time zone configurations found:\n/etc/timezone: Europe/Warsaw\n/etc/localtime is a symlink to: UTC\nFix the configuration, or set the time zone in a TZ environment variable.\n' 2023-04-27 10:08:12.607 7 ERROR python-watcher Which I believe is caused by wrong symlink for /etc/localtime in containers. Did anyone experience similar issue and know how to resolve it. Best regards, Stefan

2 2

[kolla-ansible] all-in-one deployment on single NIC
by Satish Patel 27 Apr '23

27 Apr '23

Folks, I am trying to create a lab with a single server which has a single NIC card and as you know kolla-ansible needs two nic for all-in-one (api and neutron nic). I want to test VLAN base provider for VMs so can I configure single nic on trunk port and create two VLAN interfaces foo.10 and foo.20 bridge and assign foo.10 to api and foo.20 for neutron. Does that make sense and will help the test lab? I was also reading somewhere that you need to create a veth interface two split single nic for kolla. Did anyone test kolla with single nic with two bridges to create dual nic simulation?

1 0

[neutron] [kolla-ansible] alembic mismatch, schema differences
by Gregory Orange 27 Apr '23

27 Apr '23

Hi all, We've caused ourselves some bother with our neutron database, and I found the following thread instructive, so I hope we can get some help to resolve the bother. https://lists.openstack.org/pipermail/openstack-discuss/2022-November/03131… We're running kolla-ansible train (yes, upgrades planned). We wanted to test something with a wallaby container, and while mainly just pulling train versions of containers on a single compute node, we also changed openstack_release variable to wallaby in globals.yml - this was the mistake. Later that day, we ran kolla-ansible deploy --limit $HOST for a new compute node. We stopped at the following error, realising the above mistake. --- 2023-04-05 12:25:50.487 7 ERROR nova nova.exception.TooOldComputeService: Current Nova version does not support computes older than Victoria but the minimum compute service level in your cell is 40 and the oldest supported service level is 52. 2023-04-05 12:25:50.487 7 ERROR nova --- Now when we deploy a node it gets to task "Running Neutron bootstrap container" and gives error: ---- "alembic.script.revision.ResolutionError: No such revision or branch '6135a7bd4425'" ---- Using insight from the above list thread, I fetched DB entries: MariaDB [neutron]> select * from alembic_version; +--------------+ | version_num | +--------------+ | 5c85685d616d | | 6135a7bd4425 | +--------------+ Running the same from the test cluster which was deployed in the same way: MariaDB [neutron]> select * from alembic_version; +--------------+ | version_num | +--------------+ | 5c85685d616d | | c613d0b82681 | +--------------+ Also, comparing `neutron-db-manage history --verbose` across the two clusters, output is the same in both test and prod, except for the order of 2 lines: ---- -Branches into: 56893333aa52, 30018084ed99 -Branches into: c40fbb377ad, 67c8e8d61d5 +Branches into: 30018084ed99, 56893333aa52 +Branches into: 67c8e8d61d5, c40fbb377ad ---- Finally, I looked at the schema of the neutron database across the two. There are significant differences. for i in `mysql neutron -bNe "show tables;"`; do echo "TABLE: $i"; mysql neutron -e "desc $i;"; done > prod-neutron-descs Repeat for test. $ cat prod-neutron-descs | nc termbin.com 9999 https://termbin.com/8ppi $ cat test-neutron-descs | nc termbin.com 9999 https://termbin.com/cfqz Our cluster and Neutron in particular is operating fine, but we can't deploy new nodes to it. May I have some help on how to resolve this? Thank you, Greg.

4 8

[kolla-ansible][swift][ceph]
by Nguyễn Hữu Khôi 27 Apr '23

27 Apr '23

Hello guys. I am working to make openstack swift save data on ceph. I am using kolla ansible and see it need enable swift first but I don't want to make swift ring on my controller. I just want use external ceph. Pls you give me some advices Thank you Nguyen Huu Khoi

5 8

VM doesn't boot after qemu-img convert from VMDK to RAW/QCOW2 Edit
by David Francisco León Vera 27 Apr '23

27 Apr '23

Hi! Can someone help me? I have an issue migrating VMWare VMs to OpenStack with KVM-QEMU ... the VMDK file converted to qcow2 format doesn't boot, especially with Windows Server 2016 and 2019. I tried a lot of ways, but I still finish with an unbootable disk in Nova. I explained with more details my problem here: https://bugs.launchpad.net/nova/+bug/2017358 -- Before printing, think about your responsibility and commitment to the ENVIRONMENT. The information contained in this email and in any attached file is sent only for the use of the person or entity to which it is addressed and / or authorized third parties. This release may contain confidential and / or legally privileged information. If you are not the recipient or have received this email in error, we request that you notify the sender of this message and destroy this email, its attachments, and any copies or backups thereof immediately. If you are not the indicated recipient, you are notified that the total or partial distribution, printing or reproduction of this message is strictly prohibited, it could be considered illegal and sent to the corresponding authorities. Emails are not necessarily a secure means of transmission, so the sender will not be responsible at any time for the changes in your transfer, for attacks in the medium, so no responsibility is assumed in case of mutations in their transfer and it will always be necessary for the recipient to check them before opening them. Octapus is not responsible for the correct and complete transmission of the information contained in this communication, nor for any delay in receiving it. If you want to know about our privacy notice, go to: <https://on-cloud.com/avisos-de-privacidad/>https://octapus.io/aviso-de-privacidad/ <https://octapus.io/aviso-de-privacidad/> Antes de imprimir piense en su responsabilidad y compromiso con el MEDIO AMBIENTE. La información contenida en este correo electrónico y en cualquier archivo adjunto es enviada únicamente para el uso de la persona o entidad a quien está dirigida y/o terceros autorizados. Este comunicado puede contener información confidencial y/o legalmente privilegiada. Si usted no es el destinatario o ha recibido este correo por error, le solicitamos notificar al emisor de este mensaje y destruir este correo, sus archivos adjuntos y cualquier copia o respaldo del mismo inmediatamente. Si usted no es el destinatario indicado, queda notificado que la distribución, impresión o reproducción, total o parcial del presente mensaje está estrictamente prohibida, podría ser considerado ilegal y remitido a las autoridades correspondientes. Los correos electrónicos no son necesariamente un medio de transmisión seguro, por lo que el remitente no será responsable en ningún momento por los cambios que se sufra en su transferencia, por ataques en el medio, por lo que tampoco se asume ninguna responsabilidad en caso de mutaciones en su transferencia y será siempre necesario para el destinatario revisarlos antes de abrirlos. Octapus no es responsable por la correcta y completa transmisión de la información contenida en esta comunicación, y tampoco por cualquier retraso en su recepción. Si usted desea conocer sobre nuestro aviso de privacidad, ingresa a: <https://on-cloud.com/avisos-de-privacidad/>https://octapus.io/aviso-de-privacidad/ <https://octapus.io/aviso-de-privacidad/>

3 2

(OpenStack-Glance) issue while configuring glance
by Adivya Singh 26 Apr '23

26 Apr '23

Hi Team, I am getting OpenStack Glance issue while configuring, it is a remote NFS which i am mounting in a glance container in /var/lib/glance/images 2023-04-26 14:13:46.973 3260 ERROR glance.api.v2.image_data [req-3b87572c-a508-441b-9a1d-2a0392859f52 4d849540700f412396b24bc913700323 2390988a15a04252825dbb6a6e071321 - default default] Error in store configuration. Adding images to the store is disabled.: glance_store.exceptions.StoreAddDisabled: Configuration for store failed. Adding images to this store is disabled. Regards Adivya Singh

2 1

Re: openstack-discuss Digest, Vol 54, Issue 117
by BEDDA Fadhel 26 Apr '23

26 Apr '23

Good morning, I am still looking for a complete and clear procedure to set up an openstack yoga solution on a vmware worksation virtual machine: ubuntu 22.04 or centos. THANKS Le mer. 26 avr. 2023 à 10:54, <openstack-discuss-request(a)lists.openstack.org> a écrit : > Send openstack-discuss mailing list submissions to > openstack-discuss(a)lists.openstack.org > > To subscribe or unsubscribe via the World Wide Web, visit > > https://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss > > or, via email, send a message with subject or body 'help' to > openstack-discuss-request(a)lists.openstack.org > > You can reach the person managing the list at > openstack-discuss-owner(a)lists.openstack.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of openstack-discuss digest..." > > > Today's Topics: > > 1. [kolla-ansible][swift][ceph] (Nguy?n H?u Kh?i) > 2. Re: OpenStack Swift quota (Thomas Goirand) > 3. [Image Encryption] No meeting on May 1st (Josephine Seifert) > 4. Re: [kolla-ansible][swift][ceph] (Danny Webb) > 5. Re: [kolla-ansible][swift][ceph] (Danny Webb) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 26 Apr 2023 08:08:09 +0700 > From: Nguy?n H?u Kh?i <nguyenhuukhoinw(a)gmail.com> > To: OpenStack Discuss <openstack-discuss(a)lists.openstack.org> > Subject: [kolla-ansible][swift][ceph] > Message-ID: > < > CABAODRc1SLeGT4oxH0srAp8nL06_iNrcTLQioGg1w948SBUSGg(a)mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Hello guys. > I am working to make openstack swift save data on ceph. I am using kolla > ansible and see it need enable swift first but I don't want to make swift > ring on my controller. I just want use external ceph. > Pls you give me some advices > Thank you > Nguyen Huu Khoi >

1 0

[Glance] backend file backed by NFS share
by wodel youchi 26 Apr '23

26 Apr '23

Hi, I have 3 controllers nodes on my deployment, each controller has a Glance-api container on it. Can I create an NFS share, then mount it manually, or via fstab or autofs then use file as backend for Glance pointing to the nfs mount point on the 3 controllers safely, regarding simultaneous access? Regards.

1 0

Cinder Bug Report 2023-04-26
by Sofia Enriquez 26 Apr '23

26 Apr '23

Hello Argonauts, Cinder Bug Meeting Etherpad <https://etherpad.opendev.org/p/cinder-bug-squad-meeting> *High* - Users with a Reader role can create/delete/update a snapshot <https://bugs.launchpad.net/cinder/+bug/2017108>. - *Status:* Unassigned. These issues were found while adding snapshot tests for srbac <https://review.opendev.org/c/openstack/cinder-tempest-plugin/+/872986> . *Incomplete* - wrong hostname passed to os_brick <https://bugs.launchpad.net/cinder/+bug/2017575> - *Status:* Waiting on reports updates. Cheers, -- Sofía Enriquez she/her Software Engineer Red Hat PnT <https://www.redhat.com> IRC: @enriquetaso @RedHat <https://twitter.com/redhat> Red Hat <https://www.linkedin.com/company/red-hat> Red Hat <https://www.facebook.com/RedHatInc> <https://www.redhat.com>

1 0

[Image Encryption] No meeting on May 1st
by Josephine Seifert 26 Apr '23

26 Apr '23

Hi, due to a national holiday there will be no meeting on May the 1st. regards, Jospehine (Luzi)

1 0

[nova][ci] Hold your rechecks
by Sylvain Bauza 25 Apr '23

25 Apr '23

Due to tooz changing their python support to no longer support py3.8 by the 4.0 version, the Nova functional jobs are now blocked until we either block tooz>=4 in upper-constraints or we completely remove py3.8 support for the CI jobs we run. A proposal already exists : https://review.opendev.org/c/openstack/nova/+/881339 Anyway, hold your rechecks. -Sylvain

1 2

[publiccloud-sig] Bi-weekly meeting reminder
by Tobias Rydberg 25 Apr '23

25 Apr '23

Hi everyone, Tomorrow it's time again for our bi-weekly meeting, 0800 UTC in #openstack-operators. Etherpad can be found here [0]. Hope to chat with you tomorrow! [0] https://etherpad.opendev.org/p/publiccloud-sig-meeting BR, Tobias Rydberg -- *Tobias Rydberg* Solution Architect Email: tobias.rydberg(a)cleura.com cleura.com <https://cleura.com/> – The European cloud! Read our press release – City Network becomes Cleura <https://cleura.com/press-releases/city-network-becomes-cleura/>

1 0

[neutron] Deprecated support for Windows OS
by Rodolfo Alonso Hernandez 25 Apr '23

25 Apr '23

Hello Neutrinos: During this release, Neutron is dropping the support for Windows OS [1] and will be removed in 2024.2. This decision [2] was taken after the announcement of the current Winstacker mantainers to step down from this project. Regards. [1]https://review.opendev.org/c/openstack/neutron/+/880980 [2] https://meetings.opendev.org/meetings/networking/2023/networking.2023-04-18… [3] https://lists.openstack.org/pipermail/openstack-discuss/2022-November/03104…

1 0

[neutron] Broken CI "neutron-tempest-plugin-*" jobs
by Rodolfo Alonso Hernandez 25 Apr '23

25 Apr '23

Hello all: Please hold your rechecks for the "neutron-tempest-plugin-*" jobs. We need to bump the python version from 3.8 to 3.9. However, due to an issue in Ubuntu Jammy [1], we are still working with Ubuntu Focal nodes. The problem in Focal is that uWSGI provided in this version doesn't support python3.9. We are pushing new patches for Nova and neutron-tempest-plugin to test possible solutions. If we can't solve this issue, we'll skip these jobs temporarily. I'll send an update as soon as possible. Regards. [1]https://bugs.launchpad.net/neutron/+bug/1999249 [2]https://review.opendev.org/c/openstack/nova/+/868419 [3]https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/879036

2 3

[tc] Next Technical Committee weekly meeting to be held on April 25, 2023
by Nikolla, Kristi 24 Apr '23

24 Apr '23

Hi all, This is a reminder that the next weekly Technical Committee meeting is to be held on Tuesday (April 25) at 1800 UTC on #openstack-tc on OFTC IRC Items can be proposed by editing the wiki page at https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting Unless there are last minute additions (for which I will send a follow-up email) the agenda will be: * Roll call * Follow up on past action items * Gate health check * 2023.2 cycle Leaderless projects ** https://etherpad.opendev.org/p/2023.2-leaderless * Broken docs due to inconsistent release naming * Following new release naming convention by packagers (UCA/RDO) * Schedule of removing support for Python versions by libraries - how it should align with coordinated releases (tooz case) * Recurring tasks check ** Bare 'recheck' state *** https://etherpad.opendev.org/p/recheck-weekly-summary * Open Reviews ** https://review.opendev.org/q/projects:openstack/governance+is:open Thank you, Kristi Nikolla

1 0

Re: [openstack][sharing][kolla ansible]Problems when 1 of 3 controller was be down
by Matt Crees 24 Apr '23

24 Apr '23

Hi all, It seems worth noting here that there is a fix ongoing in oslo.messaging which will resolve the issues with HA failing when one node is down. See here: https://review.opendev.org/c/openstack/oslo.messaging/+/866617 In the meantime, we have also found that setting kombu_reconnect_delay = 0.5 does resolve this issue. As for why om_enable_rabbitmq_high_availability is currently defaulting to false, as Michal said enabling it in stable releases will impact users. This is because it enables durable queues, and the migration from transient to durable queues is not a seamless procedure. It requires that the state of RabbitMQ is reset and that the OpenStack services which use RabbitMQ are restarted to recreate the queues. I think that there is some merit in changing this default value. But if we did this, we should either add additional support to automate the migration from transient to durable queues, or at the very least provide some decent docs on the manual procedure. However, as classic queue mirroring is deprecated in RabbitMQ (to be removed in RabbitMQ 4.0) we should maybe consider switching to quorum queues soon. Then it may be beneficial to leave the classic queue mirroring + durable queues setup as False by default. This is because the migration between queue types (durable or quorum) can take several hours on larger deployments. So it might be worth making sure the default values only require one migration to quorum queues in the future, rather than two (durable queues now and then quorum queues in the future). We will need to make this switch eventually, but right now RabbitMQ 4.0 does not even have a set release date, so it's not the most urgent change. Cheers, Matt >Hi Michal, > >Feel free to propose change of default in master branch, but I don?t think we can change the default in stable branches without impacting users. > >Best regards, >Michal > >> On 11 Apr 2023, at 15:18, Michal Arbet <michal.arbet(a)ultimum.io> wrote: >> >> Hi, >> >> Btw, why we have such option set to false ? >> 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 <mailto:michal.arbet@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> >> >> >> ?t 11. 4. 2023 v 14:48 odes?latel Micha? Nasiadka <mnasiadka(a)gmail.com <mailto:mnasiadka@gmail.com>> napsal: >>> Hello, >>> >>> RabbitMQ HA has been backported into stable releases, and it?s documented here: >>> https://docs.openstack.org/kolla-ansible/yoga/reference/message-queues/rabb… >>> >>> Best regards, >>> Michal >>> >>> W dniu wt., 11.04.2023 o 13:32 Nguy?n H?u Kh?i <nguyenhuukhoinw(a)gmail.com <mailto:nguyenhuukhoinw@gmail.com>> napisa?(a): >>>> Yes. >>>> But cluster cannot work properly without it. :( >>>> >>>> On Tue, Apr 11, 2023, 6:18 PM Danny Webb <Danny.Webb(a)thehutgroup.com <mailto:Danny.Webb@thehutgroup.com>> wrote: >>>>> This commit explains why they largely removed HA queue durability: >>>>> >>>>> https://opendev.org/openstack/kolla-ansible/commit/2764844ee2ff9393a4eebd90… >>>>> From: Satish Patel <satish.txt(a)gmail.com <mailto:satish.txt@gmail.com>> >>>>> Sent: 09 April 2023 04:16 >>>>> To: Nguy?n H?u Kh?i <nguyenhuukhoinw(a)gmail.com <mailto:nguyenhuukhoinw@gmail.com>> >>>>> Cc: OpenStack Discuss <openstack-discuss(a)lists.openstack.org <mailto:openstack-discuss@lists.openstack.org>> >>>>> Subject: Re: [openstack][sharing][kolla ansible]Problems when 1 of 3 controller was be down >>>>> >>>>> >>>>> CAUTION: This email originates from outside THG >>>>> >>>>> Are you proposing a solution or just raising an issue? >>>>> >>>>> I did find it strange that kolla-ansible doesn't support HA queue by default. That is a disaster because when one of the nodes goes down it will make the whole rabbitMQ unacceptable. Whenever i deploy kolla i have to add HA policy to make queue HA otherwise you will endup in problem. >>>>> >>>>> On Sat, Apr 8, 2023 at 6:40?AM Nguy?n H?u Kh?i <nguyenhuukhoinw(a)gmail.com <mailto:nguyenhuukhoinw@gmail.com>> wrote: >>>>> Hello everyone. >>>>> >>>>> I want to summary for who meets problems with Openstack when deploy cluster with 3 controller using Kolla Ansible >>>>> >>>>> Scenario: 1 of 3 controller is down >>>>> >>>>> 1. Login horizon and use API such as nova, cinder will be very slow >>>>> >>>>> fix by: >>>>> >>>>> nano: >>>>> kolla-ansible/ansible/roles/heat/templates/heat.conf.j2 >>>>> kolla-ansible/ansible/roles/nova/templates/nova.conf.j2 >>>>> kolla-ansible/ansible/roles/keystone/templates/keystone.conf.j2 >>>>> kolla-ansible/ansible/roles/neutron/templates/neutron.conf.j2 >>>>> kolla-ansible/ansible/roles/cinder/templates/cinder.conf.j2 >>>>> >>>>> or which service need caches >>>>> >>>>> add as below >>>>> >>>>> [cache] >>>>> backend = oslo_cache.memcache_pool >>>>> enabled = True >>>>> memcache_servers = {{ kolla_internal_vip_address }}:{{ memcached_port }} >>>>> memcache_dead_retry = 0.25 >>>>> memcache_socket_timeout = 900 >>>>> >>>>> https://review.opendev.org/c/openstack/kolla-ansible/+/849487 >>>>> >>>>> but it is not the end >>>>> >>>>> 2. Cannot launch instance or mapping block device(stuck at this step) >>>>> >>>>> nano kolla-ansible/ansible/roles/rabbitmq/templates/definitions.json.j2 >>>>> >>>>> "policies":[ >>>>> {"vhost": "/", "name": "ha-all", "pattern": "^(?!(amq\.)|(.*_fanout_)|(reply_)).*", "apply-to": "all", "definition": {"ha-mode":"all"}, "priority":0}{% if project_name == 'outward_rabbitmq' %}, >>>>> {"vhost": "{{ murano_agent_rabbitmq_vhost }}", "name": "ha-all", "pattern": ".*", "apply-to": "all", "definition": {"ha-mode":"all"}, "priority":0} >>>>> {% endif %} >>>>> ] >>>>> >>>>> nano /etc/kollla/global.conf >>>>> >>>>> [oslo_messaging_rabbit] >>>>> kombu_reconnect_delay=0.5 >>>>> >>>>> >>>>> https://bugs.launchpad.net/oslo.messaging/+bug/1993149 >>>>> https://docs.openstack.org/large-scale/journey/configure/rabbitmq.html >>>>> >>>>> I used Xena 13.4 and Yoga 14.8.1. >>>>> >>>>> Above bugs are critical, but I see that it was not fixed. I am just an operator and I want to share what I encountered for new people who come to Openstack >>>>> >>>>> >>>>> Nguyen Huu Khoi >>> -- >>> Micha? Nasiadka >>> mnasiadka(a)gmail.com <mailto:mnasiadka@gmail.com>

6 18

Query about RBAC for subnets
by Aditya Sathish 24 Apr '23

24 Apr '23

Hello, We currently have an external network that is being interfaced from the physical interface of the compute server to an L3 switch with different subnets to different services. These services (and, by extension, the subnets) must be accessed and controlled by the operator to allow a project only a subset of these services. RBAC can only set rules for the network as a whole. Can this network be made external but only share a few subnets with each project? If not the RBAC way, is there another alternative to achieve the same? Regards, Aditya

2 1

[openstack-helm] Manila chart merged
by Vladimir Kozhukalov 24 Apr '23

24 Apr '23

Hi, everyone I would like to announce that last week we eventually merged the PR that adds the Manila chart. Thanks everyone for their contribution. -- Best regards, Kozhukalov Vladimir

1 0

[neutron] Bug Deputy Report April 17 - 23
by Lucas Alvares Gomes 24 Apr '23

24 Apr '23

Hi, This is the Neutron bug report from April 17th to 24th. *High:* * https://bugs.launchpad.net/neutron/+bug/2016704 - Listing ports creates inefficient database query - Assigned to: Ihtisham ul Haq * https://bugs.launchpad.net/neutron/+bug/2017145 - [OVN] - Logging configuration doesn't change after neutron restart - Assigned to: Elvira García Ruiz * https://bugs.launchpad.net/neutron/+bug/2017216 - [ovn-octavia-provider] batch member update generates out of sync with Octavia DB - Assigned to: Fernando Royo *Medium:* * https://bugs.launchpad.net/neutron/+bug/2016414 - Message when creating new neutron bugs has outdated links - Unassigned * https://bugs.launchpad.net/neutron/+bug/2016862 - [ovn-octavia-provider] Admin_state_up ignored on create a new member - Assigned to: Fernando Royo * https://bugs.launchpad.net/neutron/+bug/2017037 - Improve keepalived test pid termination - Assigned to: Miro Tomaska * https://bugs.launchpad.net/neutron/+bug/2017127 - [ovn-octavia-provider] Fix member update according to the Octavia API definition - Assigned to: Fernando Royo *Low:* * https://bugs.launchpad.net/neutron/+bug/2016413 - api-ref: missing documentation for subnet-onboard - Unassigned *Wishlist:* * https://bugs.launchpad.net/neutron/+bug/2016504 - [rfe]Support specify fixed_ip_address for DHCP or Metadata port - Unassigned * https://bugs.launchpad.net/neutron/+bug/2016960 - neutron fwaas support l2 firewall for ovn driver - Unassigned *Needs further triage:* * https://bugs.launchpad.net/neutron/+bug/2017023 - Tempest: remove test duplication for Compute legacy networking API and Neutron API calls - Unassigned * https://bugs.launchpad.net/neutron/+bug/2017131 - neutron-loki job fails tests with ORM session: SQL execution without transaction in progress - Unassigned Cheers, Lucas

1 0

[Networking-vSphere]
by SCAGLIA Emanuele (NPO) 24 Apr '23

24 Apr '23

Hello, I'd like to know if there is in your opinion any chance that the OVSvApp solution works with Openstack zed release. Regarding how to use it, I found this page: https://github.com/nephoscale-div/OVSvAPP Is it still valid? Thank you in advance, Emanuele Scaglia Emanuele Scaglia Senior System Engineer NPO TORINO s.r.l. [cid:image001.png@01D97443.46C8DCE0]<https://www.nposervices.com/> [cid:image002.png@01D97443.46C8DCE0] emanuele.scaglia(a)nposervices.com<mailto:emanuele.scaglia@nposervices.com> [cid:image003.png@01D97443.46C8DCE0] +39 3666180721<tel:3425965928> [cid:image004.png@01D97443.46C8DCE0] Via Vincenzo Lancia 27, 10141 TORINO<https://www.google.com/maps/place/Via+Vincenzo+Lancia,+27,+10141+Torino+TO/…> [cid:image005.png@01D97443.46C8DCE0] nposervices.com<https://www.nposervices.com/> [cid:image006.png@01D97443.46C8DCE0]<https://www.facebook.com/> [cid:image007.png@01D97443.46C8DCE0]<https://www.twitter.com/> [cid:image008.png@01D97443.46C8DCE0]<https://www.linkedin.com/> [cid:image009.png@01D97443.46C8DCE0]<https://www.instagram.com/> [cid:image010.png@01D97443.46C8DCE0]<https://www.youtube.com/> Sede legale: L.go Dora P. Colletta, 81, 10153- Torino Tel. +39 011 19701225 Fax. +39 011 19781413 P. IVA: 10041060012 The content of this email is confidential and intended for the recipient specified in message only. It is strictly forbidden to share any part of this message with any third party, without a written consent of the sender. If you received this message by mistake, please reply to this message and follow with its deletion, so that we can ensure such a mistake does not occur in the future. AVVERTENZE AI SENSI DEL D.LGS. 196/2003 . Il contenuto di questo messaggio (ed eventuali allegati) e' strettamente confidenziale. L'utilizzo del contenuto del messaggio e' riservato esclusivamente al destinatario. La modifica, distribuzione, copia del messaggio da parte di altri e' severamente proibita. Se non siete i destinatari Vi invitiamo ad informare il mittente ed eliminare tutte le copie del suddetto messaggio. The contents of this message (and all attachments) are strictly confidential. The message is intended exclusively to the addressee. The modification, distribution, or replication of the message from others is strictly forbidden. If you are not the intended addressee, please notify the sender and eliminate all the copies of the message,

2 1

[tc][all] Technical Committee Weekly Summary - April 22, 2023
by Nikolla, Kristi 22 Apr '23

22 Apr '23

Hi all, Here’s another edition of “What’s happening on the Technical Committee.” Meeting ======= The Technical Committee met on April 18, 2023 on the #openstack-tc channel on OFTC IRC. The meeting was chaired by Jay Faulkner. Thanks Jay! The next meeting will be held on April 25, 2023 at 18:00UTC. For more information visit https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting Happenings ========== Leaderless projects ------------------- There's only 3 projects now remaining without a leader[0]. Monasca[1], Vitrage[2] and Winstackers[3]. We're actively looking for people with the time and desire to maintain these projects. A retirement of Winstackers would cause Windows (and Hyper-V) host support to be removed. Meanwhile, TripleO has switched to a distributed project leadership model, and is initiating the process of deprecation.[4] [0]. https://etherpad.opendev.org/p/2023.2-leaderless [1]. https://lists.openstack.org/pipermail/openstack-discuss/2023-April/033112.h… [2]. https://lists.openstack.org/pipermail/openstack-discuss/2023-April/033348.h… [3]. https://lists.openstack.org/pipermail/openstack-discuss/2023-April/033342.h… [4]. https://review.opendev.org/c/openstack/governance/+/877132 Issues with docs since 2023.1 release ------------------------------------- 2023.1 is the first release that uses numeric versioning, rather than the old naming scheme. This confuses our docs build process, which produces incorrect results. For one example the Administrator Guides list for Zed lists all the projects correctly[0], but the one for 2023.1 is empty[1]. Please use the Etherpad [2] to report issues, and the same Etherpad for tracking work. We're looking for help in getting this resolved quickly. [0]. https://docs.openstack.org/zed/admin/index.html [1]. https://docs.openstack.org/2023.1.antelope/admin/index.html [2]. https://etherpad.opendev.org/p/docs-issues-2023 Weekly Gate Health Report ------------------------- The gate continues to experience failures regarding volume detach tests[0]. There's also some issues with Ironic grenade jobs. Helping out with CI is an amazing way to get involved in the community, reach out to the TC (see below how) to know more! [0]. https://meetings.opendev.org/meetings/tc/2023/tc.2023-04-18-18.00.log.html#… Changes ======= Merged Appoint Tim Burke as Swift PTL (formal-vote) | https://review.opendev.org/c/openstack/governance/+/878286 TripleO: switch to distributed project leadership (formal-vote) | https://review.opendev.org/c/openstack/governance/+/878799 Appoint Andriy Kurilin as Rally PTL (formal-vote) | https://review.opendev.org/c/openstack/governance/+/878065 Add missing governance-sigs repo in technical-committee-repos.yaml (project-update) | https://review.opendev.org/c/openstack/governance/+/880237 Consider release version as string in projects data (code-change) | https://review.opendev.org/c/openstack/governance/+/877143 New Open Update to hacking v6 (code-change) | https://review.opendev.org/c/openstack/governance/+/881266 Switch to 2023.2 testing runtime py version (code-change) | https://review.opendev.org/c/openstack/governance/+/881137 Abandoned Switch project and OpenStack versions in releases (formal-vote) | https://review.opendev.org/c/openstack/governance/+/875942 All Open https://review.opendev.org/q/project:openstack/governance+status:open How to contact the TC ===================== If you would like to discuss or give feedback to TC, you can reach out to us in multiple ways: 1. Email: you can send an email with the tag [tc] on the openstack-discuss mailing list. 2. Weekly meeting: The Technical Committee conduct a weekly meeting every Thursday 16:00 UTC 3. IRC: Ping us using the 'tc-members' keyword on the #openstack-tc IRC channel on OFTC.

1 0

[nova]qemu-guest-agent Used in openstack
by 啧啧啧 20 Apr '23

20 Apr '23

Hi, We discovered the use of qemu-guest-agent in openstack,Set hw_qemu_guest_agent=yes to the metadata parameter on the image. https://docs.openstack.org/mitaka/config-reference/compute/hypervisor-kvm.h… Meanwhile, the application of qemu-guest-agent in cloud scenarios is investigated. It is found that Qemu-guest-Agent can be used for guest os performance monitoring, snapshot backup, and guest OS-level failover. But these things can be done in openstack with prometheus and  instance backup,There may be some differences between them. Sorry, I am not familiar with how hw_qemu_guest_agent is used in openstack, and I do not know the operations that can be performed on guest os in openstack by configuring hw_qemu_guest_agent. Only through qemu official know some of the effects.I want to clarify the use of hw_qemu_guest_agent. Other components of openstack, such as the prometheus service, can be used instead.

2 2

[qa][all] New hacking 6.0.0 is available
by Ghanshyam Mann 20 Apr '23

20 Apr '23

Hello Everyone, Hacking 6.0.0 is available to use now which includes flake8 5.0 changes. There are no other changes than bumping flake8 version to 5.0.1, you can refer to the changes done in flake8 5.0.0 (or 5.0.1) directly in flake8 release notes - https://flake8.pycqa.org/en/latest/release-notes/5.0.0.html Note: hacking is pinned in test-requirements.txt (for almost all the repo), do not forget to bump the version there while moving your code to new hacking. -gmann

1 0

[Glance] Bobcat PTG summary
by Abhishek Kekane 20 Apr '23

20 Apr '23

Hi Team, We had our seventh virtual PTG between 27th March to 31st March 2023. Thanks to everyone who joined the virtual PTG sessions. Using bluejeans app we had lots of discussion around different topics for glance, glance + cinder, fips and Secure RBAC. You can find the topics discussed in etherpad [1] with Notes from the session and which also includes the recordings of each discussion. Here I am going to highlight a few important topics which we are going to target this cycle. # Glance Image Direct URL access - OSSN-0090 This is the most important and high priority work item for us in this cycle. We are going to move the spec to the current cycle and implement glance, client and osc side work this cycle. We are also going to implement tempest side work for the same. Once it is completed, Rajat (current cinder PTL) is going to write consumer side spec for nova and cinder. https://bluejeans.com/s/dKF1IG2h8PC chapter 2 (from 22 minutes onward) # Bridge gap between Glance client and OSC Last cycle we have prepared the list of missing commands [2] and started submitting patches to implement the same. Our biggest hurdle at the moment is lack of reviews from the osc team (which has only one/two cores). Glance PTL is going to communicate with TC/existing core(s) of OSC whether they can add any glance core to the team so that we can prioritize our work and get reviews immediately. This cycle we are planning to complete this work. Recording: https://bluejeans.com/s/XZoRGceEhW3/ - Chapter 4 # Default glance to configure multistore Efforts has been started from last cycle but this work needs to be divided in small parts such as removing unnecessary tests, migrating existing tests to support multistore and so on. This cycle we are going to ensure that existing tests are supporting multistore configs. Recording: https://bluejeans.com/s/XZoRGceEhW3/ - Chapter 3 # Secure RBAC So far we are good with the goals decided by the community. This cycle PTL is going to discuss with the QE/TC team regarding deprecation of policies (migrating policies to use manager role) and decide further action. Recording: https://bluejeans.com/s/RHgqQi28_Hk/ - chapter 1 # Fips Overview ade_lee is going to submit some patches for us and we are going to help him in debugging failures if there are any. Recording: https://bluejeans.com/s/RHgqQi28_Hk/ - chapter 5 # Native Image encryption Finally the Barbican work is complete and we can move ahead with glance side work in this cycle. We need to move glance side spec to Bobcat and check whether there will be any changes in the implementation. Luzi is going to work on glance changes and the team is going to assist her in reviews and testing. Recording: https://bluejeans.com/s/RHgqQi28_Hk/ - chapter 3 # RBD deferred deletion Eric from cinder team is working on PoC/code for glance-store side changes for the same. Once we have PoC ready, the glance team will assist him to create a detailed spec and start working on tests for the same. https://bluejeans.com/s/dKF1IG2h8PC - chapter 2 Apart from above topics you can find other miscellaneous topics discussed in PTG etherpad [1] along with milestone wise priorities at the end. If you have any questions/suggestions then please join us in our weekly meeting (each Thursday #openstack-meeting irc channel at 1400 UTC). [1] https://etherpad.opendev.org/p/glance-bobcat-ptg [2] https://docs.google.com/spreadsheets/d/1tlipscCDeWmYGz3Hfp74czPW7BBJb4ST84q… Thanks and Regards, Abhishek Kekane

5 10

[cinder] festival of feature reviews 21 April 2023
by Rajat Dhasmana 20 Apr '23

20 Apr '23

Hello Argonauts, We will be having our monthly festival of reviews tomorrow i.e. 21st April (Friday) from 1400-1600 UTC. Our priorities for M-1 are DB changes for compatibility with sqlalchemy 2.0 and cinder-specs. Following are some additional details: Date: 21st April, 2023 Time: 1400-1600 UTC Meeting link: will be shared before meeting etherpad: https://etherpad.opendev.org/p/cinder-festival-of-reviews See you there! Thanks Rajat Dhasmana

1 0

[blazar] Meeting cancelled today
by Pierre Riteau 20 Apr '23

20 Apr '23

Hello, I won't be able to run the Blazar IRC meeting today. Let's skip this one. Thanks, Pierre Riteau (priteau)

1 0

[neutron] Neutron drivers meeting
by Rodolfo Alonso Hernandez 20 Apr '23

20 Apr '23

Hello Neutrinos: Please remember tomorrow we have the drivers meeting at 14UTC. The agenda is here [1]. We have, so far, a couple of topics to discuss. See you tomorrow. [1]https://wiki.openstack.org/wiki/Meetings/NeutronDrivers

1 0

[nova]qemu-guest-agent Used in openstack
by 任亮 20 Apr '23

20 Apr '23

Hi, We discovered the use of qemu-guest-agent in openstack,Set hw_qemu_guest_agent=yes to the metadata parameter on the image. https://docs.openstack.org/mitaka/config-reference/compute/hypervisor-kvm.h… Meanwhile, the application of qemu-guest-agent in cloud scenarios is investigated. It is found that Qemu-guest-Agent can be used for guest os performance monitoring, snapshot backup, and guest OS-level failover. But these things can be done in openstack with prometheus and cinder-backup,There may be some differences between them, Sorry, I am not familiar with how hw_qemu_guest_agent is used in openstack, and I do not know the operations that can be performed on guest os in openstack by configuring hw_qemu_guest_agent. Only through qemu official know some of the effects.I want to clarify the use of hw_qemu_guest_agent. Other components of openstack, such as the prometheus service, can be used instead.

1 0

[security-sig] Ask base recommendation for handling vulnerability which affects both OpenStack code and vendor code
by Vanou Ishii (Fujitsu) 19 Apr '23

19 Apr '23

Hi OpenStack community, I’m working on OpenStack project under my employee company. In OpenStack, few of projects (e.g. Cinder and Ironic) uses vendor supplied library in it. This means vendor-neutral base code of project is hosted under OpenStack project repository but vendor hardware specific logic is delegated to vendor library which is called by base code and is maintained by each hardware vendor under their repository. In the past, I faced situation to handle vulnerability in which cause of vulnerability is in vendor library but, to handle vulnerability, both OpenStack code and vendor library code should be modified. To handle this, I consulted community member and asked them to coordinate to fix vulnerability in private way (i.e. review patch and prepare commit in not public but private as usual security handling manner). However member are not willing to working on together because cause of vulnerability is in vendor provided library. I felt it’s better for community to, at least, be open to working on such vulnerability because that policy may benefit community. So I think it’s better to include policy in VMT document[1] like “Community is encouraged to make effort to be open to handling vulnerability in which both OpenStack community code and vendor provided code should be modified”. How do you think about this? Regards, Vanou Ishii [1] https://security.openstack.org/vmt-process.html

3 4

[neutron] questions about bond and port ip
by 韩光宇 19 Apr '23

19 Apr '23

Hello, I have a victoria cluster. I am a bit perplexed about OpenStack networking and was wondering if you could enlighten me on the topic. 1. bond When configuring bond interfaces (bond0/1/2/3) in an OpenStack instance, can I follow the same steps as I would on a physical machine? Are there any particular considerations to keep in mind? Also, when it comes to switch configuration, do I configure virtual machine switches directly or are there specific OpenStack interfaces to use? 2. `openstack port create --network net1 --no-fixed-ip port_net1` I was able to obtain a port with an ip_allocation value of "none" using the above command. I noticed that the ip_allocation value can be set to "none", "deferred", or "immediate". Is there a CLI interface to modify the ip_allocation value of a port, for example, changing "none" to "deferred"? Alternatively, what is the recommended method to make this change? 3. Is it possible for users to set IP addresses within an instance system? For example, if I create an instance without an IP address, is there a mechanism that allows me to set an IP address within the instance system, or can I only modify the port bindings or switch ports externally to change the IP address of an instance? Thank you for your attention to this matter. Best regards, Han Guangyu

3 2

Re: openstack-discuss Digest, Vol 54, Issue 85
by Kristin Barrientos 19 Apr '23

19 Apr '23

Hi everyone, There seems to have been an error regarding the time for the next Large Scale SIG meeting. It was supposed to be 14 UTC, not 15 UTC. Is there anyone that is able to join the meeting now? So sorry about that. Please join now if you can! Thanks, Kristin Barrientos Marketing Coordinator OpenInfra Foundation > On Apr 17, 2023, at 7:00 AM, openstack-discuss-request(a)lists.openstack.org wrote: > > Send openstack-discuss mailing list submissions to > openstack-discuss(a)lists.openstack.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss > > or, via email, send a message with subject or body 'help' to > openstack-discuss-request(a)lists.openstack.org > > You can reach the person managing the list at > openstack-discuss-owner(a)lists.openstack.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of openstack-discuss digest..." > > > Today's Topics: > > 1. [largescale-sig] Next meeting: April 19, 15utc (Thierry Carrez) > 2. Re: [largescale-sig] Next meeting: April 19, 15utc > (Thierry Carrez) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 17 Apr 2023 13:14:19 +0200 > From: Thierry Carrez <thierry(a)openstack.org> > To: "openstack-discuss(a)lists.openstack.org" > <openstack-discuss(a)lists.openstack.org> > Subject: [largescale-sig] Next meeting: April 19, 15utc > Message-ID: <25b05623-92e2-f01e-70c3-5aac26a4f256(a)openstack.org> > Content-Type: text/plain; charset=UTF-8; format=flowed > > Hi everyone, > > The Large Scale SIG will be meeting this Wednesday in > #openstack-operators on OFTC IRC, at 15UTC, our EU+US-friendly time. > > You can doublecheck how that UTC time translates locally at: > https://www.timeanddate.com/worldclock/fixedtime.html?iso=20230322T14 > > Feel free to add topics to the agenda: > https://etherpad.opendev.org/p/large-scale-sig-meeting > > Regards, > > -- > Thierry Carrez > > > > ------------------------------ > > Message: 2 > Date: Mon, 17 Apr 2023 13:15:26 +0200 > From: Thierry Carrez <thierry(a)openstack.org> > To: "openstack-discuss(a)lists.openstack.org" > <openstack-discuss(a)lists.openstack.org> > Subject: Re: [largescale-sig] Next meeting: April 19, 15utc > Message-ID: <90db3bfb-b6b4-c0ef-6b9f-8593c7dcc324(a)openstack.org> > Content-Type: text/plain; charset=UTF-8; format=flowed > > Thierry Carrez wrote: >> You can doublecheck how that UTC time translates locally at: >> https://www.timeanddate.com/worldclock/fixedtime.html?iso=20230322T14 > > Wrong URL, try out this one instead: > https://www.timeanddate.com/worldclock/fixedtime.html?iso=20230419T15 > > Sorry about that. > > -- > Thierry] > > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > openstack-discuss mailing list > openstack-discuss(a)lists.openstack.org > > > ------------------------------ > > End of openstack-discuss Digest, Vol 54, Issue 85 > *************************************************

1 0

[kolla-ansible] bootstrap-server docker version question
by Satish Patel 19 Apr '23

19 Apr '23

Folks, Playing with kolla and i decided to use docker.io installation (ubuntu 20.04) on controller nodes but when i run bootstrap-server it removed docker.io and installed docker-ce version. Question: What is the best docker version to run in production for operator point of view and better support and stability. docker.io maintained by debian community and native support with Ubuntu distro. docker-ce is maintained by the docker community which has better features etc but rapid growth but does that matter for kolla? Just curious, what if I add compute nodes in an existing cluster after many months? In that case the docker-ce version will be changed. How to maintain or pin docker-ce version? ~S

5 10

[cinder] Bug Report | Bugs from 2023-04-12 to 2023-04-19
by Sofia Enriquez 19 Apr '23

19 Apr '23

Hello Argonauts, I've recently updated a personal script <https://github.com/enriquetaso/launchpad-bug-reporter> I've been using to fetch bugs from Launchpad. I wanted to share it with you all in case anyone has ideas on how to make it better or wants to contribute to the project. Your suggestions and input would be super valuable! *Medium* - Dell Compellent:- DSM is unable to fetch WWNs from mapping personality objects which are stored with lowercase letters in SC. <https://bugs.launchpad.net/cinder/+bug/2016840> - *Status*: The bug report says *In Progress *but I couldn't find any patch on Gerrit. - NVMe-oF connector doesn't create the hostid <https://bugs.launchpad.net/os-brick/+bug/2016029> - Status: Fix proposed to branch: master <https://review.opendev.org/c/openstack/os-brick/+/880222>. - [rbac] list, show and show_default volume type command response does not contain "os-volume-type-access:is_public" property when using reader user <https://bugs.launchpad.net/cinder/+bug/2016402> - *Status*: The reporter updated the bug report with references to the Tempest test. *Incomplete* - Cleanup of backups fails for non-existing volume <https://bugs.launchpad.net/cinder/+bug/2016138>. - *Status*: Waiting on reporter update. Cheers, -- Sofía Enriquez she/her Software Engineer Red Hat PnT <https://www.redhat.com> IRC: @enriquetaso @RedHat <https://twitter.com/redhat> Red Hat <https://www.linkedin.com/company/red-hat> Red Hat <https://www.facebook.com/RedHatInc> <https://www.redhat.com>

1 0

Survey Invitation on Code Snippets in Code Reviews
by Beiqi Zhang 18 Apr '23

18 Apr '23

Dear OpenStack Contributors, In the code review process, reviewers and developers engage in asynchronous online discussions to exchange information with each other, aiming at promoting the acceptence of proposed code changes. During the discussions, code snippets might be served as a way to meet the information needs of reviewers or developers (e.g., reviewers may make a suggestion by providing code snippet). However, little is known about the practices of providing code snippets in code reviews (e.g., what is the intention behind providing code snippet). To this end, we plan to conduct this survey to gain knowledge and experience from the perspective of developers in industry. We would greatly appreciate your help with our research by filling out the questionnaire below: Our questionnaire contains 4 close-ended questions and 2 open-ended questions, which may take about 3-5 minutes. The link of the questionnaire (hosted at Google Forms): https://forms.gle/nrLaZXQUq4QMS3bu6 Thank you very much for your participation! Best regards, Beiqi Zhang (on Behalf of the Team) Wuhan University, China

1 0

RDO Antelope Released
by Amy Marrich 18 Apr '23

18 Apr '23

The RDO community is pleased to announce the general availability of the RDO build for OpenStack 2023.1 Antelope for RPM-based distributions, CentOS Stream and Red Hat Enterprise Linux. RDO is suitable for building private, public, and hybrid clouds. Antelope is the 27th release from the OpenStack project, which is the work of more than 1,000 contributors from around the world. The release is already available for CentOS Stream 9 on the CentOS mirror network in: http://mirror.stream.centos.org/SIGs/9-stream/cloud/x86_64/openstack-antelo… The RDO community project curates, packages, builds, tests and maintains a complete OpenStack component set for RHEL and CentOS Stream and is a member of the CentOS Cloud Infrastructure SIG. The Cloud Infrastructure SIG focuses on delivering a great user experience for CentOS users looking to build and maintain their own on-premise, public or hybrid clouds. All work on RDO and on the downstream release, Red Hat OpenStack Platform, is 100% open source, with all code changes going upstream first. The highlights of the broader upstream OpenStack project may be read via https://releases.openstack.org/antelope/highlights.html but here are some highlights: - The continuation of SRBAC and FIPS to make OpenStack a more secure platform across various services, along with additional support in images. - Additional drivers and features for Block Storage to support more technologies from vendors such as Dell, Hitachi and NetApp, among others. - DNS Zones that can now be shared with other tenants (projects) allowing them to create and manage recordsets within the Zone. - Networking port forwarding was added to the dashboard for Floating IPs. - Additional networking features to support OVN. - Compute now allows PCI devices to be scheduled via the Placement API and power consumption can be managed for dedicated CPUs. - Load balancing now allows users to enable cpu-pinning. - Community testing of compatibility between non-adjacent upstream versions. OpenStack Antelope is the first release marked as Skip Level Upgrade Release Process or SLURP. According to this model ( https://governance.openstack.org/tc/resolutions/20220210-release-cadence-ad…) this means that upgrades will be supported between these (SLURP) releases, in addition to between adjacent major releases. *TripleO removal in the RDO Antelope release:* During the Antelope cycle, The TripleO team communicated the decision of abandoning the development of the project and deprecating the master branches. According to that upstream decision, TripleO packages have been removed from the RDO distribution and will not be included in the Antelope release. *Contributors* During the Zed cycle, we saw the following new RDO contributors: - Adrian Fusco Arnejo - Bhagyashri Shewale - Eduardo Olivares - Elvira Garcia Ruiz - Enrique Vallespí - Jason Paroly - Juan Badia Payno - Karthik Sundaravel - Roberto Alfieri - Tom Weininger Welcome to all of you and Thank You So Much for participating! But we wouldn’t want to overlook anyone. A super massive Thank You to all *52* contributors who participated in producing this release. This list includes commits to rdo-packages, rdo-infra, and rdo-website repositories: - Adrian Fusco Arnejo - Alan Pevec - Alfredo Moralejo Alonso - Amol Kahat - Amy Marrich - Ananya Banerjee - Artom Lifshitz - Arx Cruz - Bhagyashri Shewale - Cédric Jeanneret - Chandan Kumar - Daniel Pawlik - Dariusz Smigiel - Dmitry Tantsur - Douglas Viroel - Eduardo Olivares - Elvira Garcia Ruiz - Emma Foley - Eric Harney - Enrique Vallespí - Fabien Boucher - Harald Jensas - Jakob Meng - Jason Paroly - Jesse Pretorius - Jiří Podivín - Joel Capitao - Juan Badia Payno - Julia Kreger - Karolina Kula - Karthik Sundaravel - Leif Madsen - Luigi Toscano - Luis Tomas Bolivar - Marios Andreou - Martin Kopec - Matthias Runge - Matthieu Huin - Nicolas Hicher - Pooja Jadhav - Rabi Mishra - Riccardo Pittau - Roberto Alfieri - Ronelle Landy - Sandeep Yadav - Sean Mooney - Slawomir Kaplonski - Steve Baker - Takashi Kajinami - Tobias Urdin - Tom Weininger - Yatin Karel *The Next Release Cycle* At the end of one release, focus shifts immediately to the next release i.e Bobcat. *Get Started* To spin up a proof of concept cloud, quickly, and on limited hardware, try an All-In-One Packstack installation. You can run RDO on a single node to get a feel for how it works. Finally, for those that don’t have any hardware or physical resources, there’s the OpenStack Global Passport Program. This is a collaborative effort between OpenStack public cloud providers to let you experience the freedom, performance and interoperability of open source infrastructure. You can quickly and easily gain access to OpenStack infrastructure via trial programs from participating OpenStack public cloud providers around the world. *Get Help* The RDO Project has our users(a)lists.rdoproject.org for RDO-specific users and operators. For more developer-oriented content we recommend joining the dev(a)lists.rdoproject.org mailing list. Remember to post a brief introduction about yourself and your RDO story. The mailing lists archives are all available at https://mail.rdoproject.org. You can also find extensive documentation on RDOproject.org. The #rdo channel on OFTC IRC is also an excellent place to find and give help. We also welcome comments and requests on the CentOS devel mailing list and the CentOS IRC channels (#centos, #centos-cloud, and #centos-devel in Libera.Chat network), however we have a more focused audience within the RDO venues. *Get Involved* To get involved in the OpenStack RPM packaging effort, check out the RDO contribute pages, peruse the CentOS Cloud SIG page, and inhale the RDO packaging documentation. Join us in #rdo on the OFTC IRC network and follow us on Twitter @RDOCommunity. You can also find us on Facebook and YouTube.

1 0

[Horizon]: allow user to access calendar on horizon
by James Leong 18 Apr '23

18 Apr '23

Hi all, I am using kolla-ansible for OpenStack deployment in the yoga version. Is it possible to allow the user (member role) to view the calendar graph under the reservation tab (lease)? Currently, only the admin will be able to view the calendar graph with all the reserved leases. However, a user with other roles cannot load the calendar information. On the dashboard, I saw it displayed " Unable to load reservations." When I look into the log file, I get the below error message. "blazarclient.exception.BlazarClientException: ERROR: Policy doesn't allow blazar:oshosts:get to be performed." Is there a way to allow the policy? Thanks for your help. James

2 2

[kolla][kolla-ansible] Kolla-Ansible mirror update and kolla images
by Nguyễn Hữu Khôi 18 Apr '23

18 Apr '23

Hello. I have a question. I use kolla-ansible 13.0.0 and kolla 13.0.0 images then I upgrade kolla-ansible to 13.8.0. I will use kolla 13.8.0 to build new images? Thank you. Regards Nguyen Huu Khoi

3 4

[neutron] Bug deputy April 10-16th
by Rodolfo Alonso Hernandez 18 Apr '23

18 Apr '23

Hello Neutrinos: This is the bug list from the last week: High: * https://bugs.launchpad.net/neutron/+bug/2015847: Functional job db missconfiguration. Assigned to Rodolfo. * https://bugs.launchpad.net/neutron/+bug/2016142: [sqlalchemy-20] Error in "get_ports_on_host_by_subnet" execution. Fixed. * https://bugs.launchpad.net/neutron/+bug/2016266: [Secure RBAC] Get availability zone API should be available for READER role. Assigned to Slawek. Patch proposed: https://review.opendev.org/c/openstack/neutron/+/880461 Medium: * https://bugs.launchpad.net/neutron/+bug/2016198: [L3][HA] race condition between first two router creations when tenant has no HA network. Related to https://bugs.launchpad.net/neutron/+bug/2016197. Not assigned. Low: * https://bugs.launchpad.net/neutron/+bug/2015844: Remove netifaces dependency from neutron. To be discussed during the Neutron meeting. * https://bugs.launchpad.net/neutron/+bug/1988039: ovs idl not monitor tables after reconnect. Patch proposed: https://review.opendev.org/c/openstack/neutron/+/857010 * https://bugs.launchpad.net/neutron/+bug/2016413: api-ref: missing documentation for subnet-onboard. Not assigned. Whislist: * https://bugs.launchpad.net/neutron/+bug/2016158: [OVN] How to deal with SB "Chassis"/"Chassis_Private" duplicated registers. Assigned to Rodolfo. * https://bugs.launchpad.net/neutron/+bug/2016197: [Open Discussion] neutron can create port from network which has no subnet. Not assigned (maybe it won’t be necessary). Regards.

1 0

[zun][zun_api][blazar][config][yoga][kolla-ansible] Adding more configuration to config file
by James Leong 18 Apr '23

18 Apr '23

Hi all, I am playing around with Zun. I have used kolla-ansible as a deployment tool for deploying the yoga version of OpenStack. I am trying to add an option to the configuration file. However, those added options are not recognized by OpenStack when being called. For instance, Zun.conf, I am adding a new database (blazar) information to it so I can access blazar information in the zun service. Would that be possible to allow the zun_api container to access the blazar database? Thanks for your help, James

3 2

Re: [all][stable][ptl] Propose to EOL Rocky series
by Elõd Illés 17 Apr '23

17 Apr '23

Hi, thanks for all the feedbacks from teams so far! @Zigo: Extended Maintenance process was created just for the same situation: to give space to interested parties to cooperate and keep things maintained even when stable releases are over their 'supported' lifetime. So it's good to see that there is interest in it! Unfortunately, with very old branches we've reached the state where gates can't be maintained and without a functional gate it's not safe to merge patches (yes, even security fixes) and they are just using resources (CI & maintainers' time). When gate is broken in such extent, then i think the community have to accept that it is not possible to merge patches confidently and needs to EOL that release. (Yes, it means that some vendors still have to do it for their own sake, testing it by their own, etc). Keeping things open in such state gives the false signal to vendors that 'it is maintained' however this is done without fully testing the changes. Another aspect is that code cannot be cleaned up until those old branches are still present (CI jobs, project configurations, etc) which gives pain for developers. So, however some vendors would appreciate probably to keep things open forever, for the community this is not beneficial and doable I think. Seeing that teams want to EOL their old branches is a proof that this is needed (unfortunately). Thanks, Előd Illés irc: elodilles @ #openstack-stable / #openstack-release ________________________________ From: Thomas Goirand <thomas(a)goirand.fr> Sent: Saturday, January 28, 2023 2:25 PM Cc: openstack-discuss(a)lists.openstack.org <openstack-discuss(a)lists.openstack.org> Subject: Re: [all][stable][ptl] Propose to EOL Rocky series Hi, I understand the gate is broken, however, Rocky is in Debian LTS, and I would like to keep the possibility to merge patches, even with the gate tests disabled. CVE-2022-47951 is an example why this is important... Thomas Goirand (zigo) On Jan 28, 2023 11:54, Radosław Piliszek <radoslaw.piliszek(a)gmail.com> wrote: > > Masakari is happy to EOL Rocky too. > > Radek > -yoctozepto > > On Fri, 27 Jan 2023 at 20:59, Jay Faulkner <jay(a)gr-oss.io> wrote: > > > > Thanks for doing all this cleanup work Elod. Ironic is OK with retirements of these shared resources up to Train. > > > > - > > Jay Faulkner > > > > On Fri, Jan 27, 2023 at 10:12 AM Elõd Illés <elod.illes(a)est.tech> wrote: > >> > >> Hi, > >> > >> Similarly like the Queens branch EOL proposal [1] I would like to propose > >> to transition every project's stable/rocky to End of Life: > >> > >> - gates are mostly broken > >> - minimal number of activity can be seen on this branch > >> - some core projects already transitioned their stable/rocky to EOL > >> recently (like ironic, neutron, nova) > >> - gate job definitions are still using the old, legacy zuul syntax > >> - gate jobs are based on Ubuntu Xenial, which is also beyond its public > >> maintenance window date and hard to maintain > >> > >> Based on the above, if there won't be any project who wants to keep open > >> their stable/rocky, then I'll start the process of EOL'ing Rocky stable > >> series as a whole. If anyone has any objection then please respond to > >> this mail. > >> > >> Thanks, > >> > >> Előd Illés > >> irc: elodilles @ #openstack-stable / #openstack-release > >> > >> [1] https://lists.openstack.org/pipermail/openstack-discuss/2022-October/031030… > >> >

3 4

[Neutron] Future of TripleO OVN migration in-tree code
by Jakub Libosvar 17 Apr '23

17 Apr '23

Hello Neutrinos and others, as this has been brought up several times through some conversation channels with no consensus, I wanted to start a discussion and possibly find a consensus about the code for migrating an OpenStack from OVS mechanism driver to OVN [1]. The code leverages TripleO to install and to configure OVN services, however the TripleO project is no longer maintained after Zed release [2]. This brings up the question what to do with the migration tooling that relies on TripleO. Shall we remove the code completely or is there anybody who would be interested in maintaining that code and implement support for other installers? Thanks Kuba [1] https://opendev.org/openstack/neutron/src/branch/master/tools/ovn_migration… [2] https://review.opendev.org/c/openstack/governance/+/878799

2 2

[kolla] Reducing ceilometer, gnocchi, aodh time interval
by Modyngs 17 Apr '23

17 Apr '23

Dear lists, Hi I have recently noticed of this link to customize configurations to be overridden [Thanks to michal nasiadka]: https://docs.openstack.org/kolla-ansible/latest/admin/advanced-configuratio… but i have some doubts in regards! The docs says /etc/kolla/ config/<< service name >>/<< config file >> (Ex. /etc/kolla/config/nova/nova-scheduler.conf) let's say i want to change interval to 30sec (* 'interval: 30'*) in *'/etc/kolla/ceilometer-central/polling.yaml'* file: as i understood, i need to create a file in *'/etc/kolla/config/ceilometer-central/polling.yaml'* and copy all the contents of * '/etc/kolla/ceilometer-central/polling.yaml'* into it ( *or just the change?*) and then change just the *interval from 300 to 30 .* Am I doing Right? ( because there was no [DEFAULT] section available in the polling.yaml file ....) After doing the same for all the desired files, then i need to do prechecks and deploy? kolla-ansible -i /etc/kolla/all-in-one prechecks kolla-ansible -i /etc/kolla/all-in-one deploy Thanks

1 0

[largescale-sig] Next meeting: April 19, 15utc
by Thierry Carrez 17 Apr '23

17 Apr '23

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

1 1

[tc] Technical Committee next weekly meeting on 2023 April 18 at 1800 UTC
by Nikolla, Kristi 16 Apr '23

16 Apr '23

Hi all, This is a reminder that the next weekly Technical Committee meeting is to be held on Tuesday (April 18) at 1800 UTC on #openstack-tc on OFTC IRC Items can be proposed by editing the wiki page at https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting Unless there are last minute additions (for which I will send a follow-up email) the agenda will be: • Roll call • Follow up on past action items • gmann respond to Sahara PTL volunteer to propose a patch to governance, and explain the outcome of today's discussion • jamespage to write email about Winstackers removal • Gate health check • 2023.2 cycle Leaderless projects • https://etherpad.opendev.org/p/2023.2-leaderless • Broken docs due to inconsistent release naming • Recurring tasks check • Bare 'recheck' state • https://etherpad.opendev.org/p/recheck-weekly-summary • Open Reviews • https://review.opendev.org/q/projects:openstack/governance+is:open Thank you, Kristi Nikolla

1 0

Installation
by BEDDA Fadhel 14 Apr '23

14 Apr '23

Bonjour, Ou je peux trouver pour tester openstack sur Ubuntu 22.04 Cordialement

3 2

[tc][all] What's happening in the Technical Committee - 2023 April 14
by Nikolla, Kristi 14 Apr '23

14 Apr '23

Hi all, Here’s another edition of “What’s happening on the Technical Committee.” Meeting ======= The Technical Committee met on April 11 on the #openstack-tc channel on OFTC IRC. The next weekly meeting will happen on April 18th. For more information visit https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting Happenings ========== Final call for Winstackers (and Windows Support) ------------------------------------------------ Cloudbase Solutions are no longer in a position to maintain support for running OpenStack on Windows and have also ceased operation of their 3rd party CI for the windows support across a number of OpenStack projects. This is the final call for any maintainers to step forward for maintaining Winstackers if this feature is important to them in OpenStack[0][1]. If there is no response by June 2023, we will discuss the retirement of this project. [0]. https://lists.openstack.org/pipermail/openstack-discuss/2023-April/033342.h… [1]. https://lists.openstack.org/pipermail/openstack-discuss/2023-April/033273.h… Final call for Vitrage maintainers ---------------------------------- This is the final call for maintainers. If anyone is using or interested in this project, this is the right time to step up. If there is no response by the end of April 2023, we will discuss the retirement of this project.[0] [0]. https://lists.openstack.org/pipermail/openstack-discuss/2023-April/033348.h… Patrole retirement ------------------ As notified on the mailing list yesterday[0] and by a patch proposed to the governance repo[1], the Patrole project is being retired. The project is inactive, and there was no interest from prospective maintainers. [0]. https://lists.openstack.org/pipermail/openstack-discuss/2023-April/033346.h… [1]. https://review.opendev.org/c/openstack/governance/+/880014 Gate status ----------- Every week we have a look at the overall status of the "gate". In the last meeting the status was reported and not super healthy[0]. * The U-C bump broke Glance's functional test and there is a desire to put Glance's functional tests behind the U-C gate so that future breakages are caught before they happen. * It was also reported that we were seeing some guest kernel crashes on volume tests. These may be related to nested virtualization. [0]. https://meetings.opendev.org/meetings/tc/2023/tc.2023-04-11-17.59.log.html#… Changes ======= * Merged * Add ovn-bgp-agent to Neutron governed projects (project-update) | https://review.opendev.org/c/openstack/governance/+/879455 * Add xstatic-angular-fileupload as Horizon team deliverables (project-update) | https://review.opendev.org/c/openstack/governance/+/873845 * Retire puppet-tacker - Step 3: Retire Repository (project-update) | https://review.opendev.org/c/openstack/governance/+/875295 * New Open * Appoint Jerry Zhou as Sahara PTL (formal-vote) | https://review.opendev.org/c/openstack/governance/+/879847 * Retire patrole (project-update) | https://review.opendev.org/c/openstack/governance/+/880014 * Correct the old deprecated policies removal timeline for SLURP release (formal-vote) | https://review.opendev.org/c/openstack/governance/+/880238 * Add missing governance-sigs repo in technical-committee-repos.yaml (project-update) | https://review.opendev.org/c/openstack/governance/+/880237 * Retire puppet-rally - Step 3: Retire Repository (project-update) | https://review.opendev.org/c/openstack/governance/+/880018 * All Open * https://review.opendev.org/q/project:openstack/governance+status:open How to contact the TC ===================== If you would like to discuss or give feedback to TC, you can reach out to us in multiple ways: 1. Email: you can send an email with the tag [tc] on the openstack-discuss mailing list. 2. Weekly meeting: The Technical Committee conduct a weekly meeting every Thursday 16:00 UTC 3. IRC: Ping us using the 'tc-members' keyword on the #openstack-tc IRC channel on OFTC.

1 0

[glance][cinder]create volume from image too slow
by Nguyễn Hữu Khôi 14 Apr '23

14 Apr '23

Hello guys. I am using nfs for glance and SAN for cinder but when i create 1 gb volume with 100mb image(Converted 112.00 MB image at 25.4 MB/s) then it will fast. however, if I create 100gb volume with 100mb image(Converted 112.00 MB image at 8.24 MB/s) then it will very slow. Pls give me some advices. ty Nguyen Huu Khoi

1 1

[neutron] Drivers meeting agenda
by Rodolfo Alonso Hernandez 14 Apr '23

14 Apr '23

Hello Neutrinos: Remember we have the Neutron drivers meeting today at 14UTC. The agenda is here: https://wiki.openstack.org/wiki/Meetings/NeutronDrivers Regards.

1 0

[Controller/Infra node removal] [openstack-ansible] Need to remove infra/controller node from environment.
by Danish Khan 14 Apr '23

14 Apr '23

Hello Team, Is it possible to remove an infra host from environment? If yes, can you please share the exact steps that need to be followed. I am trying to remove it manually by destroying all lxc containers from infra host which needs to be removed and then running setup openstack playbook. but it is not working properly. Can someone please share the exact steps needed to be followed to remove infra host from the environment. Openstack version: Wallaby or Yoga. Regards, Danish

2 1

[kolla-ansible][yoga] is there a way to deploy or reconfigure a container to run in privileged mode?
by wodel youchi 14 Apr '23

14 Apr '23

Hi, Is there a way to deploy or reconfigure a container to run in privileged mode? I need to make glance-api run in privileged mode. Regards.

2 1

[ptl] Need PTL volunteer for OpenStack Winstackers
by Ghanshyam Mann 13 Apr '23

13 Apr '23

Hi Lukas, I am reaching out to you as you were PTL for OpenStack Winstackers project in the last cycle. There is no PTL candidate for the next cycle (2023.2), and it is on the leaderless project list. Please check if you or anyone you know would like to lead this project. - https://etherpad.opendev.org/p/2023.2-leaderless Also, if anyone else would like to help leading this project, this is time to let TC knows. -gmann

7 14

[qa][patrole] Retiring Patrole project
by Ghanshyam Mann 13 Apr '23

13 Apr '23

Hello Everyone, You might know that Patrole project[1] which was created to test the RBAC but had some design challenges, and we never got much attention to this project to align it with the new SRBAC or efficient way to test the RBAC. Since the last couple of years (After AT&T's focus was changed from OpenStack), we hardly had any maintainer in this project. In this cycle, the QA team decided to retire this project. There is always an option to bring it back in OpenStack if anyone is interested in maintaining it. I have pushed the changes required for retirement, including governance change. If anyone using or interested in this project, feel free to reply here or in governance change[2]. [1] https://wiki.openstack.org/wiki/QA#Patrole_.28RETIRED.29 [2] https://review.opendev.org/c/openstack/governance/+/880014 -gmann

1 0

[heat] Performance scaling with number of resources
by John Bartelme 13 Apr '23

13 Apr '23

Hello, I'm wondering about heat performance when I scale to a larger number of resources. A single resource deploys quite quickly but when I deploy the below template it takes 2 minutes for this stack to deploy. This occurs on Antelope via DevStack on Ubuntu 22.04 as well as a full production cluster(yoga) deployed with OpenStack-Ansible on RHEL 8. Not only does this template take 2 minutes to deploy it also takes 2 minutes to update without any changes. Is there anything in the stack configuration or heat configuration I can do to speed up the process of updating the stack when very little changes? Or this something inherit in the design of heat? --- heat_template_version: 2021-04-16 description: test resources: test-resources: type: OS::Heat::ResourceGroup properties: count: 100 resource_def: type: OS::Heat::None --- A little more detail: Obviously I have no need to deploy this template but it is a much more simplified case of what I really want to deploy. I'm deploying resource groups that contain hundreds of custom resources(containing network/compute/storage etc.) that are conditionally enabled or disabled based on a JSON property array(in general only about 20 or so resources are deployed but depending on needs any one of the resources might be needed in the near future). The JSON properties array is complex enough that I really want to have it all defined so that changing a boolean value is all that is needed to turn on and off resources without having to fully write new complex heat templates. Additionally the nature of the workflow is that I want to add future resources to the existing stack. I don't change the number of the resources to the resource group, i.e. count=20 instead of 100 because when I conditionally add another resource it causes all the existing resources to be renumbered. Ideally I could rapidly modify one value to the json array and then update the stack and have it quickly modified. Thanks, john

1 0

[manila] Cancelling next week's weekly meeting
by Carlos Silva 13 Apr '23

13 Apr '23

Hello everyone! As we will have a significant drop in attendance in next week's IRC weekly meeting (Apr 20th), we will be cancelling it. The next IRC weekly meeting will be on Apr 27th. Thanks, carloss

1 0