March 2023 - openstack-discuss - lists.openstack.org

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 Ansible on Ubuntu 20.04 - cloud-init & other network issues
by Tobias McNulty 10 Oct '24

10 Oct '24

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

5 9

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

07 Aug '24

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

5 16

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

17 May '24

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

18 27

[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

[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 02 Jun '23

02 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

[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

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

10 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

[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

[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

[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

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

[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

[nova][cinder] future of rebuild without reimaging
by Bence Romsics 06 Apr '23

06 Apr '23

Hi All! We have users who use 'rebuild' on volume booted servers before nova microversion 2.93, relying on the behavior that it keeps the volume as is. And they would like to keep doing this even after the openstack distro moves to a(n at least) zed base (sometime in the future). As a naive user, it seems to me both behaviors make sense. I can easily imagine use cases for rebuild with and without reimaging. However since the implementation of https://specs.openstack.org/openstack/nova-specs/specs/zed/implemented/volu… rebuild without reimaging is only possible using an old microversion (<2.93). With that change merged, rebuild without reimaging seems to be a somewhat less than fully supported feature. A few examples of what I mean by that: First, there's this warning: https://opendev.org/openstack/python-openstackclient/src/commit/5eb89e4ca1c… In which it is unclear to me what exactly will become an error in a future release. Rebuild with a different image? Or any rebuild with microversion <2.93? Then old nova microversions may get dropped. Though what I heard from nova folks, this is unlikely to happen. Then there are a few hypothetical situations like: a) Rebuild gets a new api feature (in a new microversion) which can never be combined with the do-not-reimage behavior. b) Rebuild may have a bug, whose fix requires a microversion bump. This again can never be combined with the old behavior. What do you think, are these concerns purely theoretical or real? If we would like to keep having rebuild without reimaging, can we rely on the old microversion indefinitely? Alternatively shall we propose and implement a nova spec to explicitly expose the choice in the rebuild api (just to express the idea: osc server rebuild --reimage|--no-reimage)? If the topic is worth further discussion beyond the ML, I can also bring it to the nova ptg. Thanks in advance, Bence Romsics (rubasov) ps: I'll be afk for a few days, but I'll follow up next Tuesday.

7 16

[nova][cinder] Providing ephemeral storage to instances - Cinder or Nova
by Christian Rohmann 04 Apr '23

04 Apr '23

Hello OpenStack-discuss, I am currently looking into how one can provide fast ephemeral storage (backed by local NVME drives) to instances. There seem to be two approaches and I would love to double-check my thoughts and assumptions. 1) *Via Nova* instance storage and the configurable "ephemeral" volume for a flavor a) We currently use Ceph RBD als image_type (https://docs.openstack.org/nova/latest/configuration/config.html#libvirt.im…) so instance images are stored in Ceph, not locally on disk. I believe this setting will also cause ephemeral volumes (destination_local) to be placed on a RBD and not /var/lib/nova/instances? Or is there a setting to set a different backend for local block devices providing "ephemeral" storage? So RBD for the root disk and a local LVM VG for ephemeral? b) Will an ephemeral volume also be migrated when the instance is shutoff as with live-migration? Or will there be an new volume created on the target host? I am asking because I want to avoid syncing 500G or 1T when it's only "ephemeral" and the instance will not expect any data on it on the next boot. c) Is the size of the ephemeral storage for flavors a fixed size or just the upper bound for users? So if I limit this to 1T, will such a flavor always provision a block device with his size? I suppose using LVM this will be thin provisioned anyways? 2) *Via Cinder*, running cinder-volume on each compute node to provide a volume type "ephemeral", using e.g. the LVM driver a) While not really "ephemeral" and bound to the instance lifecycle, this would allow users to provision ephemeral volume just as they need them. I suppose I could use backend specific quotas (https://docs.openstack.org/cinder/latest/cli/cli-cinder-quotas.html#view-bl…) to limit the number of size of such volumes? b) Do I need to use the instance locality filter (https://docs.openstack.org/cinder/latest/contributor/api/cinder.scheduler.f…) then? c) Since a volume will always be bound to a certain host, I suppose this will cause side-effects to instance scheduling? With the volume remaining after an instance has been destroyed (beating the purpose of it being "ephemeral") I suppose any other instance attaching this volume will be scheduling on this very machine? Is there any way around this? Maybe a driver setting to have such volumes "self-destroy" if they are not attached anymore? d) Same question as with Nova: What happens when an instance is live-migrated? Maybe others also have this use case and you can share your solution(s)? Thanks and with regards Christian

3 4

Opensearch service upgrade
by Daniel Pawlik 04 Apr '23

04 Apr '23

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

1 1

[nova][heat] The next steps to "fix" libvirt problems in Ubuntu Jammy
by Takashi Kajinami 04 Apr '23

04 Apr '23

Hello, Since we migrated our jobs from Ubuntu Focal to Ubuntu Jammy, heat gate jobs have become very flaky. Further investigation revealed that the issue is related to something in libvirt from Ubuntu Jammy and that prevents detaching devices from instances[1]. The same problem appears in different jobs[2] and we workaround the problem by disabling some affected jobs. In heat we also disabled some flaky tests but because of this we no longer run basic scenario tests which deploys instance/volume/network in a single stack, which means we lost the quite basic test coverage. My question is, is there anyone in the Nova team working on "fixing" this problem ? We might be able to implement some workaround (like checking status of the instances before attempting to delete it) but this should be fixed in libvirt side IMO, as this looks like a "regression" in Ubuntu Jammy. Probably we should report a bug against the libvirt package in Ubuntu but I'd like to hear some thoughts from the nova team because they are more directly affected by this problem. I'm now trying to set up a centos stream 9 job in Heat repo to see whether this can be reproduced if we use centos stream 9. I've been running that specific scenario test in centos stream 9 jobs in puppet repos but I've never seen this issue, so I suspect the issue is really specific to libvirt in Jammy. [1] https://bugs.launchpad.net/nova/+bug/1998274 [2] https://bugs.launchpad.net/nova/+bug/1998148 Thank you, Takashi

3 5

[ptls] PyPI maintainer cleanup - Action needed: Contact extra maintainers
by Jay Faulkner 03 Apr '23

03 Apr '23

Hi PTLs, The TC recently voted[1] to require humans be removed from PyPI access for OpenStack-managed projects. This helps ensure all releases are created via releases team tooling and makes it less likely for a user account compromise to impact OpenStack packages. Many projects have already updated https://etherpad.opendev.org/p/openstack-pypi-maintainers-cleanup#L33 with a list of packages that contain extra maintainers. We'd like to request that PTLs, or their designate, reach out to any extra maintainers listed for projects you are responsible for and request they remove their access in accordance with policy. An example email, and detailed steps to follow have been provided at https://etherpad.opendev.org/p/openstack-pypi-maintainers-cleanup-email-tem… . Thank you for your cooperation as we work to improve our security posture and harden against supply chain attacks. Thank you, Jay Faulkner TC Vice-Chair 1: https://opendev.org/openstack/governance/commit/979e339f899ef62d2a6871a99c9…

3 6

[barbican] database is growing and can not be purged
by Pavlo Shchelokovskyy 03 Apr '23

03 Apr '23

Hi all, we are observing the following behavior in Barbican: - OpenStack environment is using both encrypted Cinder volumes and encrypted local storage (lvm) for Nova instances - over the time, the secrets and orders tables are growing - many soft-deleted entries in secrets DB can not be purged by the db cleanup script As I understand what is happening - both Cinder and Nova create secrets in Barbican on behalf of the user when creating an encrypted volume or booting an instance with encrypted local storage. They both do it via castellan library, that under the hood creates orders in Barbican, waits for them to become active and returns to the caller only the ID of the generated secret. When time comes to delete the thing (volume or instance) Cinder/Nova again use castellan, but only delete the secret, not the order (they are not aware that there was any 'order' created anyway). As a result, the orders are left in place, and DB cleanup procedure does not delete soft-deleted secrets when there's an ACTIVE order referencing such secret. This is troublesomes on many levels - users who use Cinder or Nova may not even be aware that they are creating something in Barbican. Orders accumulating like that may eventually result in cryptic errors when e.g. when you run out of quota for orders. And what's more, default Barbican policies do allow 'normal' (creator) users to create an order, but not delete it (only project admin can do it), so even if the users are aware of Barbican involvement, they can not delete those orders manually anyway. Plus there's no good way in API to determine outright which orders are referencing deleted secrets. I see several ways of dealing with that and would like to ask for your opinion on what would be the best one: 1. Amend Barbican API to allow filtering orders by the secrets, when castellan deletes a secret - search for corresponding order and delete it as well, change default policy to actually allow order deletion by the same users who can create them. 2. Cascade-delete orders when deleting secrets - this is easy but probably violates that very policy that disallowed normal users to delete orders. 3. improve the database cleanup so it first marks any order that references a deleted secret also as deleted, so later when time comes both could be purged (or something like that). This also has a similar downside to the previous option by not being explicit enough. I've filed a bug for that https://storyboard.openstack.org/#!/story/2010625 and proposed a patch for option 2 (cascade delete), but would like to ask what would you see as the most appropriate way or may be there's something else that I've missed. Btw, the problem is probably even more pronounced with keypairs - when castellan is used to create those, under the hood both order and container are created besides the actual secrets, and again only the secret ids are returned to the caller. When time comes to delete things, the caller only knows about secret IDs, and can only delete them, leaving both container and order behind. Luckily, I did not find any place across OpenStack that actually creates keypairs using castellan... but the problem is definitely there. Best regards, -- Dr. Pavlo Shchelokovskyy Principal Software Engineer Mirantis Inc www.mirantis.com

2 2

[kolla] Image building question
by Satish Patel 03 Apr '23

03 Apr '23

Folks, I am playing with kolla image building to understand how it works. I am using the following command to build images and wanted to check with you folks if that is the correct way to do it. $ kolla-build -b ubuntu -t source keystone nova neutron glance Does the above command compile code from source or just download images from remote repositories and re-compile them? because in command output I've not noticed anything related to the compiling process going on. Here is the output of all images produced by kolla-build command. Do I need anything else or is this enough to deploy kolla? root@docker-reg:~# docker images REPOSITORY TAG IMAGE ID CREATED SIZE kolla/mariadb-server 15.1.0 2a497eee8269 26 minutes ago 595MB kolla/cron 15.1.0 342877f26a8a 30 minutes ago 250MB kolla/memcached 15.1.0 0d19a4902644 31 minutes ago 250MB kolla/mariadb-clustercheck 15.1.0 d84427d3c639 31 minutes ago 314MB kolla/mariadb-base 15.1.0 34447e3e59b6 31 minutes ago 314MB kolla/keepalived 15.1.0 82133b09fbf0 31 minutes ago 260MB kolla/prometheus-memcached-exporter 15.1.0 6c2d605f70ee 31 minutes ago 262MB <none> <none> e66b228c2a07 31 minutes ago 248MB kolla/rabbitmq 15.1.0 8de5c39379d3 32 minutes ago 309MB kolla/fluentd 15.1.0 adfd19027862 33 minutes ago 519MB kolla/haproxy-ssh 15.1.0 514357ac4d36 36 minutes ago 255MB kolla/haproxy 15.1.0 e5b9cfdf6dfc 37 minutes ago 257MB kolla/prometheus-haproxy-exporter 15.1.0 a679f65fd735 37 minutes ago 263MB kolla/prometheus-base 15.1.0 afeff3ed5dce 37 minutes ago 248MB kolla/glance-api 15.1.0 a2241f68f23a 38 minutes ago 1.04GB kolla/glance-base 15.1.0 7286772a03a4 About an hour ago 1.03GB kolla/neutron-infoblox-ipam-agent 15.1.0 f90ffc1a3326 About an hour ago 1.05GB kolla/neutron-server 15.1.0 69c844a2e3a9 About an hour ago 1.05GB kolla/neutron-l3-agent 15.1.0 4d87e6963c96 About an hour ago 1.05GB <none> <none> 486da9a6562e About an hour ago 1.05GB kolla/neutron-linuxbridge-agent 15.1.0 e5b3ca7e099c About an hour ago 1.04GB kolla/neutron-bgp-dragent 15.1.0 ac37377820c6 About an hour ago 1.04GB kolla/ironic-neutron-agent 15.1.0 90993adcd74b About an hour ago 1.04GB kolla/neutron-metadata-agent 15.1.0 8522f147f88d About an hour ago 1.04GB kolla/neutron-sriov-agent 15.1.0 8a92ce7d13c0 About an hour ago 1.04GB kolla/neutron-dhcp-agent 15.1.0 5c214b0171f5 About an hour ago 1.04GB kolla/neutron-metering-agent 15.1.0 7b3b91ecd77b About an hour ago 1.04GB kolla/neutron-openvswitch-agent 15.1.0 1f8807308814 About an hour ago 1.04GB kolla/neutron-base 15.1.0 f85b6a2e2725 About an hour ago 1.04GB kolla/nova-libvirt 15.1.0 0f3ecefe4752 About an hour ago 987MB kolla/nova-compute 15.1.0 241b7e7fafbe About an hour ago 1.47GB kolla/nova-spicehtml5proxy 15.1.0 b740820a7ad1 About an hour ago 1.15GB kolla/nova-novncproxy 15.1.0 1ba2f443d5c3 About an hour ago 1.22GB kolla/nova-compute-ironic 15.1.0 716612107532 About an hour ago 1.12GB kolla/nova-ssh 15.1.0 ae2397f4e1c1 About an hour ago 1.11GB kolla/nova-api 15.1.0 2aef02667ff8 About an hour ago 1.11GB kolla/nova-conductor 15.1.0 6f1da3400901 About an hour ago 1.11GB kolla/nova-scheduler 15.1.0 628326776b1d About an hour ago 1.11GB kolla/nova-serialproxy 15.1.0 28eb7a4a13f8 About an hour ago 1.11GB kolla/nova-base 15.1.0 e47420013283 About an hour ago 1.11GB kolla/keystone 15.1.0 e5530d829d5f 2 hours ago 947MB kolla/keystone-ssh 15.1.0 eaa7e3f3985a 2 hours ago 953MB kolla/keystone-fernet 15.1.0 8a4fa24853a8 2 hours ago 951MB kolla/keystone-base 15.1.0 b6f9562364a9 2 hours ago 945MB kolla/barbican-base 15.1.0 b2fdef1afb44 2 hours ago 915MB kolla/barbican-keystone-listener 15.1.0 58bd59de2c63 2 hours ago 915MB kolla/openstack-base 15.1.0 c805b4b3b1c1 2 hours ago 893MB kolla/base 15.1.0 f68e9ef3dd30 2 hours ago 248MB registry 2 8db46f9d7550 19 hours ago 24.2MB ubuntu 22.04 08d22c0ceb15 3 weeks ago 77.8MB

4 8

[tripleo] Removal of TripleO Master Integration and Component Lines
by Ronelle Landy 03 Apr '23

03 Apr '23

Hello All, Removal of TripleO Master Integration and Component Lines Per the decision to not maintain TripleO after the Zed release [1], the master/main integration and component lines are being removed in the following patches: https://review.rdoproject.org/r/c/config/+/48073 https://review.rdoproject.org/r/c/config/+/48074 https://review.rdoproject.org/r/c/rdo-jobs/+/48075 The last promoted release of master through TripleO is: https://trunk.rdoproject.org/centos9-master/current-tripleo/delorean.repo (hash: ddce25bad764dde7e0515094b4d40471), which was promoted on 03/28/2023. Check/gate testing for the master branch is in process of being removed as well. [1] https://review.opendev.org/c/openstack/governance/+/878799

3 2

[kolla] horizon image build failed
by Satish Patel 03 Apr '23

03 Apr '23

Folks, All other images build successfully but when i am trying to build horizon which failed with following error: $ kolla-build --registry docker-reg:4000 -b ubuntu -t source --tag zed horizon INFO:kolla.common.utils.horizon:Collecting XStatic-Dagre>=0.6.4.0 INFO:kolla.common.utils.horizon: Downloading XStatic_Dagre-0.6.4.1-py2.py3-none-any.whl (140 kB) INFO:kolla.common.utils.horizon: ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 140.0/140.0 kB 14.4 MB/s eta 0:00:00 INFO:kolla.common.utils.horizon:Collecting XStatic-Dagre-D3>=0.4.17.0 INFO:kolla.common.utils.horizon: Downloading XStatic_Dagre_D3-0.4.17.0-py2.py3-none-any.whl (357 kB) INFO:kolla.common.utils.horizon: ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 357.4/357.4 kB 13.5 MB/s eta 0:00:00 INFO:kolla.common.utils.horizon:Requirement already satisfied: XStatic-Font-Awesome>=4.7.0.0 in /var/lib/kolla/venv/lib/python3.10/site-packages (from vitrage-dashboard==3.6.1.dev2) (4.7.0.0) INFO:kolla.common.utils.horizon:Collecting XStatic-Graphlib>=2.1.7.0 INFO:kolla.common.utils.horizon: Downloading XStatic_Graphlib-2.1.7.0-py2.py3-none-any.whl (51 kB) INFO:kolla.common.utils.horizon: ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 51.5/51.5 kB 114.3 MB/s eta 0:00:00 INFO:kolla.common.utils.horizon:Requirement already satisfied: XStatic-jQuery>=1.8.2.1 in /var/lib/kolla/venv/lib/python3.10/site-packages (from vitrage-dashboard==3.6.1.dev2) (1.12.4.1) INFO:kolla.common.utils.horizon:Collecting XStatic-lodash>=4.16.4.1 INFO:kolla.common.utils.horizon: Downloading XStatic_lodash-4.16.4.2-py3-none-any.whl (167 kB) INFO:kolla.common.utils.horizon: ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 167.9/167.9 kB 12.4 MB/s eta 0:00:00 INFO:kolla.common.utils.horizon:Collecting XStatic-moment>=2.8.4.1 INFO:kolla.common.utils.horizon: Downloading XStatic_moment-2.8.4.3-py3-none-any.whl (58 kB) INFO:kolla.common.utils.horizon: ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 58.0/58.0 kB 66.7 MB/s eta 0:00:00 INFO:kolla.common.utils.horizon:Collecting XStatic-Moment-Timezone>=0.5.22.0 INFO:kolla.common.utils.horizon: Downloading XStatic-Moment-Timezone-0.5.22.0.tar.gz (99 kB) INFO:kolla.common.utils.horizon: ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 99.7/99.7 kB 45.1 MB/s eta 0:00:00 INFO:kolla.common.utils.horizon: Preparing metadata (setup.py): started INFO:kolla.common.utils.horizon: Preparing metadata (setup.py): finished with status 'error' INFO:kolla.common.utils.horizon: error: subprocess-exited-with-error INFO:kolla.common.utils.horizon: INFO:kolla.common.utils.horizon: × python setup.py egg_info did not run successfully. INFO:kolla.common.utils.horizon: │ exit code: 1 INFO:kolla.common.utils.horizon: ╰─> [6 lines of output] INFO:kolla.common.utils.horizon: Traceback (most recent call last): INFO:kolla.common.utils.horizon: File "<string>", line 2, in <module> INFO:kolla.common.utils.horizon: File "<pip-setuptools-caller>", line 34, in <module> INFO:kolla.common.utils.horizon: File "/tmp/pip-install-dqag1zef/xstatic-moment-timezone_60eeadc1dfb9492781fe3ca90e3b95c2/setup.py", line 2, in <module> INFO:kolla.common.utils.horizon: from xstatic.pkg import moment_timezone as xs INFO:kolla.common.utils.horizon: ImportError: cannot import name 'moment_timezone' from 'xstatic.pkg' (unknown location) INFO:kolla.common.utils.horizon: [end of output] INFO:kolla.common.utils.horizon: INFO:kolla.common.utils.horizon: note: This error originates from a subprocess, and is likely not a problem with pip. INFO:kolla.common.utils.horizon: INFO:kolla.common.utils.horizon:error: metadata-generation-failed INFO:kolla.common.utils.horizon:× Encountered error while generating package metadata. INFO:kolla.common.utils.horizon:╰─> See above for output. INFO:kolla.common.utils.horizon:note: This is an issue with the package mentioned above, not pip. INFO:kolla.common.utils.horizon:hint: See above for details. INFO:kolla.common.utils.horizon: INFO:kolla.common.utils.horizon:Removing intermediate container e6cd437ba529 ERROR:kolla.common.utils.horizon:Error'd with the following message ERROR:kolla.common.utils.horizon:The command '/bin/sh -c ln -s horizon-source/* horizon && sed -i /^horizon=/d /requirements/upper-constraints.txt && SETUPTOOLS_USE_DISTUTILS=stdlib python3 -m pip --no-cache-dir install --upgrade -c /requirements/upper-constraints.txt /horizon && mkdir -p /etc/openstack-dashboard && cp -r /horizon/openstack_dashboard/conf/* /etc/openstack-dashboard/ && cp /horizon/openstack_dashboard/local/local_settings.py.example /etc/openstack-dashboard/local_settings && cp /horizon/manage.py /var/lib/kolla/venv/bin/manage.py && if [ "$(ls /plugins)" ]; then SETUPTOOLS_USE_DISTUTILS=stdlib python3 -m pip --no-cache-dir install --upgrade -c /requirements/upper-constraints.txt /plugins/*; fi && for locale in /var/lib/kolla/venv/lib/python3.10/site-packages/*/locale; do (cd ${locale%/*} && /var/lib/kolla/venv/bin/django-admin compilemessages) done && chmod 644 /usr/local/bin/kolla_extend_start' returned a non-zero code: 1 INFO:kolla.common.utils:========================= INFO:kolla.common.utils:Successfully built images INFO:kolla.common.utils:========================= INFO:kolla.common.utils:base INFO:kolla.common.utils:openstack-base INFO:kolla.common.utils:=========================== INFO:kolla.common.utils:Images that failed to build INFO:kolla.common.utils:===========================

4 8

[tc] No TC weekly meeting next week
by Nikolla, Kristi 31 Mar '23

31 Mar '23

Hi all, There will be no TC meeting on Tuesday, April 4th. The next TC meeting will be held on Tuesday, April 11 at 18.00 UTC. More information and an ICS file can be found here https://meetings.opendev.org/#Technical_Committee_Meeting Thank you, Kristi Nikolla

1 0

[release] Release countdown for week R-26, Apr 03 - 07
by Elõd Illés 31 Mar '23

31 Mar '23

Hi, Welcome back to the release countdown emails! These will be sent at major points in the 2023.2 Bobcat development cycle, which should conclude with a final release on October 4th, 2023. Development Focus ----------------- At this stage in the release cycle, focus should be on planning the 2023.2 Bobcat development cycle and approving 2023.2 Bobcat specs. General Information ------------------- 2023.2 Bobcat is a 28 weeks long development cycle. In case you haven't seen it yet, please take a look over the schedule for this release: https://releases.openstack.org/bobcat/schedule.html By default, the team PTL is responsible for handling the release cycle and approving release requests. This task can (and probably should) be delegated to release liaisons. Now is a good time to review release liaison information for your team and make sure it is up to date: https://opendev.org/openstack/releases/src/branch/master/data/release_liais… By default, all your team deliverables from the 2023.1 Antelope release are continued in 2023.2 Bobcat with a similar release model. Upcoming Deadlines & Dates -------------------------- Bobcat-1 milestone: May 11th, 2023 OpenInfra Summit + PTG Vancouver 2023 - June 13-15, 2023 Előd Illés irc: elodilles @ #openstack-release

1 0

[heat][qa][requirements] Pinning tempest in stable/xena constraints
by Takashi Kajinami 31 Mar '23

31 Mar '23

Hello, I have had some local discussions with gmann, but I'd really like to move this discussion forward to fix the broken stable/xena gate in heat so I will start this thread, hoping the thread can provide more context behind my proposal. Historically stable branches of heat have been frequently affected by any change in requirements of tempest. This is mainly because in our CI we install our own in-tree integration tests[1] into tempest venv where tempest and heat-tempest-plugin are installed. Because in-tree integration tests are tied to that specific stable branch, this has been often causing conflicts in requirements (master constraint vs stable/X constraint). [1] https://github.com/openstack/heat/tree/master/heat_integrationtests In the past we changed our test installation[2] to use stable constraint to avoid this conflicts, but this approach does no longer work since stable/xena because 1. stable/xena u-c no longer includes tempest 2. latest tempest CAN'T be installed with stable/xena u-c because current tempest requires fasteners>=0.16.0 which conflicts with 0.14.1 in stable/xena u-c. [2] https://review.opendev.org/c/openstack/heat/+/803890 https://review.opendev.org/c/openstack/heat/+/848215 I've proposed the change to pin tempest[3] in stable/xena u-c so that people can install tempest with stable/xena u-c. [3] https://review.opendev.org/c/openstack/requirements/+/878228 I understand the reason tempest was removed from u-c was that we should use the latest tempest to test recent stable releases.I agree we can keep tempest excluded for stable/yoga and onwards because tempest is installable with their u-c, but stable/xena u-c is no longer compatible with master. Adding pin to xena u-c does not mainly affect the policy to test stable branches with latest tempest because for that we anyway need to use more recent u-c. I'm still trying to find out the workaround within heat but IMO adding tempest pin to stable/xena u-c is harmless but beneficial in case anyone is trying to use tempest with stable/xena u-c. Thank you, Takashi Kajinami

4 10

Reminder! In Person PTG 2023 Team Signup Deadline
by Kendall Nelson 31 Mar '23

31 Mar '23

Hello Everyone, This is the last call to sign your team up for the *in-person* Project Teams Gathering (PTG) happening in Vancouver at the OpenInfra Summit! If you haven't already done so and your team is interested in participating, please complete the survey[1] by April 2nd, 2023 at 7:00 UTC. Registration for the PTG is included as a part of registration for the OpenInfra Summit in Vancouver. Prices increase May 5th so register soon! Thanks! -Kendall (diablo_rojo) [1] Team Survey: https://openinfrafoundation.formstack.com/forms/june2023_ptg_survey [2] Summit Registration: https://vancouver2023.openinfra.dev/ <https://vancouver2023.openinfra.dev/>

1 0

[openstack-helm][ptg] agenda changes for (Fri) Mar/31/2023
by Vladimir Kozhukalov 31 Mar '23

31 Mar '23

Dear helmers, Since we don't have any new topics in the etherpad [1] to discuss apart from those we discussed yesterday I think we can unbook our meeting room. Thanks for attending yesterday. I'll send the summary of our discussions later. [1] https://etherpad.opendev.org/p/march2023-ptg-openstack-helm -- Best regards, Kozhukalov Vladimir

1 0

[nova][ptg] Today's agenda (Friday)
by Sylvain Bauza 31 Mar '23

31 Mar '23

Hey folks, Today is our last vPTG day. The agenda is so : 13:00 UTC - 14:45 UTC : * Users reported exhaustion of primary keys ('id') in some large tables like system_metadata. How could we achieve a data migration from sa.Integer to sa.BigInteger ? * Should cold-migrate have a specific new policy like os_compute_api:os-migrate-server:migrate-specify-host to accept non-admins to migrate if they don't provide a host value ? * Discuss the next steps with compute hostname robustification * Disable compute services after being discovered * Limited lower constraint job in nova and placement 14:45 UTC - 15:00 UTC : break 15:00 UTC - 17:00 UTC : * Openstack server show command output (cross-project discussion with openstackSDK contributors) * Should we support dynamically disabling post copy live migration based on vm_state is paused ? * Evacuation with multiple allocations * Bobcat proposed planning (cont.) * trim support for virtio-blk feature or bug? * Summit/PTG : what could we be doing for the physical PTG ? (if we have time) As a reminder, you can look at the topics here : https://etherpad.opendev.org/p/nova-bobcat-ptg#L426 and you can add your IRC nick in the courtesy ping list if you want to be around. Hope you had a good week and see you in an hour by now ! -Sylvain

1 0

[Glance] Bobcat PTG Updates
by Pranali Deore 31 Mar '23

31 Mar '23

Hello Everyone, We have concluded Glance vPTG yesterday and I will share the summary early next week. You can find tentative milestone wise priorities for glance in PTG etherpad[1]. Join us in the weekly meeting coming Thursday if you have any doubts/suggestions. Thanks & Regards, Pranali [1]: https://etherpad.opendev.org/p/glance-bobcat-ptg#L143

1 0

[neutron][ptg] Today's agenda
by Rodolfo Alonso Hernandez 31 Mar '23

31 Mar '23

Hello Neutrinos: Today is the last day of the PTG. You can check the agenda in [1]. This is a quick summary: * Open hour for core reviewers: join us! Neutron needs you. * FIPS jobs: status and distro support. If you have a last minute topic, today is the best moment to show up and present it (it doesn't matter if it is not on the agenda). Regards. [1]https://etherpad.opendev.org/p/neutron-bobcat-ptg

1 0

Migration from linuxbridge to ovs
by Luk 31 Mar '23

31 Mar '23

Hello, Can You share some thoughts/ideas or some clues regarding migration from linux bridge to ovs ? Does this migration is posible without interrupting traffic from VMs ? We have now linuxbridge with l3-ha, and we noticed that for example when doing live migration of VM from linuxbridge baked compute to openvswitch compute is created bridge... inside openvswitch, instead adding qvo device to br-int: Bridge brq91dc40ac-ea datapath_type: system Port qvo84e2bd98-e9 Interface qvo84e2bd98-e9 Port brq91dc40ac-ea Interface brq91dc40ac-ea type: internal After removing the brq91dc40ac-ea from ovs, and hard reboot, the qvo interface is added properly to br-int: Bridge br-int Controller "tcp:127.0.0.1:6633" is_connected: true fail_mode: secure datapath_type: system Port qvo84e2bd98-e9 tag: 1 Interface qvo84e2bd98-e9 Also, before hard reboot, there is no flow for br-int or any other openvswitch bridge regarding this VM/ip. Does anyone have same problems ? Have tried to migrate from lb to ovs ? Openstack version: ussuri OS: ubuntu 20 Regards Lukasz

3 3

[Octavia] moving back to Launchpad
by Gregory Thiemonge 31 Mar '23

31 Mar '23

Hi Folks, During the Antelope PTG, we discussed the move from Storyboard to Launchpad, and in the Bobcat PTG session, we decided to switch at the beginning of the B cycle (now). The Octavia Launchpad [0] is now re-enabled, we are marking all the old entries as Invalid. We don't plan to have an automated migration script, we will duplicate manually the most recent bugs reported in Storyboard (not started bugs). I'm also proposing patches to update the links to the bug tracker in the Octavia projects. Greg [0] https://launchpad.net/octavia

2 1

[kolla-ansible] deploy cinder and glance with multi-backend
by wodel youchi 30 Mar '23

30 Mar '23

Hi, I need to deploy cinder and glance with multi-backend. My experience for now is simple, my deployment is an HCI built on top of ceph storage, and I am using it to store both cinder volumes and glance images. I have some questions if you can help: - can multi-backend be deployed at first run with kolla-ansible, or do I need to do at least two runs? - reading the doc about multi-backend, I saw that the first backend is specified, do I need to remove the creation of the first backend from glabals.yml and put it in a configuration file cinder.conf and glance.conf? In other words, do I have to create all the backends from the config files, or can I still create the first one using globals.yml and the rest from the config files? I hope my question is clear. Regards.

1 0

[neutron][ptg] Today's agenda
by Rodolfo Alonso Hernandez 30 Mar '23

30 Mar '23

Hello Neutrinos: Same as yesterday, we have a packed agenda. Today we'll have the Nova-Neutron meetings, starting at 13UTC. Quick summary: * delete_on_termination for Neutron ports * Blueprint: "Add support for Napatech LinkVirt SmartNICs" * https://bugs.launchpad.net/neutron/+bug/1986003 * ovn-bgp-agent roadmap * neutron-dynamic-routing: Make static scheduler finally the default? See you in a few minutes. Regards.

1 0

[nova][ptg] Today's agenda (Thursday)
by Sylvain Bauza 30 Mar '23

30 Mar '23

Heya again, Yesterday was a very productive day. Thanks folks. Today, we'll have mostly cross-project discussions but we'll also try to discuss about 3 topics : - 13:00 - 14:30 UTC : Nova-Neutron cross-project sessions* in the neutron room (tbd)* - 14:30 - 14:45 UTC : Transition Xena to EM, any concerns ? - 14:45 - 15:00 UTC : break - 15:00 - 15:30 UTC : Glance/Cinder/Nova cross-project session about secure glance Direct URLs *in the glance room (newton)* - 15:30 - 16:30 UTC : Cinder/Nova cross-project session* in the nova room (diablo)* - 16:30 - 16:50 UTC : Discuss the next steps with compute hostname robustification - 16:50 - 16:00 UTC : (tentatively) Instance.name is not persisted and just sub'd by every service calling the object Thanks and enjoy this day. -Sylvain

1 1

Nova undefine secret | openstack | wallaby
by Swogat Pradhan 30 Mar '23

30 Mar '23

Hi, For some reason, i had to redeploy ceph for my hci nodes and then found that the deployment command is giving out the following error: 2023-03-28 01:49:46.709605 | | WARNING | ERROR: Can't run container nova_libvirt_init_secret stderr: error: Failed to set attributes from /etc/nova/secret.xml error: internal error: a secret with UUID bd136bb0-fd78-5429-ab80-80b8c571d821 already defined for use with client.openstack secret 2023-03-28 01:49:46.711176 | 48d539a1-1679-623b-0af7-000000004b45 | FATAL | Create containers managed by Podman for /var/lib/tripleo-config/container-startup-config/step_4 | dcn01-hci-0 | error={"changed": false, "msg": "Failed containers: nova_libvirt_init_secret"} Can you please tell me how I can undefine the existing secret? With regards, Swogat Pradhan

3 5

[oslo][heat][masakari][senlin][venus][all] oslo.db 13.0.0 will remove sqlalchemy-migrate support
by Stephen Finucane 30 Mar '23

30 Mar '23

tl;dr: Projects still relying on sqlalchemy-migrate for migrations need to start their switch to alembic immediately. Projects with "legacy" sqlalchemy-migrated based migrations need to drop them. A quick heads up that oslo.db 13.0.0 will be release in the next month or so and will remove sqlalchemy-migrate support and formally add support for sqlalchemy 2.x. The removal of sqlalchemy-migrate support should only affect projects using oslo.db's sqlalchemy-migrate wrappers, as opposed to using sqlalchemy-migrate directly. For any projects that rely on this functionality, a short-term fix is to vendor the removed code [1] in your project. However, I must emphasise that we're not removing sqlalchemy-migrate integration for the fun of it: it's not compatible with sqlalchemy 2.x and is no longer maintained. If your project uses sqlalchemy-migrate and you haven't migrated to alembic yet, you need to start doing so immediately. If you have migrated to alembic but still have sqlalchemy- migrate "legacy" migrations in-tree, you need to look at dropping these asap. Anything less will result in broken master when we bump upper-constraints to allow sqlalchemy 2.x in Bobcat. I've listed projects in $subject that appear to be using the removed modules. For more advice on migrating to sqlalchemy 2.x and alembic, please look at my previous post on the matter [2]. Cheers, Stephen [1] https://review.opendev.org/c/openstack/oslo.db/+/853025 [2] https://lists.openstack.org/pipermail/openstack-discuss/2021-August/024122.…

3 3

[neutron][ovn] stateless SG behavior for metadata / slaac / dhcpv6
by Ihar Hrachyshka 30 Mar '23

30 Mar '23

Hi all, (I've tagged the thread with [ovn] because this question was raised in the context of OVN, but it really is about the intent of neutron stateless SG API.) Neutron API supports 'stateless' field for security groups: https://docs.openstack.org/api-ref/network/v2/index.html#stateful-security-… The API reference doesn't explain the intent of the API, merely walking through the field mechanics, as in "The stateful security group extension (stateful-security-group) adds the stateful field to security groups, allowing users to configure stateful or stateless security groups for ports. The existing security groups will all be considered as stateful. Update of the stateful attribute is allowed when there is no port associated with the security group." The meaning of the API is left for users to deduce. It's customary understood as something like "allowing to bypass connection tracking in the firewall, potentially providing performance and simplicity benefits" (while imposing additional complexity onto rule definitions - the user now has to explicitly define rules for both directions of a duplex connection.) [This is not an official definition, nor it's quoted from a respected source, please don't criticize it. I don't think this is an important point here.] Either way, the definition doesn't explain what should happen with basic network services that a user of Neutron SG API is used to rely on. Specifically, what happens for a port related to a stateless SG when it trying to fetch metadata from 169.254.169.254 (or its IPv6 equivalent), or what happens when it attempts to use SLAAC / DHCPv6 procedure to configure its IPv6 stack. As part of our testing of stateless SG implementation for OVN backend, we've noticed that VMs fail to configure via metadata, or use SLAAC to configure IPv6. metadata: https://bugs.launchpad.net/neutron/+bug/2009053 slaac: https://bugs.launchpad.net/neutron/+bug/2006949 We've noticed that adding explicit SG rules to allow 'returning' communication for 169.254.169.254:80 and RA / NA fixes the problem. I figured that these services are "base" / "basic" and should be provided to ports regardless of the stateful-ness of SG. I proposed patches for this here: metadata series: https://review.opendev.org/q/topic:bug%252F2009053 RA / NA: https://review.opendev.org/c/openstack/neutron/+/877049 Discussion in the patch that adjusts the existing stateless SG test scenarios to not create explicit SG rules for metadata and ICMP replies suggests that it's not a given / common understanding that these "base" services should work by default for stateless SGs. See discussion in comments here: https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/876692 While this discussion is happening in the context of OVN, I think it should be resolved in a broader context. Specifically, a decision should be made about what Neutron API "means" by stateless SGs, and how "base" services are supposed to behave. Then backends can act accordingly. There's also an open question of how this should be implemented. Whether Neutron would like to create explicit SG rules visible in API that would allow for the returning traffic and that could be deleted as needed, or whether backends should do it implicitly. We already have "default" egress rules, so there's a precedent here. On the other hand, the egress rules are broad (allowing everything) and there's more rationale to delete them and replace them with tighter filters. In my OVN series, I implement ACLs directly in OVN database, without creating SG rules in Neutron API. So, questions for the community to clarify: - whether Neutron API should define behavior of stateless SGs in general, - if so, whether Neutron API should also define behavior of stateless SGs in terms of "base" services like metadata and DHCP, - if so, whether backends should implement the necessary filters themselves, or Neutron will create default SG rules itself. I hope I laid the problem out clearly, let me know if anything needs clarification or explanation. Yours, Ihar

3 6

[Magnum] vPTG
by Jake Yip 30 Mar '23

30 Mar '23

Dear all, Magnum vPTG will be held at Wed 0900 UTC in the Havana Room. Please see etherpad https://etherpad.opendev.org/p/march2023-ptg-magnum for updates Regards, Jake (sorry for duplicates)

1 1

OpenStack 2023.1 Antelope for Ubuntu 22.04 LTS
by Corey Bryant 29 Mar '23

29 Mar '23

The Ubuntu OpenStack team at Canonical is pleased to announce the general availability of OpenStack 2023.1 Antelope on Ubuntu 22.04 LTS (Jammy Jellyfish). Details of the Antelope release can be found at: https://www.openstack.org/software/antelope The Ubuntu Cloud Archive for OpenStack 2023.1 Antelope can be enabled on Ubuntu 22.04 by running the following command: sudo add-apt-repository cloud-archive:antelope The Ubuntu Cloud Archive for 2023.1 Antelope includes updates for: aodh, barbican, ceilometer, cinder, designate, designate-dashboard, dpdk (22.11.1), glance, gnocchi, heat, heat-dashboard, horizon, ironic, ironic-ui, keystone, magnum, magnum-ui, manila, manila-ui, masakari, mistral, murano, murano-dashboard, networking-arista, networking-bagpipe, networking-baremetal, networking-bgpvpn, networking-hyperv, networking-l2gw, networking-mlnx, networking-odl, networking-sfc, neutron, neutron-dynamic-routing, neutron-fwaas, neutron-taas, neutron-vpnaas, nova, octavia, octavia-dashboard, openstack-trove, openvswitch (3.1.0), ovn (23.03.0), ovn-octavia-provider, placement, sahara, sahara-dashboard, senlin, swift, trove-dashboard, vitrage, watcher, watcher-dashboard, zaqar, and zaqar-ui. For a full list of packages and versions, please refer to: https://openstack-ci-reports.ubuntu.com/reports/cloud-archive/antelope_vers… == Reporting bugs == If you have any issues please report bugs using the ‘ubuntu-bug’ tool to ensure that bugs get logged in the right place in Launchpad: sudo ubuntu-bug nova-conductor Thank you to everyone who contributed to OpenStack 2023.1 Antelope! Corey (on behalf of the Ubuntu OpenStack Engineering team)

1 0

(Openstack-Designate) rndc key not getting generated in /etc/designate
by Adivya Singh 29 Mar '23

29 Mar '23

Hi Team, My DNS Server located outside the Open Stack, and i am using below variables in my user_variables.yaml File. But When i ' m running os-desigante-install.yml Playbook, rndc key are not generating in /etc/designate Folder and the playbook fail at the below Task {"msg": "The task includes an option with an undefined variable. The error was: 'dict object' has no attribute 'file'\n\nThe error appears to be in '/etc/ansible/roles/os_designate/tasks/designate_post_install.yml': line 89, column 3, but may\nbe elsewhere in the file depending on the exact syntax problem.\n\nThe offending line appears to be:\n\n\n- name: Create Designate rndc key file\n ^ here\n"} - name: Create Designate rndc key file template: src: rndc.key.j2 dest: "{{ item.file }}" owner: "{{ item.owner | default('root') }}" group: "{{ item.group | default('root') }}" mode: "{{ item.mode | default('0600') }}" with_items: "{{ designate_rndc_keys }}" when: designate_rndc_keys is defined and the post-install.yml File looks like this Any idea on this, Where i am missing ## rndc keys for authenticating with bind9 # define this to create as many key files as are required # designate_rndc_keys # - name: "rndc-key" # file: /etc/designate/rndc.key # algorithm: "hmac-md5" # secret: "<key>"

2 1

[ironic] bug tracking move to launchpad
by Julia Kreger 29 Mar '23

29 Mar '23

Greetings Ironic! During the PTG yesterday, we discussed the fact we had not moved back to Launchpad for bug tracking. Mainly because we are all very busy. The point was raised, why don't we just re-enable launchpad bug tracking, and move our primary usage back to that. Consensus on the call resulted with this proposal, and the consensus to send this email to the mailing list. As such, if nobody objects, I'm going to go turn the bug tracker for Ironic in launchpad back on next Monday. If you object, scream now and/or write a migration script and/or propose another solution. Thanks! -Julia

1 0

(Openstack-Nova)
by Adivya Singh 29 Mar '23

29 Mar '23

Hi Team I see these error in my syslog related to my nova compute service getting hung while communicating to rabbit-mq service "A recoverable connection/channel error occurred, trying to reconnect: [Errno 24] Too many open files" Is this a OS related error, or some thing i can change to get rid of this error Regards Adivya Singh

3 2

[neutron] BGP for self-service network
by Deniz AYDIN 29 Mar '23

29 Mar '23

Hi, I am looking for options for removing Layer-2 in the underlay as much as possible. The features explained in the document, BGP floating IPs over L2 segmented network <https://docs.openstack.org/neutron/zed/admin/config-bgp-floating-ip-over-l2…>, solve the problem for floating IPS where layer 2 is only needed between servers and rack switches. Is there any specific reason that this feature is limited to floating IPS? As long as we have unique BGP next-hops defined for every DVR, it can also be used for advertising self-service networks /32 routes. Thanks for the help Deniz

1 0

[nova] openstack-tox-pep8 job broken, hold your rechecks
by melanie witt 29 Mar '23

29 Mar '23

Hey all, Sending this to the ML to try to help others who may not have heard about it yet. I didn't know about myself until I saw the job fail on a random nova patch and I looked around to figure out why. It looks like openstack-tox-pep8 is failing 100% in nova due to a newer version of the mypy library being pulled in since a recent upper-constraints bump: https://review.opendev.org/c/openstack/requirements/+/872065 And the job isn't going to pass until the following fix merges: https://review.opendev.org/c/openstack/nova/+/878693 Finally, to help prevent a breakage for this in the future, a cross-nova-pep8 job has been approved: https://review.opendev.org/c/openstack/requirements/+/878748 and will be on its way to the gate once the aforementioned fix merges. I'll post a reply to this email when it's OK to do rechecks again. Cheers, -melwitt

2 3

[nova] Hold your rechecks
by Sylvain Bauza 29 Mar '23

29 Mar '23

Hey, Due to the recent merge of https://review.opendev.org/c/openstack/requirements/+/872065/10/upper-const… we now use mypy==1.1.1 which includes a breaking behavioural change against our code : https://07de6a0c9e6ec0c6835f-ccccbfab26b1456f69293167016566bc.ssl.cf2.rackc… Thanks to Eric (kudos to him, he was quickier than me), we have a fix https://review.opendev.org/c/openstack/nova/+/878693 Please accordingly hold your rechecks until that fix is merged. -Sylvain

1 1

[PTL][release][stable][EM] Extended Maintenance - Xena
by Elõd Illés 29 Mar '23

29 Mar '23

Hi teams, As 2023.1 Antelope was released last week and we are in a less busy period, now is the good time to call your attention to the following: In less than a month Xena is planned to transition to Extended Maintenance phase [1] (planned date: 2023-04-20). I have generated the list of the current *open* and *unreleased* changes in stable/xena for every repositories [2] (where there are such patches). These lists could help the teams who are planning to do a *final* release on Xena before moving stable/xena branches to Extended Maintenance. Feel free to edit and extend these lists to track your team's progress! Note that the *latest* Xena *release* tagging patches ('xena-em' tag) have been generated too in advance [3], please mark with a -1 if your team plans to do a final release, or +1 if the team is ready for the transition. The schedule from now on is as follows: * patches with +1 from PTL / release liaison will be merged, thus those repositories will transition to Extended Maintenance * at the planned deadline (April 20th) the Release Team will merge all of the transition patches (even the ones without any response!) * after the transition, stable/xena will be still open for bug fixes, but there won't be official releases anymore. *NOTE*: teams, please focus on wrapping up your libraries first if there is any concern about the changes, in order to avoid broken (final!!) releases! [1] https://releases.openstack.org/ [2] https://etherpad.opendev.org/p/xena-final-release-before-em [3] https://review.opendev.org/q/topic:xena-em Thanks, Előd irc: elodilles @ #openstack-release

1 0

[nova][ptg] Today's agenda
by Sylvain Bauza 29 Mar '23

29 Mar '23

(just shamelessly stealing the idea from Neutron's team) Hey foks, Yesterday was a packed day but we didn't really progressed on a lot of topics. Today I'm gonna propose a list of topics in order to improve our sessions's visibility and in order to provide some timeboxing. 13:00 UTC - 14:45 UTC : * How to make sure people can help to review ? * Should we ask for some implementation before accepting a spec ? * CI stability is a nightmare, let's fight over this * Bobcat is a non-SLURP release * Let's clean up our upgrade documentation * Nova community outreach * Clean-up our bug list by abandoning very old LP bug reports ? * Summit/PTG : what could we be doing for the physical PTG ? (Will be 4 weeks before milestone-2) 15:00 UTC - 15:45 UTC : * Nova/Manila cross-project session : Prevent share deletion while it's attached to an instance 16:00 UTC - 17:00 UTC : * When your instance is stuck due to hard affinity policies, what could we do ? * Users reported exhaustion of primary keys ('id') in some large tables like system_metadata. How could we achieve a data migration from sa.Integer to sa.BigInteger ? Details can be found in https://etherpad.opendev.org/p/nova-bobcat-ptg#L192 I assume the packed agenda, particularly the first two hours. As a reminder, people are welcome to add their IRC nicks in each of the courtesy ping list of the related topic. Hope this gives you a taste of joining the Nova PTG today. -Sylvain

1 0

[neutron][ptg] Today's agenda
by Rodolfo Alonso Hernandez 29 Mar '23

29 Mar '23

Hello all: This is a quick summary of the agenda for today's meeting (starting at 13UTC): * Status and questions about https://review.opendev.org/q/topic:port-hints * IPv6 Prefix Delegation in OVN * Neutron agents status (https://bugs.launchpad.net/neutron/+bug/2011422) * DHCP IPv6 issues with metadata service ( https://bugs.launchpad.net/neutron/+bug/1953165) * Operator hour Please check the full agenda, topics and past logs in https://etherpad.opendev.org/p/neutron-bobcat-ptg. Regards.

1 0

[Horizon][policies][keystone] allow _member_ role to add user
by James Leong 28 Mar '23

28 Mar '23

Hi all, I am using kolla-ansible for OpenStack deployment in the yoga version. Would it be possible to allow a user with a "_member_" role to add a user to the respective project? In OpenStack, an admin role allows users to add, delete, and edit a user profile. I would like to have the same privilege added to the "_member_" role. I have tried to modify the file "user.py" in the keystone container at "keystone/common/policies" and restarted the container. However, the button on my horizon dashboard did not appear. How could I integrate the code in order to allow the create button to appear on my dashboard with the "_member_" role? Is there a way to do that? THanks for your help James

1 0

[scientific-sig] PTG sessions for Scientific SIG
by Stig Telfer 28 Mar '23

28 Mar '23

Hi all - The Scientific SIG has two sessions on Wednesday (tomorrow) at the PTG, at 1400 UTC and 2100 UTC. Everyone is welcome. There is an etherpad for the sessions here: https://etherpad.opendev.org/p/march2023-ptg-scientific-sig <https://etherpad.opendev.org/p/march2023-ptg-scientific-sig>. We'll begin with an introduction to the SIG and some discussion of problems, challenges and new features specific to research computing use cases. We'd also like participants to contribute lightning talks about anything relevant that is of interest to them. Cheers, Stig

1 0

[Magnum] vPTG
by Jake Yip 28 Mar '23

28 Mar '23

Dear all, Magnum vPTG will be held at Wed 0900 UTC in the Havana Room. Please see etherpad https://etherpad.opendev.org/p/march2023-ptg-magnum for updates Regards, Jake -- Jake Yip DevOps Engineer, ARDC Nectar Research Cloud

2 1

[networking-mlnx] release job failure - missing openstackci as maintainer in pypi
by Elõd Illés 28 Mar '23

28 Mar '23

Hi networking-mlnx maintainers, latest networking-mlnx releases caused release job failures [1][2][3], with the following error: The user 'openstackci' isn't allowed to upload to project 'networking-mlnx'. (note, that networking-mlnx is not under openstack namespace (x/networking-mlnx)) [1] https://lists.openstack.org/pipermail/release-job-failures/2023-March/00165… [2] https://lists.openstack.org/pipermail/release-job-failures/2023-March/00165… [3] https://lists.openstack.org/pipermail/release-job-failures/2023-March/00165… Thanks, Előd irc: elodilles @ #openstack-release

1 0

[Freezer] Restore action report ERROR can't delete temporary Image
by Annie Liu(BJ-RD) 28 Mar '23

28 Mar '23

Hi All My Cinder Backend is Ceph, and so is Glance. For backup and restore, I choose Cinder for mode and local for storage . When I restore a Cinder volume with Freezer, an ERROR reported related to deleting temporary Image failure, which makes the whole restore flow can't be completed. 2023-03-23 16:53:50.555 361 ERROR freezer.main [-] HTTP 409 Conflict: Image 8af4be3f-2e7a-4965-8b34-74e610a89a3e could not be deleted because it is in use: The image cannot be deleted because it is in use through the backend store outside of Glance.: HTTPConflict: HTTP 409 Conflict: Image 8af4be3f-2e7a-4965-8b34-74e610a89a3e could not be deleted because it is in use: The image cannot be deleted because it is in use through the backend store outside of Glance. According to Cinder source code, the volume created from Image is a child of the Image, since it is made by clone which means it doesn't copy volume data at first. In other words, the Image is its parent holding the real data, and that's why deleting is failed. My question is, is this a general issue for other storage solution? Is there any opportunity to fix it? For example, do a flatten immediately after create volume from Image? Thanks. Beat Regards, Annie Liu ????? ????????????????????????????????????????????????????? CONFIDENTIAL NOTE: This email contains confidential or legally privileged information and is for the sole use of its intended recipient. Any unauthorized review, use, copying or forwarding of this email or the content of this email is strictly prohibited.

1 0

[neutron] Bug deputy report (week of Mar 20)
by Akihiro Motoki 28 Mar '23

28 Mar '23

Hi, Here is the bug deputy report last week. Hopefully, someone familiar with DNS integration can check the first bug. # Needs assignee * FQDN inside guest VM is not the same as dns_assignment on network port https://bugs.launchpad.net/neutron/+bug/2012391 It would be nice if someone familiar with DNS integration can look into it. * [CI] "neutron-ovs-grenade-multinode-skip-level" and "neutron-ovn-grenade-multinode-skip-level" failing always https://bugs.launchpad.net/neutron/+bug/2012731 # New but assigned * [OVN] Define the OVS port in the LSP to allow OVN to set the QoS rules https://bugs.launchpad.net/neutron/+bug/2012613 Assigned to ralonsoh # In Progress * [ovn] N/S traffic for VMs without FIPs not working https://bugs.launchpad.net/neutron/+bug/2012712 Assigned to ltomasbo [1] was proposed as a fix of bug 2012712 which is caused by [2]. In parallel, [3] was proposed to revert [2]. Reverting [2] first sounds reasonable to avoid the regression but it is better to clarify the priority and the relationship in the review comments. ltomasbo is involved in both, so I think there is no confusion though. [1] https://review.opendev.org/c/openstack/neutron/+/878450 [2] https://review.opendev.org/c/openstack/neutron/+/875644 [3] https://review.opendev.org/c/openstack/neutron/+/878441 * neutron-ovn-agent fails on do_commit aborted due to error: 'Chassis_Private' https://bugs.launchpad.net/neutron/+bug/2012385 * Intermittent failures of test_agent_metadata_port_ip_update_event https://bugs.launchpad.net/neutron/+bug/2012754 * [sqlalchemy-20] sqlalchemy.exc.InvalidRequestError: No 'on clause' argument may be passed when joining to a relationship path as a target https://bugs.launchpad.net/neutron/+bug/2012643 * [sqlalchemy-20] Strings are not accepted for attribute names in loader options https://bugs.launchpad.net/neutron/+bug/2012662 * [sqlalchemy-20] Unexpected keyword argument "when" in "sqlalchemy.case" method https://bugs.launchpad.net/neutron/+bug/2012705 # RFE * [rfe] Add one api support CRUD allowed_address_pairs https://bugs.launchpad.net/neutron/+bug/2012332 Thanks, Akihiro Motoki (amotoki)

1 0

(Open Stack )Image Upload in Open Stack in a Bulk
by Adivya Singh 28 Mar '23

28 Mar '23

Hi Team, Any hints, if i want to upload images in a bulk in a Open Stack , because it takes some time for the image to copy if we go one by one, or even of we go with script Also if there is a scenario where glance mount point fails and we can create the same Share path and Copy the Image from the source , Will the OpenStack glance Service will start detecting those images upload in a share Regards Adivya Singh

2 3

[swift][ptg] Ops Feedback Session - 29th March at 13:00 UTC
by Matthew Oliver 28 Mar '23

28 Mar '23

As we've done in PTGs past, we're getting devs and ops together to talk about Swift: what's working, what isn't, and what would be most helpful to improve. We're meeting in Ocata (https://www.openstack.org/ptg/rooms/ocata) at 13:00UTC -- if you run a Swift cluster, we hope to see you there! Even if you can't make it, We'd appreciate it if you can offer some feedback on the feedback etherpad (https://etherpad.opendev.org/p/swift-bobcat-ops-feedback ). This has always been a highlight at every PTG for us swift devs. Have your say and help make Swift even better! Matt

1 0

DCN compute service goes down when a instance is scheduled to launch | wallaby | tripleo
by Swogat Pradhan 28 Mar '23

28 Mar '23

Hi, I currently have 3 compute nodes on edge site1 where i am trying to launch vm's. When the VM is in spawning state the node goes down (openstack compute service list), the node comes backup when i restart the nova compute service but then the launch of the vm fails. nova-compute.log 2023-02-26 08:15:51.808 7 INFO nova.compute.manager [req-bc0f5f2e-53fc-4dae-b1da-82f1f972d617 - - - - -] Running instance usage audit for host dcn01-hci-0.bdxworld.com from 2023-02-26 07:00:00 to 2023-02-26 08:00:00. 0 instances. 2023-02-26 08:49:52.813 7 INFO nova.compute.claims [req-3a1547ea-326f-4dd0-9127-7f4a4bdf1e45 b240e3e89d99489284cd731e75f2a5db 4160ce999a31485fa643aed0936dfef0 - default default] [instance: 0c62c1ef-9010-417d-a05f-4db77e901600] Claim successful on node dcn01-hci-0.bdxworld.com 2023-02-26 08:49:54.225 7 INFO nova.virt.libvirt.driver [req-3a1547ea-326f-4dd0-9127-7f4a4bdf1e45 b240e3e89d99489284cd731e75f2a5db 4160ce999a31485fa643aed0936dfef0 - default default] [instance: 0c62c1ef-9010-417d-a05f-4db77e901600] Ignoring supplied device name: /dev/vda. Libvirt can't honour user-supplied dev names 2023-02-26 08:49:54.398 7 INFO nova.virt.block_device [req-3a1547ea-326f-4dd0-9127-7f4a4bdf1e45 b240e3e89d99489284cd731e75f2a5db 4160ce999a31485fa643aed0936dfef0 - default default] [instance: 0c62c1ef-9010-417d-a05f-4db77e901600] Booting with volume c4bd7885-5973-4860-bbe6-7a2f726baeee at /dev/vda 2023-02-26 08:49:55.216 7 WARNING nova.cache_utils [req-3a1547ea-326f-4dd0-9127-7f4a4bdf1e45 b240e3e89d99489284cd731e75f2a5db 4160ce999a31485fa643aed0936dfef0 - default default] Cache enabled with backend dogpile.cache.null. 2023-02-26 08:49:55.283 7 INFO oslo.privsep.daemon [req-3a1547ea-326f-4dd0-9127-7f4a4bdf1e45 b240e3e89d99489284cd731e75f2a5db 4160ce999a31485fa643aed0936dfef0 - default default] Running privsep helper: ['sudo', 'nova-rootwrap', '/etc/nova/rootwrap.conf', 'privsep-helper', '--config-file', '/etc/nova/nova.conf', '--config-file', '/etc/nova/nova-compute.conf', '--privsep_context', 'os_brick.privileged.default', '--privsep_sock_path', '/tmp/tmpin40tah6/privsep.sock'] 2023-02-26 08:49:55.791 7 INFO oslo.privsep.daemon [req-3a1547ea-326f-4dd0-9127-7f4a4bdf1e45 b240e3e89d99489284cd731e75f2a5db 4160ce999a31485fa643aed0936dfef0 - default default] Spawned new privsep daemon via rootwrap 2023-02-26 08:49:55.717 2647 INFO oslo.privsep.daemon [-] privsep daemon starting 2023-02-26 08:49:55.722 2647 INFO oslo.privsep.daemon [-] privsep process running with uid/gid: 0/0 2023-02-26 08:49:55.726 2647 INFO oslo.privsep.daemon [-] privsep process running with capabilities (eff/prm/inh): CAP_SYS_ADMIN/CAP_SYS_ADMIN/none 2023-02-26 08:49:55.726 2647 INFO oslo.privsep.daemon [-] privsep daemon running as pid 2647 2023-02-26 08:49:55.956 7 WARNING os_brick.initiator.connectors.nvmeof [req-3a1547ea-326f-4dd0-9127-7f4a4bdf1e45 b240e3e89d99489284cd731e75f2a5db 4160ce999a31485fa643aed0936dfef0 - default default] Process execution error in _get_host_uuid: Unexpected error while running command. Command: blkid overlay -s UUID -o value Exit code: 2 Stdout: '' Stderr: '': oslo_concurrency.processutils.ProcessExecutionError: Unexpected error while running command. 2023-02-26 08:49:58.247 7 INFO nova.virt.libvirt.driver [req-3a1547ea-326f-4dd0-9127-7f4a4bdf1e45 b240e3e89d99489284cd731e75f2a5db 4160ce999a31485fa643aed0936dfef0 - default default] [instance: 0c62c1ef-9010-417d-a05f-4db77e901600] Creating image Is there a way to solve this issue? With regards, Swogat Pradhan

5 40

[ironic] Slight PTG Schedule change
by Jay Faulkner 27 Mar '23

27 Mar '23

Take notice: tomorrow's topic schedule has been changed slightly. We have moved Service Steps and DPU Orchestration conversations up 30 minutes. As mentioned in the other thread ( https://lists.openstack.org/pipermail/openstack-discuss/2023-March/032983.h…) I accidentally booked Firmware Upgrades to two times. This was fortuitous because we needed to add a cross-team item with Keystone. As always, the up to date schedule and notes are here: https://etherpad.opendev.org/p/ironic-bobcat-ptg Thanks, Jay Faulkner Ironic PTL

1 0

[all][ptg] Pre-PTG discussion: New Keystone Middleware Feature Supporting OAuth2.0 with External Authorization Service
by Hiromu Asahina 27 Mar '23

27 Mar '23

Hello Everyone, Recently, Tacker and Keystone have been working together on a new Keystone Middleware that can work with external authentication services, such as Keycloak. The code has already been submitted [1], but we want to make this middleware a generic plugin that works with as many OpenStack services as possible. To that end, we would like to hear from other projects with similar use cases (especially Ironic and Barbican, which run as standalone services). We will make a time slot to discuss this topic at the next vPTG. Please contact me if you are interested and available to participate. [1] https://review.opendev.org/c/openstack/keystonemiddleware/+/868734 -- Hiromu Asahina

4 11

[nova] Can OpenStack support snapshot rollback (not creating a new instance)?
by 韩光宇 27 Mar '23

27 Mar '23

Hello, I use Ceph as the storage backend for Nova, Glance, and Cinder. If I create a snapshot for a instance, It create a new image in glance. And I can use the image to create a new instance. This feels to me more like creating an image based on the current state of the VM rather than creating a VM snapshot. I want to ask: 1、Can I create and revert a VM snapshot like I would in virtual machine software? 2、When a VM uses multiple disks/volumes, does OpenStack support taking a snapshot of all disks/volumes of the VM as a whole? 3、Can OpenStack snapshot and save the memory state of a VM? If it is not currently supported, are there any simple customization implementation ideas that can be recommended? Thank you for any help and suggestions. Best wishes. Han

3 2

[neutron][release] Proposing transition to EOL Train (all Neutron related projects)
by Rodolfo Alonso Hernandez 27 Mar '23

27 Mar '23

Hello: I'm sending this mail in advance to propose transitioning Neutron and all related projects to EOL. I'll propose this topic too during the next Neutron meeting. The announcement is the first step [1] to transition a stable branch to EOL. The patch to mark these branches as EOL will be pushed in two weeks. If you have any inconvenience, please let me know in this mail chain or in IRC (ralonsoh, #openstack-neutron channel). You can also contact any Neutron core reviewer in the IRC channel. Regards. [1] https://docs.openstack.org/project-team-guide/stable-branches.html#end-of-l…

3 3

[ptg][sdk][cli][ansible] PTG Slot for SDK, CLI, Ansible collection OpenStack is now booked
by Artem Goncharov 27 Mar '23

27 Mar '23

Hi all, A bit late, but still - I have booked a 3 hours slot during PTG on Friday 14:00-17:00 UTC. This will follow publiccloud room discussion so I think some people and outcomes will follow directly into our room. Etherpad is there: https://etherpad.opendev.org/p/march2023-ptg-sdk-cli Feel free to feel in topics you want to discuss Cheers, Artem

3 6

[Diversity] Diversity and Inclusion at the PTG
by Amy Marrich 24 Mar '23

24 Mar '23

I have blocked off three hours on Monday for the D&I WG to discuss the upcoming Diversity Survey(14:00 UTC) and then ongoing changes to the Code of Conduct(15:00- 16:00 UTC) and then the Summit if there is time. The agenda can be found here[0]. All projects are encouraged to attend these sessions as the WG is at the Foundation level. Thanks, Amy (spotz) 0 - https://etherpad.opendev.org/p/march2023-ptg-diversity

1 0

[openstack-helm] PTG March 27-31 2023
by Vladimir Kozhukalov 24 Mar '23

24 Mar '23

Dear openstack-helmers, As you know PTG is going to happen next week and I booked slots at the end of the week on Thursday 03/30 and on Friday 03/31 from 14:00 UTC till 17:00 UTC [1] I believe this should be enough. If you feel other time slots are gonna work better for any reason there are still some free slots that can be booked. Please also pay some attention to the etherpad where I listed some of the points for our discussions. [2] Please feel free to add other points that you think worth it to be discussed. [1] https://ptg.opendev.org/ptg.html [2] https://etherpad.opendev.org/p/march2023-ptg-openstack-helm -- Best regards, Kozhukalov Vladimir

1 0

[i18n][PTG] I18n SIG 2023.2 (Bobcat) PTG Planning
by Ian Y. Choi 24 Mar '23

24 Mar '23

Hi, PTG is coming next week. I have blocked the following schedule - anyone can check via https://ptg.opendev.org/ptg.html and please let me know if more discussion is needed during PTG. Those are topics what I am thinking currently but it is open - feel free to suggest any topic to be discussed: - Weblate migration - Translation artifacts release management - Review of i18n statistics & ATC/AC - Discussion on translation target - Overall OpenStack/OpenInfra I18n process/progress review - Check-in on each language team Discussions will be shared via Etherpad: https://etherpad.opendev.org/p/march2023-ptg-i18n . Lastly, please don't forget to register if you have forgotten: https://openinfra-ptg.eventbrite.com :) Looking forward to a productive PTG with I18n. Thank you, /Ian

1 0

[cinder][PTG] Cinder 2023.2 (Bobcat) Virtual PTG
by Rajat Dhasmana 24 Mar '23

24 Mar '23

Hello Argonauts, We will be conducting cinder virtual PTG for 2023.2 (Bobcat) cycle from 28th March to 31st March, 2023. I've prepared the PTG etherpad[1] with topics day wise. I haven't kept the schedule time bound since some discussions take less and some take more time and in both cases reaching a conclusion is important. There are some events that need to be done on their respective time are as follows: *1) Operator Hour: *We encourage operators to join and tell us about the pain points of cinder so we can improve upon it. Date: Wednesday, 29 March, 2023 Time: 1400-1500 UTC Link: https://bluejeans.com/556681290 *2) Glance Cross Project* Date: Thursday, 30 March, 2023 Time: 1430-1500 UTC Link: https://bluejeans.com/556681290 *3) Nova Cross Project* Date: Thursday, 30 March, 2023 Time: 1600-1700 UTC Link: https://zoom.us/j/96494117185?pwd=NGhya0NpeWppMEc1OUNKdlFPbDNYdz09 (Diablo room) The general information about the PTG is as follows: Date: 28th March to 31st March, 2023 Time: 1300-1700 UTC everyday Link to PTG: https://bluejeans.com/556681290 You can also follow the schedule at https://ptg.opendev.org/ptg.html Note that we have allocated 4 hours each day but it also depends on the number and duration of topics as to how long the PTG will run. If you want to be reminded about a particular topic, please add your IRC nick in the *Courtesy ping list *mentioned after every topic. If you still have topics, please add them to the Planning etherpad[2] and I will see if we can accommodate that into our current schedule. Lastly, we will be cancelling our cinder upstream meeting (Wednesday, 29 March, 1400-1500 UTC) since it overlaps with the PTG. If you still have topics please bring it to the PTG. See you all at the PTG! [1] https://etherpad.opendev.org/p/bobcat-ptg-cinder [2] https://etherpad.opendev.org/p/bobcat-ptg-cinder-planning Thanks Rajat Dhasmana

1 0

[TripleO] Last maintained release of TripleO is Wallaby
by James Slagle 24 Mar '23

24 Mar '23

The team of TripleO developers, reviewers, and community have no plans to do another release of TripleO, or to continue maintaining the Zed release. This means the last maintained release of TripleO is Wallaby. The plan is to continue to maintain the train and wallaby branches of TripleO repositories under the openstack namespace. We plan to continue to run existing CI on those branches, although we anticipate reducing to a minimal set of jobs in the future. Going forward, the TripleO team expects to continue involvement in other OpenStack projects, and focus on different approaches to OpenStack deployment. The team is not aware of enough other community interest to continue to maintain the zed, master, and future branches of TripleO. Eventually, we will empty commit these branches with a pointer to Wallaby being the last release. If other interests do exist to maintain TripleO going forward, then those plans can adjust. TripleO does not plan on nominating a PTL in the current Bobcat election cycle. If a PTL-like contact is needed for train and wallaby maintenance, then someone will be nominated. I am also not sure how to reflect this project structure change within openstack/governance, and am looking for guidance on how to do so. This type of change did not seem to exactly fit within the concepts of inactive or retired projects. I can work on the patches for governance with some direction, if anyone can provide it. Thanks, and please let us know any questions or feedback about this plan. -- -- James Slagle --

6 21

[security-sig] vPTG sessions 16:00 UTC Tuesday and Wednesday
by Jeremy Stanley 24 Mar '23

24 Mar '23

I've booked two hours on the vPTG schedule, Tuesday and Wednesday 16:00-17:00 UTC, in the hopes that interested parties will be able to make at least one of those if not both. We'll use OpenDev's Meetpad service: https://meetpad.opendev.org/march2023-ptg-os-security I tried to avoid booking conflicts with Barbican and Keystone since those are the two projects our participants traditionally have obligatory conflicts from (also worked around the TC, Release and Diversity WG sessions). I know folks from Ironic wanted to talk about VMT topics, but our times overlap with some of theirs so we can either try to talk about that in one of the non-overlapping Ironic sessions or they can join us during ours, whichever works better. I've started adding some proposed discussion topics to the corresponding pad, but anyone can feel free to throw ideas in there, or just bring them up once we're on the call... I'm not one to stand on ceremony: https://etherpad.opendev.org/p/march2023-ptg-os-security Hopefully some people will be able to make it, but if you want other times on the schedule too then let me know and I'll try to work something out. -- Jeremy Stanley

1 0

[blazar][ptg] Bobcat PTG scheduling
by Pierre Riteau 24 Mar '23

24 Mar '23

Hello, The Bobcat PTG will happen online during the week starting March 27. As the Blazar project has done in the past, I suggest we meet on Thursday, but starting 1400 UTC rather than the usual 1500 of our biweekly meeting. I have booked two hours in the Bexar room. If you want to join, please let me know if this works for you. To summarise, the Blazar project will meet on Thursday March 30 from 1400 UTC to 1600 UTC. We will prepare discussion topics on Etherpad. Cheers, Pierre Riteau (priteau)

1 1

OUTREACHY INITIAL APPLICANT
by Anointing Adetoye 24 Mar '23

24 Mar '23

Good day I have been unable to make relevant contributions because I don't know how to start contributing or converse on the channel. Also, I am a golang developer that is just picking C and I would really like to use this opportunity to build my knowledge in C. I will appreciate it if i get pointed to how to make contribution and also utilize the few weeks remaining to make relevant contribution to the project.

2 1

[neutron] Neutron driver's meeting cancelled
by Rodolfo Alonso Hernandez 24 Mar '23

24 Mar '23

Hello Neutrinos: Today's drivers meeting is cancelled. The only topic in the agenda [1] was agreed to be discussed during the PTG. Join us next week in the PTG sessions! Here is the Neutron agenda [2] and the PTG website [3]. We'll be on the Juno channel. Have a nice weekend. [1]https://wiki.openstack.org/wiki/Meetings/NeutronDrivers [2]https://etherpad.opendev.org/p/neutron-bobcat-ptg [3]https://ptg.opendev.org/ptg.html

1 0

[nova]host cpu reserve
by Nguyễn Hữu Khôi 24 Mar '23

24 Mar '23

Hello guys. I am trying google for nova host cpu reserve to prevent host overload but I cannot find any resource about it. Could you give me some information? Thanks. Nguyen Huu Khoi

3 12

回复： [ironic]Questions about the use of the build image tool
by 任亮 24 Mar '23

24 Mar '23

I have found the cause of the problem, which is because tar does not exist in the working directory. I wonder if there are requirements on the base image when building from the base image.  Thank you. 发自我的企业微信 ----------回复的邮件信息---------- 任亮<renliang(a)uniontech.xn--com> 2023-03-23-jw84b 周四 15:01写道： Hi We are using diskimage-builder to make a custom image, There is a problem in extract_image, The question is chroot: failed to run command 'bin/tar': No such file or directory, I found the /bin/tar file in the working directory /tmp/ tmp.00yldwe1xt. But errors are still being reported. It's not clear if this is a custom image problem, There are also requirements for custom images. 发自我的企业微信

2 1

[manila] Cancelling March 30th IRC weekly meeting
by Carlos Silva 24 Mar '23

24 Mar '23

Hello Zorillas! As mentioned in today's IRC meeting, we will be having several meetings at the PTG next week, so we will not have our usual IRC meeting on Thursday March 30th 15 UTC. See you at the PTG! Regards, carloss

1 0

[manila] Bobcat vPTG slots and topics
by Carlos Silva 24 Mar '23

24 Mar '23

Hello, Zorillas! PTG is right around the corner and I would like to remind you to please add the topics you would like to bring up during our sessions to the planning etherpad [1] until next Tuesday (Mar 21st). I have already allocated some slots for our sessions: - Monday: 16:00 to 17:00 UTC - Wednesday: 14:00 to 16:00 UTC - Thursday: 14:00 to 16:00 UTC - Friday: 14:00 to 17:00 UTC We will be meeting in the Austin room, you can access the meeting room through the PTG page [2]. If you have a preference of date/time for your topic to be discussed, please let me know and I will try to accommodate it. Looking forward to meeting you! [1] https://etherpad.opendev.org/p/manila-bobcat-ptg-planning [2] https://ptg.opendev.org/ptg.html Thanks, carloss

1 1

[tc] No TC weekly meeting next week + meeting time change
by Nikolla, Kristi 23 Mar '23

23 Mar '23

Hi all, Due to the vPTG being held next week, the TC will not hold its regular weekly meeting that was scheduled for Wednesday, March 29, 2023. Please note, that after the PTG, the new meeting time will be Tuesdays 18.00 UTC. More information and an ICS file can be found here https://meetings.opendev.org/#Technical_Committee_Meeting Thank you, Kristi Nikolla

1 0

[tc][ptl][ptg] TC + Community Leaders Interaction for 2023.2 vPTG
by Nikolla, Kristi 23 Mar '23

23 Mar '23

Hello everyone, On Monday, March 27, 2023 16.00UTC to 18.00UTC, the TC is organizing the Technical Committee & Community Leaders Interaction. While this meeting is open to all, we would like to invite participation especially from PTL, TC, and SIG Chairs with the goal of gathering feedback and promoting collaboration. This meeting has been quite successful in the last 2 PTG and I'm hoping we can continue this tradition. If you have an item you'd like to propose for discussion please add it to the purposefully quite empty etherpad[0], where you can also find information and details on how to join. 0. https://etherpad.opendev.org/p/tc-leaders-interaction-2023-2 Hope to see you there, Kristi Nikolla

1 0

[all][tc][goal][policy] RBAC goal discussion in 2023.2 PTG
by Ghanshyam Mann 23 Mar '23

23 Mar '23

Hello Everyone, I have booked the Tuesday 17-18 UTC slot bexar room for the RBAC goal discussion. You can add the topics/queries to be discussed in vPTG in the below etherpad. - https://etherpad.opendev.org/p/rbac-2023.2-ptg -gmann

1 0

Fwd: [PTG] Environmental Sustainability WG goes to the vPTG next week!
by Kendall Nelson 23 Mar '23

23 Mar '23

[Cross posting from the foundation ML] Hello Everyone! I have finally begun setting up the etherpad for our time during the PTG. I have the Austin room reserved on Tuesday from 16-18 UTC. I hope to see you all there and please add to the etherpad if there is a related topic you think we should discuss! Here is the etherpad: https://etherpad.opendev.org/p/march2023-ptg-env-sus -Kendall Nelson

1 0

[nova][ptg][ops] Nova at the vPTG (+ skipping next weekly meeting)
by Sylvain Bauza 23 Mar '23

23 Mar '23

Hey folks, As a reminder, the Nova community will discuss at the vPTG. You can see the topics we'll talk in https://etherpad.opendev.org/p/nova-bobcat-ptg Our agenda will be from Tuesday to Friday, everyday between 1300UTC and 1700UTC. Connection details are in the etherpad above, but you can also use PTGbot website : https://ptg.opendev.org/ptg.html (we'll use the diablo room for all the discussions) You can't stick around for 4 hours x 4 days ? Heh, no worries ! If you (as an operator or a developer) want to engage with us (and we'd love this honestly), you have two possibilities : - either you prefer to listen (and talk) to some topics you've seen in the agenda, and then add your IRC nick (details how to use IRC are explained by [1]) on the topics you want. Once we start to discuss about those topics, I'll ping the courtesy ping list of each topic on #openstack-nova. Just make sure you're around in the IRC channel. - or you prefer to engage with us about some pain points or some feature requests, and then the right time is the Nova Operator Hour that will be on *Tuesday 1500UTC*. We have a specific etherpad for this session : https://etherpad.opendev.org/p/march2023-ptg-operator-hour-nova where you can preemptively add your thoughts or concerns. Anyway, we are eager to meet you all ! Oh, last point, given we will be at the vPTG, next week's weekly meeting on Tuesday is CANCELLED. But I guess you'll see it either way if you lurk the #openstack-nova channel ;-) See you next week ! -Sylvain [1] https://lists.openstack.org/pipermail/openstack-discuss/2023-March/032853.h…

3 4

[qa][ptg] Virtual Bobcat vPTG Planning
by Martin Kopec 23 Mar '23

23 Mar '23

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

1 1

[tacker][ptg] Bobcat vPTG Planning
by Yasufumi Ogawa 23 Mar '23

23 Mar '23

Hi team, We are going to have the Bobcat vPTG through three days, 28-30 Mar 6am-8am UTC as agreed at the IRC meeting last week. I've booked rooms for the sessions and uploaded etherpad [1]. Please feel free to add your proposal on the etherpad. [1] https://etherpad.opendev.org/p/tacker-bobcat-ptg Thanks, Yasufumi

1 1

[heat][PTG] 2023.2 (Bobcat) PTG Planning
by Takashi Kajinami 23 Mar '23

23 Mar '23

Hello, I've signed up for the upcoming virtual PTG so that we can have some slots for Heat discussion. In case you are interested in attending the sessions or have any topics you want to discuss, please put your name and the proposed topics in the etherpad. https://etherpad.opendev.org/p/march2023-ptg-heat-planning It'd be nice if we can update the planning etherpad this week so that I'll fix our slots and topics early next week. Thank you, Takashi Kajinami

1 1

[ironic]Questions about the use of the build image tool
by 任亮 23 Mar '23

23 Mar '23

Hi We are using diskimage-builder to make a custom image, There is a problem in extract_image, The question is chroot: failed to run command 'bin/tar': No such file or directory, I found the /bin/tar file in the working directory /tmp/ tmp.00yldwe1xt. But errors are still being reported. It's not clear if this is a custom image problem, There are also requirements for custom images. 发自我的企业微信

1 0

Unable to create volume with image in edge site | Glance-Cinder | Openstack DCN | Wallaby
by Swogat Pradhan 22 Mar '23

22 Mar '23

Hi, I am creating a fresh thread for this glance issue. I have setup glance multistore for my infra. glance.yaml for dcn site: (overcloud) [stack@hkg2director ~]$ cat dcn02/glance_dcn02.yaml parameter_defaults: #GlanceShowMultipleLocations: true GlanceEnabledImportMethods: web-download,copy-image GlanceBackend: rbd GlanceStoreDescription: 'dcn02 rbd glance store' GlanceBackendID: dcn02 CephClusterName: dcn02 GlanceMultistoreConfig: ceph: GlanceBackend: rbd GlanceStoreDescription: 'Default glance store backend.' CephClusterName: ceph Now i have created a cirros image and have imported it to dcn store using copy-image method. When I create an empty volume in the DCN site the volume gets created without any issues. But when I create a volume with image (volume source) the volume gets stuck in the creating state forever. I get logs in cinder-volume 3-4 mins after I have hit the create volume button. Cinder logs: 2023-03-22 20:34:59.166 108 INFO cinder.volume.flows.manager.create_volume [req-0d2093a0-efbd-45a5-bd7d-cce25ddc200e b240e3e89d99489284cd731e75f2a5db 4160ce999a31485fa643aed0936dfef0 - - -] Volume 5743a879-090d-46db-bc7c-1c0b0669a112: being created as image with specification: {'status': 'creating', 'volume_name': 'volume-5743a879-090d-46db-bc7c-1c0b0669a112', 'volume_size': 2, 'image_id': 'acfd0a14-69e0-44d6-a6a1-aa9dc83e9d5b', 'image_location': ('rbd://a5ae877c-bcba-53fe-8336-450e63014757/images/acfd0a14-69e0-44d6-a6a1-aa9dc83e9d5b/snap', [{'url': 'rbd://a5ae877c-bcba-53fe-8336-450e63014757/images/acfd0a14-69e0-44d6-a6a1-aa9dc83e9d5b/snap', 'metadata': {'store': 'ceph'}}, {'url': 'rbd://a8d5f1f5-48e7-5ede-89ab-8aca59b6397b/images/acfd0a14-69e0-44d6-a6a1-aa9dc83e9d5b/snap', 'metadata': {'store': 'dcn02'}}]), 'image_meta': {'name': 'cirros', 'disk_format': 'qcow2', 'container_format': 'bare', 'visibility': 'public', 'size': 16338944, 'virtual_size': 117440512, 'status': 'active', 'checksum': '1d3062cd89af34e419f7100277f38b2b', 'protected': False, 'min_ram': 0, 'min_disk': 0, 'owner': '4160ce999a31485fa643aed0936dfef0', 'os_hidden': False, 'os_hash_algo': 'sha512', 'os_hash_value': '553d220ed58cfee7dafe003c446a9f197ab5edf8ffc09396c74187cf83873c877e7ae041cb80f3b91489acf687183adcd689b53b38e3ddd22e627e7f98a09c46', 'id': 'acfd0a14-69e0-44d6-a6a1-aa9dc83e9d5b', 'created_at': datetime.datetime(2023, 3, 22, 18, 50, 5, tzinfo=datetime.timezone.utc), 'updated_at': datetime.datetime(2023, 3, 22, 20, 3, 54, tzinfo=datetime.timezone.utc), 'locations': [{'url': 'rbd://a5ae877c-bcba-53fe-8336-450e63014757/images/acfd0a14-69e0-44d6-a6a1-aa9dc83e9d5b/snap', 'metadata': {'store': 'ceph'}}, {'url': 'rbd://a8d5f1f5-48e7-5ede-89ab-8aca59b6397b/images/acfd0a14-69e0-44d6-a6a1-aa9dc83e9d5b/snap', 'metadata': {'store': 'dcn02'}}], 'direct_url': 'rbd://a5ae877c-bcba-53fe-8336-450e63014757/images/acfd0a14-69e0-44d6-a6a1-aa9dc83e9d5b/snap', 'tags': [], 'file': '/v2/images/acfd0a14-69e0-44d6-a6a1-aa9dc83e9d5b/file', 'stores': 'ceph,dcn02', 'properties': {'os_glance_failed_import': '', 'os_glance_importing_to_stores': '', 'owner_specified.openstack.md5': '', 'owner_specified.openstack.object': 'images/cirros', 'owner_specified.openstack.sha256': ''}}, 'image_service': <cinder.image.glance.GlanceImageService object at 0x7f8147973438>} I checked both glance and cinder containers are running in a healthy state. I see no errors or whatsoever. I am not sure how to fix the cinder volume stuck in the creating state in the DCN edge site. With regards, Swogat Pradhan

1 1

[neutron] detecting l3-agent readiness
by Mohammed Naser 22 Mar '23

22 Mar '23

Hi folks, I'm working on improving the stability of rollouts when using Kubernetes as a control plane, specifically around the L3 agent, it seems that I have not found a clear way to detect in the code path where the L3 agent has finished it's initial sync.. Am I missing it somewhere or is the architecture built in a way that doesn't really answer that question? Thanks Mohammed -- Mohammed Naser VEXXHOST, Inc.

7 11

[ptl] Need PTL volunteer for OpenStack Sahara
by Ghanshyam Mann 22 Mar '23

22 Mar '23

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

1 0

Re: [cinder] Error when creating backups from iscsi volume
by Gorka Eguileor 22 Mar '23

22 Mar '23

On 11/03, Rishat Azizov wrote: > Hi, Gorka, > > Thanks. I see multiple "multipath -f" calls. Logs in attachments. > Hi, There are multiple things going on here: 1. There is a bug in os-brick, because the disconnect_volume should not fail, since it is being called with force=True and ignore_errors=True. The issues is that this call [1] is not wrapped in the ExceptionChainer context manager, and it should not even be a flush call, it should be a call to "multipathd remove map $map" instead. 2. The way multipath code is written [2][3], the error we see about "3624a93705842cfae35d7483200015fce is not a multipath device" means 2 different things: it is not a multipath or an error happened. So we don't really know what happened without enabling more verbose multipathd log levels. 3. The "multipath -f" call should not be failing in the first place, because the failure is happening on disconnecting the source volume, which has no data buffered to be written and therefore no reason to fail the flush (unless it's using a friendly name). I don't know if it could be happening that the first flush fails with a timeout (maybe because there is an extend operation happening), but multipathd keeps trying to flush it in the background and when it succeeds it removes the multipath device, which makes following calls fail. If that's the case we would need to change the retry from automatic [4] to manual and check in-between to see if the device has been removed in-between calls. The first issue is definitely a bug, the 2nd one is something that could be changed in the deployment to try to get additional information on the failure, and the 3rd one could be a bug. I'll see if I can find someone who wants to work on the 1st and 3rd points. Cheers, Gorka. [1]: https://github.com/openstack/os-brick/blob/e15edf6c17449899ec8401c37482f7cb… [2]: https://github.com/opensvc/multipath-tools/blob/db4804bc7393f2482448bdd8701… [3]: https://github.com/opensvc/multipath-tools/blob/db4804bc7393f2482448bdd8701… [4]: https://github.com/openstack/os-brick/blob/e15edf6c17449899ec8401c37482f7cb… > > чт, 9 мар. 2023 г. в 15:55, Gorka Eguileor <geguileo(a)redhat.com>: > > > On 06/03, Rishat Azizov wrote: > > > Hi, > > > > > > It works with smaller volumes. > > > > > > multipath.conf attached to thist email. > > > > > > Cinder version - 18.2.0 Wallaby > > > > Hi, > > > > After giving it some thought I think I may know what is going on. > > > > If you have DEBUG logs enabled in cinder-backup when it fails, how many > > calls do you see in the cinder-backup to "multipath -f" from os-brick, > > only one or do you see more? > > > > Cheers, > > Gorka. > > > > > > > > пн, 6 мар. 2023 г. в 17:35, Gorka Eguileor <geguileo(a)redhat.com>: > > > > > > > On 16/02, Rishat Azizov wrote: > > > > > Hello! > > > > > > > > > > We have an error with creating backups from iscsi volume. Usually, > > this > > > > > happens with large backups over 100GB. > > > > > > > > > > 2023-02-16 00:23:25.298 1920 ERROR oslo_messaging.rpc.server > > > > > [req-f6619913-6f96-4226-8d75-2da3fca722f1 > > > > 23de1b92e7674cf59486f07ac75b886b > > > > > a7585b47d1f143e9839c49b4e3bbe1b4 - - -] Exception during message > > > > handling: > > > > > oslo_concurrency.processutils.ProcessExecutionError: Unexpected error > > > > while > > > > > running command. > > > > > Command: multipath -f 3624a93705842cfae35d7483200015ec6 > > > > > Exit code: 1 > > > > > Stdout: '' > > > > > Stderr: 'Feb 16 00:22:45 | 3624a93705842cfae35d7483200015ec6 is not a > > > > > multipath device\n' > > > > > 2023-02-16 00:23:25.298 1920 ERROR oslo_messaging.rpc.server > > Traceback > > > > > (most recent call last): > > > > > 2023-02-16 00:23:25.298 1920 ERROR oslo_messaging.rpc.server File > > > > > "/usr/lib/python3.6/site-packages/oslo_messaging/rpc/server.py", line > > > > 165, > > > > > in _process_incoming > > > > > 2023-02-16 00:23:25.298 1920 ERROR oslo_messaging.rpc.server res > > = > > > > > self.dispatcher.dispatch(message) > > > > > 2023-02-16 00:23:25.298 1920 ERROR oslo_messaging.rpc.server File > > > > > "/usr/lib/python3.6/site-packages/oslo_messaging/rpc/dispatcher.py", > > line > > > > > 309, in dispatch > > > > > 2023-02-16 00:23:25.298 1920 ERROR oslo_messaging.rpc.server > > return > > > > > self._do_dispatch(endpoint, method, ctxt, args) > > > > > 2023-02-16 00:23:25.298 1920 ERROR oslo_messaging.rpc.server File > > > > > "/usr/lib/python3.6/site-packages/oslo_messaging/rpc/dispatcher.py", > > line > > > > > 229, in _do_dispatch > > > > > 2023-02-16 00:23:25.298 1920 ERROR oslo_messaging.rpc.server > > result = > > > > > func(ctxt, **new_args) > > > > > 2023-02-16 00:23:25.298 1920 ERROR oslo_messaging.rpc.server File > > > > > "/usr/lib/python3.6/site-packages/cinder/utils.py", line 890, in > > wrapper > > > > > 2023-02-16 00:23:25.298 1920 ERROR oslo_messaging.rpc.server > > return > > > > > func(self, *args, **kwargs) > > > > > 2023-02-16 00:23:25.298 1920 ERROR oslo_messaging.rpc.server File > > > > > "/usr/lib/python3.6/site-packages/cinder/backup/manager.py", line > > 410, in > > > > > create_backup > > > > > 2023-02-16 00:23:25.298 1920 ERROR oslo_messaging.rpc.server > > > > > volume_utils.update_backup_error(backup, str(err)) > > > > > 2023-02-16 00:23:25.298 1920 ERROR oslo_messaging.rpc.server File > > > > > "/usr/lib/python3.6/site-packages/oslo_utils/excutils.py", line 227, > > in > > > > > __exit__ > > > > > 2023-02-16 00:23:25.298 1920 ERROR oslo_messaging.rpc.server > > > > > self.force_reraise() > > > > > 2023-02-16 00:23:25.298 1920 ERROR oslo_messaging.rpc.server File > > > > > "/usr/lib/python3.6/site-packages/oslo_utils/excutils.py", line 200, > > in > > > > > force_reraise > > > > > 2023-02-16 00:23:25.298 1920 ERROR oslo_messaging.rpc.server > > raise > > > > > self.value > > > > > 2023-02-16 00:23:25.298 1920 ERROR oslo_messaging.rpc.server File > > > > > "/usr/lib/python3.6/site-packages/cinder/backup/manager.py", line > > 399, in > > > > > create_backup > > > > > 2023-02-16 00:23:25.298 1920 ERROR oslo_messaging.rpc.server > > updates > > > > = > > > > > self._run_backup(context, backup, volume) > > > > > 2023-02-16 00:23:25.298 1920 ERROR oslo_messaging.rpc.server File > > > > > "/usr/lib/python3.6/site-packages/cinder/backup/manager.py", line > > 493, in > > > > > _run_backup > > > > > 2023-02-16 00:23:25.298 1920 ERROR oslo_messaging.rpc.server > > > > > ignore_errors=True) > > > > > 2023-02-16 00:23:25.298 1920 ERROR oslo_messaging.rpc.server File > > > > > "/usr/lib/python3.6/site-packages/cinder/backup/manager.py", line > > 1066, > > > > in > > > > > _detach_device > > > > > 2023-02-16 00:23:25.298 1920 ERROR oslo_messaging.rpc.server > > > > > force=force, ignore_errors=ignore_errors) > > > > > 2023-02-16 00:23:25.298 1920 ERROR oslo_messaging.rpc.server File > > > > > "/usr/lib/python3.6/site-packages/os_brick/utils.py", line 141, in > > > > > trace_logging_wrapper > > > > > 2023-02-16 00:23:25.298 1920 ERROR oslo_messaging.rpc.server > > return > > > > > f(*args, **kwargs) > > > > > 2023-02-16 00:23:25.298 1920 ERROR oslo_messaging.rpc.server File > > > > > "/usr/lib/python3.6/site-packages/oslo_concurrency/lockutils.py", > > line > > > > 360, > > > > > in inner > > > > > 2023-02-16 00:23:25.298 1920 ERROR oslo_messaging.rpc.server > > return > > > > > f(*args, **kwargs) > > > > > 2023-02-16 00:23:25.298 1920 ERROR oslo_messaging.rpc.server File > > > > > > > > > > > "/usr/lib/python3.6/site-packages/os_brick/initiator/connectors/iscsi.py", > > > > > line 880, in disconnect_volume > > > > > 2023-02-16 00:23:25.298 1920 ERROR oslo_messaging.rpc.server > > > > > is_disconnect_call=True) > > > > > 2023-02-16 00:23:25.298 1920 ERROR oslo_messaging.rpc.server File > > > > > > > > > > > "/usr/lib/python3.6/site-packages/os_brick/initiator/connectors/iscsi.py", > > > > > line 942, in _cleanup_connection > > > > > 2023-02-16 00:23:25.298 1920 ERROR oslo_messaging.rpc.server > > > > > self._linuxscsi.flush_multipath_device(multipath_name) > > > > > 2023-02-16 00:23:25.298 1920 ERROR oslo_messaging.rpc.server File > > > > > "/usr/lib/python3.6/site-packages/os_brick/initiator/linuxscsi.py", > > line > > > > > 382, in flush_multipath_device > > > > > 2023-02-16 00:23:25.298 1920 ERROR oslo_messaging.rpc.server > > > > > root_helper=self._root_helper) > > > > > 2023-02-16 00:23:25.298 1920 ERROR oslo_messaging.rpc.server File > > > > > "/usr/lib/python3.6/site-packages/os_brick/executor.py", line 52, in > > > > > _execute > > > > > 2023-02-16 00:23:25.298 1920 ERROR oslo_messaging.rpc.server > > result = > > > > > self.__execute(*args, **kwargs) > > > > > 2023-02-16 00:23:25.298 1920 ERROR oslo_messaging.rpc.server File > > > > > "/usr/lib/python3.6/site-packages/os_brick/privileged/rootwrap.py", > > line > > > > > 172, in execute > > > > > 2023-02-16 00:23:25.298 1920 ERROR oslo_messaging.rpc.server > > return > > > > > execute_root(*cmd, **kwargs) > > > > > 2023-02-16 00:23:25.298 1920 ERROR oslo_messaging.rpc.server File > > > > > "/usr/lib/python3.6/site-packages/oslo_privsep/priv_context.py", line > > > > 247, > > > > > in _wrap > > > > > 2023-02-16 00:23:25.298 1920 ERROR oslo_messaging.rpc.server > > return > > > > > self.channel.remote_call(name, args, kwargs) > > > > > 2023-02-16 00:23:25.298 1920 ERROR oslo_messaging.rpc.server File > > > > > "/usr/lib/python3.6/site-packages/oslo_privsep/daemon.py", line 224, > > in > > > > > remote_call > > > > > 2023-02-16 00:23:25.298 1920 ERROR oslo_messaging.rpc.server > > raise > > > > > exc_type(*result[2]) > > > > > 2023-02-16 00:23:25.298 1920 ERROR oslo_messaging.rpc.server > > > > > oslo_concurrency.processutils.ProcessExecutionError: Unexpected error > > > > while > > > > > running command. > > > > > 2023-02-16 00:23:25.298 1920 ERROR oslo_messaging.rpc.server Command: > > > > > multipath -f 3624a93705842cfae35d7483200015ec6 > > > > > 2023-02-16 00:23:25.298 1920 ERROR oslo_messaging.rpc.server Exit > > code: 1 > > > > > 2023-02-16 00:23:25.298 1920 ERROR oslo_messaging.rpc.server Stdout: > > '' > > > > > 2023-02-16 00:23:25.298 1920 ERROR oslo_messaging.rpc.server Stderr: > > 'Feb > > > > > 16 00:22:45 | 3624a93705842cfae35d7483200015ec6 is not a multipath > > > > device\n' > > > > > 2023-02-16 00:23:25.298 1920 ERROR oslo_messaging.rpc.server > > > > > > > > > > Could you please help with this error? > > > > > > > > Hi, > > > > > > > > Does it work for smaller volumes or does it also fail? > > > > > > > > What are your defaults in your /etc/multipath.conf file? > > > > > > > > What Cinder release are you using? > > > > > > > > Cheers, > > > > Gorka. > > > > > > > > > > > > > defaults { > > > user_friendly_names no > > > find_multipaths yes > > > enable_foreign "^$" > > > } > > > > > > blacklist_exceptions { > > > property "(SCSI_IDENT_|ID_WWN)" > > > } > > > > > > blacklist { > > > } > > > > > > devices { > > > device { > > > vendor "PURE" > > > product "FlashArray" > > > fast_io_fail_tmo 10 > > > path_grouping_policy "group_by_prio" > > > failback "immediate" > > > prio "alua" > > > hardware_handler "1 alua" > > > max_sectors_kb 4096 > > > } > > > } > > > > > 2023-03-10 16:42:41.785 2878341 DEBUG cinder.backup.drivers.ceph [req-bdebfdef-daf3-4250-8594-9ed91adb7c00 f91779ad06064ebfbeeff54de535a6cd 8a676a415f9541c59705a373a36b0ec4 - - -] Transferred chunk 1600 of 1600 (84387K/s) _transfer_data /usr/lib/python3.6/site-packages/cinder/backup/drivers/ceph.py:426 > 2023-03-10 16:42:42.107 2878341 DEBUG cinder.backup.driver [req-bdebfdef-daf3-4250-8594-9ed91adb7c00 f91779ad06064ebfbeeff54de535a6cd 8a676a415f9541c59705a373a36b0ec4 - - -] Getting metadata type 'volume-base-metadata' _save_vol_base_meta /usr/lib/python3.6/site-packages/cinder/backup/driver.py:79 > 2023-03-10 16:42:42.139 2878341 DEBUG cinder.backup.driver [req-bdebfdef-daf3-4250-8594-9ed91adb7c00 f91779ad06064ebfbeeff54de535a6cd 8a676a415f9541c59705a373a36b0ec4 - - -] Completed fetching metadata type 'volume-base-metadata' _save_vol_base_meta /usr/lib/python3.6/site-packages/cinder/backup/driver.py:98 > 2023-03-10 16:42:42.139 2878341 DEBUG cinder.backup.driver [req-bdebfdef-daf3-4250-8594-9ed91adb7c00 f91779ad06064ebfbeeff54de535a6cd 8a676a415f9541c59705a373a36b0ec4 - - -] Getting metadata type 'volume-metadata' _save_vol_meta /usr/lib/python3.6/site-packages/cinder/backup/driver.py:109 > 2023-03-10 16:42:42.147 2878341 DEBUG cinder.backup.driver [req-bdebfdef-daf3-4250-8594-9ed91adb7c00 f91779ad06064ebfbeeff54de535a6cd 8a676a415f9541c59705a373a36b0ec4 - - -] No metadata type 'volume-metadata' available _save_vol_meta /usr/lib/python3.6/site-packages/cinder/backup/driver.py:123 > 2023-03-10 16:42:42.148 2878341 DEBUG cinder.backup.driver [req-bdebfdef-daf3-4250-8594-9ed91adb7c00 f91779ad06064ebfbeeff54de535a6cd 8a676a415f9541c59705a373a36b0ec4 - - -] Getting metadata type 'volume-glance-metadata' _save_vol_glance_meta /usr/lib/python3.6/site-packages/cinder/backup/driver.py:132 > 2023-03-10 16:42:42.156 2878341 DEBUG cinder.backup.driver [req-bdebfdef-daf3-4250-8594-9ed91adb7c00 f91779ad06064ebfbeeff54de535a6cd 8a676a415f9541c59705a373a36b0ec4 - - -] Completed fetching metadata type 'volume-glance-metadata' _save_vol_glance_meta /usr/lib/python3.6/site-packages/cinder/backup/driver.py:145 > 2023-03-10 16:42:42.157 2878341 DEBUG cinder.backup.drivers.ceph [req-bdebfdef-daf3-4250-8594-9ed91adb7c00 f91779ad06064ebfbeeff54de535a6cd 8a676a415f9541c59705a373a36b0ec4 - - -] Backing up metadata for volume 7e9beead-01a6-488e-bc2f-47093a8cdbd9. _backup_metadata /usr/lib/python3.6/site-packages/cinder/backup/drivers/ceph.py:946 > 2023-03-10 16:42:42.251 2878341 DEBUG cinder.backup.drivers.ceph [req-bdebfdef-daf3-4250-8594-9ed91adb7c00 f91779ad06064ebfbeeff54de535a6cd 8a676a415f9541c59705a373a36b0ec4 - - -] Backup '4f32e959-509d-49d9-9674-acc3776b4b6a' of volume 7e9beead-01a6-488e-bc2f-47093a8cdbd9 finished. backup /usr/lib/python3.6/site-packages/cinder/backup/drivers/ceph.py:1011 > 2023-03-10 16:42:42.252 2878341 DEBUG oslo_concurrency.processutils [req-bdebfdef-daf3-4250-8594-9ed91adb7c00 f91779ad06064ebfbeeff54de535a6cd 8a676a415f9541c59705a373a36b0ec4 - - -] Running cmd (subprocess): sudo cinder-rootwrap /etc/cinder/rootwrap.conf chown 0 /dev/dm-5 execute /usr/lib/python3.6/site-packages/oslo_concurrency/processutils.py:384 > 2023-03-10 16:42:42.613 2878341 DEBUG oslo_concurrency.processutils [req-bdebfdef-daf3-4250-8594-9ed91adb7c00 f91779ad06064ebfbeeff54de535a6cd 8a676a415f9541c59705a373a36b0ec4 - - -] CMD "sudo cinder-rootwrap /etc/cinder/rootwrap.conf chown 0 /dev/dm-5" returned: 0 in 0.361s execute /usr/lib/python3.6/site-packages/oslo_concurrency/processutils.py:423 > 2023-03-10 16:42:42.614 2878341 DEBUG os_brick.initiator.connectors.iscsi [req-bdebfdef-daf3-4250-8594-9ed91adb7c00 f91779ad06064ebfbeeff54de535a6cd 8a676a415f9541c59705a373a36b0ec4 - - -] ==> disconnect_volume: call "{'args': (<os_brick.initiator.connectors.iscsi.ISCSIConnector object at 0x7fe6925c3ac8>, {'target_discovered': False, 'discard': True, 'target_luns': [1, 1, 1, 1], 'target_iqns': ['iqn.2010-06.com.purestorage:flasharray.55893eb505d1d2a1', 'iqn.2010-06.com.purestorage:flasharray.55893eb505d1d2a1', 'iqn.2010-06.com.purestorage:flasharray.55893eb505d1d2a1', 'iqn.2010-06.com.purestorage:flasharray.55893eb505d1d2a1'], 'target_portals': ['10.224.18.46:3260', '10.224.18.47:3260', '10.224.18.48:3260', '10.224.18.49:3260'], 'wwn': '3624a93705842cfae35d7483200015fce', 'qos_specs': {'total_bytes_sec': '524288000', 'read_iops_sec': '12800', 'write_iops_sec': '6400'}, 'access_mode': 'rw', 'encrypted': False, 'cacheable': False}, {'type': 'block', 'scsi_wwn': '3624a93705842cfae35d7483200015fce', 'path': '/dev/dm-5', 'multipath_id': '3624a93705842cfae35d7483200015fce'}), 'kwargs': {'force': True, 'ignore_errors': True}}" trace_logging_wrapper /usr/lib/python3.6/site-packages/os_brick/utils.py:150 > 2023-03-10 16:42:42.616 2878341 DEBUG oslo_concurrency.lockutils [req-bdebfdef-daf3-4250-8594-9ed91adb7c00 f91779ad06064ebfbeeff54de535a6cd 8a676a415f9541c59705a373a36b0ec4 - - -] Lock "connect_volume" acquired by "os_brick.initiator.connectors.iscsi.ISCSIConnector.disconnect_volume" :: waited 0.001s inner /usr/lib/python3.6/site-packages/oslo_concurrency/lockutils.py:359 > 2023-03-10 16:42:42.616 2878341 DEBUG os_brick.initiator.connectors.iscsi [req-bdebfdef-daf3-4250-8594-9ed91adb7c00 f91779ad06064ebfbeeff54de535a6cd 8a676a415f9541c59705a373a36b0ec4 - - -] Getting connected devices for (ips,iqns,luns)=[('10.224.18.46:3260', 'iqn.2010-06.com.purestorage:flasharray.55893eb505d1d2a1', 1), ('10.224.18.47:3260', 'iqn.2010-06.com.purestorage:flasharray.55893eb505d1d2a1', 1), ('10.224.18.48:3260', 'iqn.2010-06.com.purestorage:flasharray.55893eb505d1d2a1', 1), ('10.224.18.49:3260', 'iqn.2010-06.com.purestorage:flasharray.55893eb505d1d2a1', 1)] _get_connection_devices /usr/lib/python3.6/site-packages/os_brick/initiator/connectors/iscsi.py:821 > 2023-03-10 16:42:42.618 2880468 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): iscsiadm -m node execute /usr/lib/python3.6/site-packages/oslo_concurrency/processutils.py:384 > 2023-03-10 16:42:42.631 2880468 DEBUG oslo_concurrency.processutils [-] CMD "iscsiadm -m node" returned: 0 in 0.013s execute /usr/lib/python3.6/site-packages/oslo_concurrency/processutils.py:423 > 2023-03-10 16:42:42.632 2880468 DEBUG oslo.privsep.daemon [-] privsep: reply[140628271231200]: (4, ('10.224.18.46:3260,4294967295 iqn.2010-06.com.purestorage:flasharray.55893eb505d1d2a1\n10.224.18.47:3260,4294967295 iqn.2010-06.com.purestorage:flasharray.55893eb505d1d2a1\n10.224.18.48:3260,4294967295 iqn.2010-06.com.purestorage:flasharray.55893eb505d1d2a1\n10.224.18.49:3260,4294967295 iqn.2010-06.com.purestorage:flasharray.55893eb505d1d2a1\n', '')) _call_back /usr/lib/python3.6/site-packages/oslo_privsep/daemon.py:511 > 2023-03-10 16:42:42.634 2880468 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): iscsiadm -m session execute /usr/lib/python3.6/site-packages/oslo_concurrency/processutils.py:384 > 2023-03-10 16:42:42.647 2880468 DEBUG oslo_concurrency.processutils [-] CMD "iscsiadm -m session" returned: 0 in 0.013s execute /usr/lib/python3.6/site-packages/oslo_concurrency/processutils.py:423 > 2023-03-10 16:42:42.647 2880468 DEBUG oslo.privsep.daemon [-] privsep: reply[140628271231200]: (4, ('tcp: [234] 10.224.18.46:3260,4013 iqn.2010-06.com.purestorage:flasharray.55893eb505d1d2a1 (non-flash)\ntcp: [235] 10.224.18.47:3260,4013 iqn.2010-06.com.purestorage:flasharray.55893eb505d1d2a1 (non-flash)\ntcp: [236] 10.224.18.49:3260,4013 iqn.2010-06.com.purestorage:flasharray.55893eb505d1d2a1 (non-flash)\ntcp: [237] 10.224.18.48:3260,4013 iqn.2010-06.com.purestorage:flasharray.55893eb505d1d2a1 (non-flash)\n', '')) _call_back /usr/lib/python3.6/site-packages/oslo_privsep/daemon.py:511 > 2023-03-10 16:42:42.649 2878341 DEBUG os_brick.initiator.connectors.iscsi [req-bdebfdef-daf3-4250-8594-9ed91adb7c00 f91779ad06064ebfbeeff54de535a6cd 8a676a415f9541c59705a373a36b0ec4 - - -] iscsiadm ('-m', 'session'): stdout=tcp: [234] 10.224.18.46:3260,4013 iqn.2010-06.com.purestorage:flasharray.55893eb505d1d2a1 (non-flash) > tcp: [235] 10.224.18.47:3260,4013 iqn.2010-06.com.purestorage:flasharray.55893eb505d1d2a1 (non-flash) > tcp: [236] 10.224.18.49:3260,4013 iqn.2010-06.com.purestorage:flasharray.55893eb505d1d2a1 (non-flash) > tcp: [237] 10.224.18.48:3260,4013 iqn.2010-06.com.purestorage:flasharray.55893eb505d1d2a1 (non-flash) > stderr= _run_iscsiadm_bare /usr/lib/python3.6/site-packages/os_brick/initiator/connectors/iscsi.py:1155 > 2023-03-10 16:42:42.649 2878341 DEBUG os_brick.initiator.connectors.iscsi [req-bdebfdef-daf3-4250-8594-9ed91adb7c00 f91779ad06064ebfbeeff54de535a6cd 8a676a415f9541c59705a373a36b0ec4 - - -] iscsi session list stdout=tcp: [234] 10.224.18.46:3260,4013 iqn.2010-06.com.purestorage:flasharray.55893eb505d1d2a1 (non-flash) > tcp: [235] 10.224.18.47:3260,4013 iqn.2010-06.com.purestorage:flasharray.55893eb505d1d2a1 (non-flash) > tcp: [236] 10.224.18.49:3260,4013 iqn.2010-06.com.purestorage:flasharray.55893eb505d1d2a1 (non-flash) > tcp: [237] 10.224.18.48:3260,4013 iqn.2010-06.com.purestorage:flasharray.55893eb505d1d2a1 (non-flash) > stderr= _run_iscsi_session /usr/lib/python3.6/site-packages/os_brick/initiator/connectors/iscsi.py:1144 > 2023-03-10 16:42:42.653 2878341 DEBUG os_brick.initiator.connectors.iscsi [req-bdebfdef-daf3-4250-8594-9ed91adb7c00 f91779ad06064ebfbeeff54de535a6cd 8a676a415f9541c59705a373a36b0ec4 - - -] Resulting device map defaultdict(<function ISCSIConnector._get_connection_devices.<locals>.<lambda> at 0x7fe6921bf268>, {('10.224.18.46:3260', 'iqn.2010-06.com.purestorage:flasharray.55893eb505d1d2a1'): ({'sdb'}, set()), ('10.224.18.47:3260', 'iqn.2010-06.com.purestorage:flasharray.55893eb505d1d2a1'): ({'sda'}, set()), ('10.224.18.48:3260', 'iqn.2010-06.com.purestorage:flasharray.55893eb505d1d2a1'): ({'sdc'}, set()), ('10.224.18.49:3260', 'iqn.2010-06.com.purestorage:flasharray.55893eb505d1d2a1'): ({'sdd'}, set())}) _get_connection_devices /usr/lib/python3.6/site-packages/os_brick/initiator/connectors/iscsi.py:853 > 2023-03-10 16:42:42.654 2878341 DEBUG os_brick.initiator.linuxscsi [req-bdebfdef-daf3-4250-8594-9ed91adb7c00 f91779ad06064ebfbeeff54de535a6cd 8a676a415f9541c59705a373a36b0ec4 - - -] Removing multipathed devices sdc, sdd, sda, sdb remove_connection /usr/lib/python3.6/site-packages/os_brick/initiator/linuxscsi.py:308 > 2023-03-10 16:42:42.655 2878341 DEBUG os_brick.initiator.linuxscsi [req-bdebfdef-daf3-4250-8594-9ed91adb7c00 f91779ad06064ebfbeeff54de535a6cd 8a676a415f9541c59705a373a36b0ec4 - - -] Flush multipath device 3624a93705842cfae35d7483200015fce flush_multipath_device /usr/lib/python3.6/site-packages/os_brick/initiator/linuxscsi.py:376 > 2023-03-10 16:42:42.657 2880468 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): multipath -f 3624a93705842cfae35d7483200015fce execute /usr/lib/python3.6/site-packages/oslo_concurrency/processutils.py:384 > 2023-03-10 16:42:46.675 2880468 DEBUG oslo_concurrency.processutils [-] CMD "multipath -f 3624a93705842cfae35d7483200015fce" returned: 1 in 4.019s execute /usr/lib/python3.6/site-packages/oslo_concurrency/processutils.py:423 > 2023-03-10 16:42:46.676 2880468 DEBUG oslo_concurrency.processutils [-] 'multipath -f 3624a93705842cfae35d7483200015fce' failed. Retrying. execute /usr/lib/python3.6/site-packages/oslo_concurrency/processutils.py:478 > 2023-03-10 16:42:46.676 2880468 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): multipath -f 3624a93705842cfae35d7483200015fce execute /usr/lib/python3.6/site-packages/oslo_concurrency/processutils.py:384 > 2023-03-10 16:42:46.685 2880468 DEBUG os_brick.privileged.rootwrap [-] Sleeping for 20 seconds on_execute /usr/lib/python3.6/site-packages/os_brick/privileged/rootwrap.py:106 > 2023-03-10 16:42:55.994 2878341 DEBUG oslo_service.periodic_task [req-b7d7b4ae-b092-40bf-9105-97bede752389 - - - - -] Running periodic task BackupManager.publish_service_capabilities run_periodic_tasks /usr/lib/python3.6/site-packages/oslo_service/periodic_task.py:211 > 2023-03-10 16:42:55.995 2878341 DEBUG cinder.manager [req-b7d7b4ae-b092-40bf-9105-97bede752389 - - - - -] Notifying Schedulers of capabilities ... _publish_service_capabilities /usr/lib/python3.6/site-packages/cinder/manager.py:197 > 2023-03-10 16:43:06.707 2880468 DEBUG oslo_concurrency.processutils [-] CMD "multipath -f 3624a93705842cfae35d7483200015fce" returned: 1 in 20.031s execute /usr/lib/python3.6/site-packages/oslo_concurrency/processutils.py:423 > 2023-03-10 16:43:06.707 2880468 DEBUG oslo_concurrency.processutils [-] 'multipath -f 3624a93705842cfae35d7483200015fce' failed. Retrying. execute /usr/lib/python3.6/site-packages/oslo_concurrency/processutils.py:478 > 2023-03-10 16:43:06.707 2880468 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): multipath -f 3624a93705842cfae35d7483200015fce execute /usr/lib/python3.6/site-packages/oslo_concurrency/processutils.py:384 > 2023-03-10 16:43:06.714 2880468 DEBUG os_brick.privileged.rootwrap [-] Sleeping for 40 seconds on_execute /usr/lib/python3.6/site-packages/os_brick/privileged/rootwrap.py:106 > 2023-03-10 16:43:46.753 2880468 DEBUG oslo_concurrency.processutils [-] CMD "multipath -f 3624a93705842cfae35d7483200015fce" returned: 1 in 40.046s execute /usr/lib/python3.6/site-packages/oslo_concurrency/processutils.py:423 > 2023-03-10 16:43:46.754 2880468 DEBUG oslo_concurrency.processutils [-] 'multipath -f 3624a93705842cfae35d7483200015fce' failed. Not Retrying. execute /usr/lib/python3.6/site-packages/oslo_concurrency/processutils.py:474 > 2023-03-10 16:43:46.754 2880468 DEBUG oslo.privsep.daemon [-] privsep: Exception during request[140628271231200]: Unexpected error while running command. > Command: multipath -f 3624a93705842cfae35d7483200015fce > Exit code: 1 > Stdout: '' > Stderr: 'Mar 10 16:43:06 | 3624a93705842cfae35d7483200015fce is not a multipath device\n' _process_cmd /usr/lib/python3.6/site-packages/oslo_privsep/daemon.py:490 > Traceback (most recent call last): > File "/usr/lib/python3.6/site-packages/oslo_privsep/daemon.py", line 485, in _process_cmd > ret = func(*f_args, **f_kwargs) > File "/usr/lib/python3.6/site-packages/oslo_privsep/priv_context.py", line 249, in _wrap > return func(*args, **kwargs) > File "/usr/lib/python3.6/site-packages/os_brick/privileged/rootwrap.py", line 197, in execute_root > return custom_execute(*cmd, shell=False, run_as_root=False, **kwargs) > File "/usr/lib/python3.6/site-packages/os_brick/privileged/rootwrap.py", line 146, in custom_execute > on_completion=on_completion, *cmd, **kwargs) > File "/usr/lib/python3.6/site-packages/oslo_concurrency/processutils.py", line 441, in execute > cmd=sanitized_cmd) > oslo_concurrency.processutils.ProcessExecutionError: Unexpected error while running command. > Command: multipath -f 3624a93705842cfae35d7483200015fce > Exit code: 1 > Stdout: '' > Stderr: 'Mar 10 16:43:06 | 3624a93705842cfae35d7483200015fce is not a multipath device\n' > 2023-03-10 16:43:46.757 2880468 DEBUG oslo.privsep.daemon [-] privsep: reply[140628271231200]: (5, 'oslo_concurrency.processutils.ProcessExecutionError', ('', 'Mar 10 16:43:06 | 3624a93705842cfae35d7483200015fce is not a multipath device\n', 1, 'multipath -f 3624a93705842cfae35d7483200015fce', None)) _call_back /usr/lib/python3.6/site-packages/oslo_privsep/daemon.py:511 > 2023-03-10 16:43:46.758 2878341 WARNING os_brick.exception [req-bdebfdef-daf3-4250-8594-9ed91adb7c00 f91779ad06064ebfbeeff54de535a6cd 8a676a415f9541c59705a373a36b0ec4 - - -] Flushing 3624a93705842cfae35d7483200015fce failed: oslo_concurrency.processutils.ProcessExecutionError: Unexpected error while running command. > 2023-03-10 16:43:46.761 2880468 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): multipathd del path /dev/sdc execute /usr/lib/python3.6/site-packages/oslo_concurrency/processutils.py:384 > 2023-03-10 16:43:46.772 2880468 DEBUG oslo_concurrency.processutils [-] CMD "multipathd del path /dev/sdc" returned: 0 in 0.011s execute /usr/lib/python3.6/site-packages/oslo_concurrency/processutils.py:423 > 2023-03-10 16:43:46.772 2880468 DEBUG oslo.privsep.daemon [-] privsep: reply[140628271231200]: (4, ('ok\n', '')) _call_back /usr/lib/python3.6/site-packages/oslo_privsep/daemon.py:511 > 2023-03-10 16:43:46.774 2878341 DEBUG os_brick.initiator.linuxscsi [req-bdebfdef-daf3-4250-8594-9ed91adb7c00 f91779ad06064ebfbeeff54de535a6cd 8a676a415f9541c59705a373a36b0ec4 - - -] Remove SCSI device /dev/sdc with /sys/block/sdc/device/delete remove_scsi_device /usr/lib/python3.6/site-packages/os_brick/initiator/linuxscsi.py:75 > 2023-03-10 16:43:46.774 2880468 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): tee -a /sys/block/sdc/device/delete execute /usr/lib/python3.6/site-packages/oslo_concurrency/processutils.py:384 > 2023-03-10 16:43:46.814 2880468 DEBUG oslo_concurrency.processutils [-] CMD "tee -a /sys/block/sdc/device/delete" returned: 0 in 0.040s execute /usr/lib/python3.6/site-packages/oslo_concurrency/processutils.py:423 > 2023-03-10 16:43:46.815 2880468 DEBUG oslo.privsep.daemon [-] privsep: reply[140628271231200]: (4, ('1', '')) _call_back /usr/lib/python3.6/site-packages/oslo_privsep/daemon.py:511 > 2023-03-10 16:43:46.817 2880468 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): multipathd del path /dev/sdd execute /usr/lib/python3.6/site-packages/oslo_concurrency/processutils.py:384 > 2023-03-10 16:43:46.828 2880468 DEBUG oslo_concurrency.processutils [-] CMD "multipathd del path /dev/sdd" returned: 0 in 0.011s execute /usr/lib/python3.6/site-packages/oslo_concurrency/processutils.py:423 > 2023-03-10 16:43:46.828 2880468 DEBUG oslo.privsep.daemon [-] privsep: reply[140628271231200]: (4, ('ok\n', '')) _call_back /usr/lib/python3.6/site-packages/oslo_privsep/daemon.py:511 > 2023-03-10 16:43:46.829 2878341 DEBUG os_brick.initiator.linuxscsi [req-bdebfdef-daf3-4250-8594-9ed91adb7c00 f91779ad06064ebfbeeff54de535a6cd 8a676a415f9541c59705a373a36b0ec4 - - -] Remove SCSI device /dev/sdd with /sys/block/sdd/device/delete remove_scsi_device /usr/lib/python3.6/site-packages/os_brick/initiator/linuxscsi.py:75 > 2023-03-10 16:43:46.831 2880468 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): tee -a /sys/block/sdd/device/delete execute /usr/lib/python3.6/site-packages/oslo_concurrency/processutils.py:384 > 2023-03-10 16:43:46.869 2880468 DEBUG oslo_concurrency.processutils [-] CMD "tee -a /sys/block/sdd/device/delete" returned: 0 in 0.039s execute /usr/lib/python3.6/site-packages/oslo_concurrency/processutils.py:423 > 2023-03-10 16:43:46.870 2880468 DEBUG oslo.privsep.daemon [-] privsep: reply[140628271231200]: (4, ('1', '')) _call_back /usr/lib/python3.6/site-packages/oslo_privsep/daemon.py:511 > 2023-03-10 16:43:46.872 2880468 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): multipathd del path /dev/sda execute /usr/lib/python3.6/site-packages/oslo_concurrency/processutils.py:384 > 2023-03-10 16:43:46.883 2880468 DEBUG oslo_concurrency.processutils [-] CMD "multipathd del path /dev/sda" returned: 0 in 0.011s execute /usr/lib/python3.6/site-packages/oslo_concurrency/processutils.py:423 > 2023-03-10 16:43:46.884 2880468 DEBUG oslo.privsep.daemon [-] privsep: reply[140628271231200]: (4, ('ok\n', '')) _call_back /usr/lib/python3.6/site-packages/oslo_privsep/daemon.py:511 > 2023-03-10 16:43:46.885 2878341 DEBUG os_brick.initiator.linuxscsi [req-bdebfdef-daf3-4250-8594-9ed91adb7c00 f91779ad06064ebfbeeff54de535a6cd 8a676a415f9541c59705a373a36b0ec4 - - -] Remove SCSI device /dev/sda with /sys/block/sda/device/delete remove_scsi_device /usr/lib/python3.6/site-packages/os_brick/initiator/linuxscsi.py:75 > 2023-03-10 16:43:46.887 2880468 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): tee -a /sys/block/sda/device/delete execute /usr/lib/python3.6/site-packages/oslo_concurrency/processutils.py:384 > 2023-03-10 16:43:46.929 2880468 DEBUG oslo_concurrency.processutils [-] CMD "tee -a /sys/block/sda/device/delete" returned: 0 in 0.042s execute /usr/lib/python3.6/site-packages/oslo_concurrency/processutils.py:423 > 2023-03-10 16:43:46.930 2880468 DEBUG oslo.privsep.daemon [-] privsep: reply[140628271231200]: (4, ('1', '')) _call_back /usr/lib/python3.6/site-packages/oslo_privsep/daemon.py:511 > 2023-03-10 16:43:46.931 2880468 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): multipathd del path /dev/sdb execute /usr/lib/python3.6/site-packages/oslo_concurrency/processutils.py:384 > 2023-03-10 16:43:46.942 2880468 DEBUG oslo_concurrency.processutils [-] CMD "multipathd del path /dev/sdb" returned: 0 in 0.011s execute /usr/lib/python3.6/site-packages/oslo_concurrency/processutils.py:423 > 2023-03-10 16:43:46.943 2880468 DEBUG oslo.privsep.daemon [-] privsep: reply[140628271231200]: (4, ('ok\n', '')) _call_back /usr/lib/python3.6/site-packages/oslo_privsep/daemon.py:511 > 2023-03-10 16:43:46.944 2878341 DEBUG os_brick.initiator.linuxscsi [req-bdebfdef-daf3-4250-8594-9ed91adb7c00 f91779ad06064ebfbeeff54de535a6cd 8a676a415f9541c59705a373a36b0ec4 - - -] Remove SCSI device /dev/sdb with /sys/block/sdb/device/delete remove_scsi_device /usr/lib/python3.6/site-packages/os_brick/initiator/linuxscsi.py:75 > 2023-03-10 16:43:46.945 2880468 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): tee -a /sys/block/sdb/device/delete execute /usr/lib/python3.6/site-packages/oslo_concurrency/processutils.py:384 > 2023-03-10 16:43:46.979 2880468 DEBUG oslo_concurrency.processutils [-] CMD "tee -a /sys/block/sdb/device/delete" returned: 0 in 0.034s execute /usr/lib/python3.6/site-packages/oslo_concurrency/processutils.py:423 > 2023-03-10 16:43:46.979 2880468 DEBUG oslo.privsep.daemon [-] privsep: reply[140628271231200]: (4, ('1', '')) _call_back /usr/lib/python3.6/site-packages/oslo_privsep/daemon.py:511 > 2023-03-10 16:43:46.980 2878341 DEBUG os_brick.initiator.linuxscsi [req-bdebfdef-daf3-4250-8594-9ed91adb7c00 f91779ad06064ebfbeeff54de535a6cd 8a676a415f9541c59705a373a36b0ec4 - - -] Checking to see if SCSI volumes sdc, sdd, sda, sdb have been removed. wait_for_volumes_removal /usr/lib/python3.6/site-packages/os_brick/initiator/linuxscsi.py:83 > 2023-03-10 16:43:46.981 2878341 DEBUG os_brick.initiator.linuxscsi [req-bdebfdef-daf3-4250-8594-9ed91adb7c00 f91779ad06064ebfbeeff54de535a6cd 8a676a415f9541c59705a373a36b0ec4 - - -] SCSI volumes sdc, sdd, sda, sdb have been removed. wait_for_volumes_removal /usr/lib/python3.6/site-packages/os_brick/initiator/linuxscsi.py:92 > 2023-03-10 16:43:46.982 2878341 DEBUG os_brick.initiator.connectors.iscsi [req-bdebfdef-daf3-4250-8594-9ed91adb7c00 f91779ad06064ebfbeeff54de535a6cd 8a676a415f9541c59705a373a36b0ec4 - - -] Disconnecting from: [('10.224.18.46:3260', 'iqn.2010-06.com.purestorage:flasharray.55893eb505d1d2a1'), ('10.224.18.47:3260', 'iqn.2010-06.com.purestorage:flasharray.55893eb505d1d2a1'), ('10.224.18.48:3260', 'iqn.2010-06.com.purestorage:flasharray.55893eb505d1d2a1'), ('10.224.18.49:3260', 'iqn.2010-06.com.purestorage:flasharray.55893eb505d1d2a1')] _disconnect_connection /usr/lib/python3.6/site-packages/os_brick/initiator/connectors/iscsi.py:1132 > 2023-03-10 16:43:46.983 2880468 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): iscsiadm -m node -T iqn.2010-06.com.purestorage:flasharray.55893eb505d1d2a1 -p 10.224.18.46:3260 --op update -n node.startup -v manual execute /usr/lib/python3.6/site-packages/oslo_concurrency/processutils.py:384 > 2023-03-10 16:43:46.996 2880468 DEBUG oslo_concurrency.processutils [-] CMD "iscsiadm -m node -T iqn.2010-06.com.purestorage:flasharray.55893eb505d1d2a1 -p 10.224.18.46:3260 --op update -n node.startup -v manual" returned: 0 in 0.013s execute /usr/lib/python3.6/site-packages/oslo_concurrency/processutils.py:423 > 2023-03-10 16:43:46.996 2880468 DEBUG oslo.privsep.daemon [-] privsep: reply[140628271231200]: (4, ('', '')) _call_back /usr/lib/python3.6/site-packages/oslo_privsep/daemon.py:511 > 2023-03-10 16:43:46.997 2878341 DEBUG os_brick.initiator.connectors.iscsi [req-bdebfdef-daf3-4250-8594-9ed91adb7c00 f91779ad06064ebfbeeff54de535a6cd 8a676a415f9541c59705a373a36b0ec4 - - -] iscsiadm ('--op', 'update', '-n', 'node.startup', '-v', 'manual'): stdout= stderr= _run_iscsiadm /usr/lib/python3.6/site-packages/os_brick/initiator/connectors/iscsi.py:1009 > 2023-03-10 16:43:46.998 2880468 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): iscsiadm -m node -T iqn.2010-06.com.purestorage:flasharray.55893eb505d1d2a1 -p 10.224.18.46:3260 --logout execute /usr/lib/python3.6/site-packages/oslo_concurrency/processutils.py:384 > 2023-03-10 16:43:47.026 2880468 DEBUG oslo_concurrency.processutils [-] CMD "iscsiadm -m node -T iqn.2010-06.com.purestorage:flasharray.55893eb505d1d2a1 -p 10.224.18.46:3260 --logout" returned: 0 in 0.028s execute /usr/lib/python3.6/site-packages/oslo_concurrency/processutils.py:423 > 2023-03-10 16:43:47.027 2880468 DEBUG oslo.privsep.daemon [-] privsep: reply[140628271231200]: (4, ('Logging out of session [sid: 234, target: iqn.2010-06.com.purestorage:flasharray.55893eb505d1d2a1, portal: 10.224.18.46,3260]\nLogout of [sid: 234, target: iqn.2010-06.com.purestorage:flasharray.55893eb505d1d2a1, portal: 10.224.18.46,3260] successful.\n', '')) _call_back /usr/lib/python3.6/site-packages/oslo_privsep/daemon.py:511 > 2023-03-10 16:43:47.028 2878341 DEBUG os_brick.initiator.connectors.iscsi [req-bdebfdef-daf3-4250-8594-9ed91adb7c00 f91779ad06064ebfbeeff54de535a6cd 8a676a415f9541c59705a373a36b0ec4 - - -] iscsiadm ('--logout',): stdout=Logging out of session [sid: 234, target: iqn.2010-06.com.purestorage:flasharray.55893eb505d1d2a1, portal: 10.224.18.46,3260] > Logout of [sid: 234, target: iqn.2010-06.com.purestorage:flasharray.55893eb505d1d2a1, portal: 10.224.18.46,3260] successful. > stderr= _run_iscsiadm /usr/lib/python3.6/site-packages/os_brick/initiator/connectors/iscsi.py:1009 > 2023-03-10 16:43:47.029 2880468 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): iscsiadm -m node -T iqn.2010-06.com.purestorage:flasharray.55893eb505d1d2a1 -p 10.224.18.46:3260 --op delete execute /usr/lib/python3.6/site-packages/oslo_concurrency/processutils.py:384 > 2023-03-10 16:43:47.041 2880468 DEBUG oslo_concurrency.processutils [-] CMD "iscsiadm -m node -T iqn.2010-06.com.purestorage:flasharray.55893eb505d1d2a1 -p 10.224.18.46:3260 --op delete" returned: 0 in 0.012s execute /usr/lib/python3.6/site-packages/oslo_concurrency/processutils.py:423 > 2023-03-10 16:43:47.041 2880468 DEBUG oslo.privsep.daemon [-] privsep: reply[140628271231200]: (4, ('', '')) _call_back /usr/lib/python3.6/site-packages/oslo_privsep/daemon.py:511 > 2023-03-10 16:43:47.042 2878341 DEBUG os_brick.initiator.connectors.iscsi [req-bdebfdef-daf3-4250-8594-9ed91adb7c00 f91779ad06064ebfbeeff54de535a6cd 8a676a415f9541c59705a373a36b0ec4 - - -] iscsiadm ('--op', 'delete'): stdout= stderr= _run_iscsiadm /usr/lib/python3.6/site-packages/os_brick/initiator/connectors/iscsi.py:1009 > 2023-03-10 16:43:47.043 2880468 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): iscsiadm -m node -T iqn.2010-06.com.purestorage:flasharray.55893eb505d1d2a1 -p 10.224.18.47:3260 --op update -n node.startup -v manual execute /usr/lib/python3.6/site-packages/oslo_concurrency/processutils.py:384 > 2023-03-10 16:43:47.055 2880468 DEBUG oslo_concurrency.processutils [-] CMD "iscsiadm -m node -T iqn.2010-06.com.purestorage:flasharray.55893eb505d1d2a1 -p 10.224.18.47:3260 --op update -n node.startup -v manual" returned: 0 in 0.012s execute /usr/lib/python3.6/site-packages/oslo_concurrency/processutils.py:423 > 2023-03-10 16:43:47.055 2880468 DEBUG oslo.privsep.daemon [-] privsep: reply[140628271231200]: (4, ('', '')) _call_back /usr/lib/python3.6/site-packages/oslo_privsep/daemon.py:511 > 2023-03-10 16:43:47.056 2878341 DEBUG os_brick.initiator.connectors.iscsi [req-bdebfdef-daf3-4250-8594-9ed91adb7c00 f91779ad06064ebfbeeff54de535a6cd 8a676a415f9541c59705a373a36b0ec4 - - -] iscsiadm ('--op', 'update', '-n', 'node.startup', '-v', 'manual'): stdout= stderr= _run_iscsiadm /usr/lib/python3.6/site-packages/os_brick/initiator/connectors/iscsi.py:1009 > 2023-03-10 16:43:47.057 2880468 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): iscsiadm -m node -T iqn.2010-06.com.purestorage:flasharray.55893eb505d1d2a1 -p 10.224.18.47:3260 --logout execute /usr/lib/python3.6/site-packages/oslo_concurrency/processutils.py:384 > 2023-03-10 16:43:47.084 2880468 DEBUG oslo_concurrency.processutils [-] CMD "iscsiadm -m node -T iqn.2010-06.com.purestorage:flasharray.55893eb505d1d2a1 -p 10.224.18.47:3260 --logout" returned: 0 in 0.026s execute /usr/lib/python3.6/site-packages/oslo_concurrency/processutils.py:423 > 2023-03-10 16:43:47.084 2880468 DEBUG oslo.privsep.daemon [-] privsep: reply[140628271231200]: (4, ('Logging out of session [sid: 235, target: iqn.2010-06.com.purestorage:flasharray.55893eb505d1d2a1, portal: 10.224.18.47,3260]\nLogout of [sid: 235, target: iqn.2010-06.com.purestorage:flasharray.55893eb505d1d2a1, portal: 10.224.18.47,3260] successful.\n', '')) _call_back /usr/lib/python3.6/site-packages/oslo_privsep/daemon.py:511 > 2023-03-10 16:43:47.086 2878341 DEBUG os_brick.initiator.connectors.iscsi [req-bdebfdef-daf3-4250-8594-9ed91adb7c00 f91779ad06064ebfbeeff54de535a6cd 8a676a415f9541c59705a373a36b0ec4 - - -] iscsiadm ('--logout',): stdout=Logging out of session [sid: 235, target: iqn.2010-06.com.purestorage:flasharray.55893eb505d1d2a1, portal: 10.224.18.47,3260] > Logout of [sid: 235, target: iqn.2010-06.com.purestorage:flasharray.55893eb505d1d2a1, portal: 10.224.18.47,3260] successful. > stderr= _run_iscsiadm /usr/lib/python3.6/site-packages/os_brick/initiator/connectors/iscsi.py:1009 > 2023-03-10 16:43:47.088 2880468 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): iscsiadm -m node -T iqn.2010-06.com.purestorage:flasharray.55893eb505d1d2a1 -p 10.224.18.47:3260 --op delete execute /usr/lib/python3.6/site-packages/oslo_concurrency/processutils.py:384 > 2023-03-10 16:43:47.101 2880468 DEBUG oslo_concurrency.processutils [-] CMD "iscsiadm -m node -T iqn.2010-06.com.purestorage:flasharray.55893eb505d1d2a1 -p 10.224.18.47:3260 --op delete" returned: 0 in 0.013s execute /usr/lib/python3.6/site-packages/oslo_concurrency/processutils.py:423 > 2023-03-10 16:43:47.102 2880468 DEBUG oslo.privsep.daemon [-] privsep: reply[140628271231200]: (4, ('', '')) _call_back /usr/lib/python3.6/site-packages/oslo_privsep/daemon.py:511 > 2023-03-10 16:43:47.103 2878341 DEBUG os_brick.initiator.connectors.iscsi [req-bdebfdef-daf3-4250-8594-9ed91adb7c00 f91779ad06064ebfbeeff54de535a6cd 8a676a415f9541c59705a373a36b0ec4 - - -] iscsiadm ('--op', 'delete'): stdout= stderr= _run_iscsiadm /usr/lib/python3.6/site-packages/os_brick/initiator/connectors/iscsi.py:1009 > 2023-03-10 16:43:47.104 2880468 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): iscsiadm -m node -T iqn.2010-06.com.purestorage:flasharray.55893eb505d1d2a1 -p 10.224.18.48:3260 --op update -n node.startup -v manual execute /usr/lib/python3.6/site-packages/oslo_concurrency/processutils.py:384 > 2023-03-10 16:43:47.114 2880468 DEBUG oslo_concurrency.processutils [-] CMD "iscsiadm -m node -T iqn.2010-06.com.purestorage:flasharray.55893eb505d1d2a1 -p 10.224.18.48:3260 --op update -n node.startup -v manual" returned: 0 in 0.010s execute /usr/lib/python3.6/site-packages/oslo_concurrency/processutils.py:423 > 2023-03-10 16:43:47.114 2880468 DEBUG oslo.privsep.daemon [-] privsep: reply[140628271231200]: (4, ('', '')) _call_back /usr/lib/python3.6/site-packages/oslo_privsep/daemon.py:511 > 2023-03-10 16:43:47.115 2878341 DEBUG os_brick.initiator.connectors.iscsi [req-bdebfdef-daf3-4250-8594-9ed91adb7c00 f91779ad06064ebfbeeff54de535a6cd 8a676a415f9541c59705a373a36b0ec4 - - -] iscsiadm ('--op', 'update', '-n', 'node.startup', '-v', 'manual'): stdout= stderr= _run_iscsiadm /usr/lib/python3.6/site-packages/os_brick/initiator/connectors/iscsi.py:1009 > 2023-03-10 16:43:47.116 2880468 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): iscsiadm -m node -T iqn.2010-06.com.purestorage:flasharray.55893eb505d1d2a1 -p 10.224.18.48:3260 --logout execute /usr/lib/python3.6/site-packages/oslo_concurrency/processutils.py:384 > 2023-03-10 16:43:47.140 2880468 DEBUG oslo_concurrency.processutils [-] CMD "iscsiadm -m node -T iqn.2010-06.com.purestorage:flasharray.55893eb505d1d2a1 -p 10.224.18.48:3260 --logout" returned: 0 in 0.024s execute /usr/lib/python3.6/site-packages/oslo_concurrency/processutils.py:423 > 2023-03-10 16:43:47.140 2880468 DEBUG oslo.privsep.daemon [-] privsep: reply[140628271231200]: (4, ('Logging out of session [sid: 237, target: iqn.2010-06.com.purestorage:flasharray.55893eb505d1d2a1, portal: 10.224.18.48,3260]\nLogout of [sid: 237, target: iqn.2010-06.com.purestorage:flasharray.55893eb505d1d2a1, portal: 10.224.18.48,3260] successful.\n', '')) _call_back /usr/lib/python3.6/site-packages/oslo_privsep/daemon.py:511 > 2023-03-10 16:43:47.141 2878341 DEBUG os_brick.initiator.connectors.iscsi [req-bdebfdef-daf3-4250-8594-9ed91adb7c00 f91779ad06064ebfbeeff54de535a6cd 8a676a415f9541c59705a373a36b0ec4 - - -] iscsiadm ('--logout',): stdout=Logging out of session [sid: 237, target: iqn.2010-06.com.purestorage:flasharray.55893eb505d1d2a1, portal: 10.224.18.48,3260] > Logout of [sid: 237, target: iqn.2010-06.com.purestorage:flasharray.55893eb505d1d2a1, portal: 10.224.18.48,3260] successful. > stderr= _run_iscsiadm /usr/lib/python3.6/site-packages/os_brick/initiator/connectors/iscsi.py:1009 > 2023-03-10 16:43:47.142 2880468 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): iscsiadm -m node -T iqn.2010-06.com.purestorage:flasharray.55893eb505d1d2a1 -p 10.224.18.48:3260 --op delete execute /usr/lib/python3.6/site-packages/oslo_concurrency/processutils.py:384 > 2023-03-10 16:43:47.153 2880468 DEBUG oslo_concurrency.processutils [-] CMD "iscsiadm -m node -T iqn.2010-06.com.purestorage:flasharray.55893eb505d1d2a1 -p 10.224.18.48:3260 --op delete" returned: 0 in 0.010s execute /usr/lib/python3.6/site-packages/oslo_concurrency/processutils.py:423 > 2023-03-10 16:43:47.153 2880468 DEBUG oslo.privsep.daemon [-] privsep: reply[140628271231200]: (4, ('', '')) _call_back /usr/lib/python3.6/site-packages/oslo_privsep/daemon.py:511 > 2023-03-10 16:43:47.154 2878341 DEBUG os_brick.initiator.connectors.iscsi [req-bdebfdef-daf3-4250-8594-9ed91adb7c00 f91779ad06064ebfbeeff54de535a6cd 8a676a415f9541c59705a373a36b0ec4 - - -] iscsiadm ('--op', 'delete'): stdout= stderr= _run_iscsiadm /usr/lib/python3.6/site-packages/os_brick/initiator/connectors/iscsi.py:1009 > 2023-03-10 16:43:47.155 2880468 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): iscsiadm -m node -T iqn.2010-06.com.purestorage:flasharray.55893eb505d1d2a1 -p 10.224.18.49:3260 --op update -n node.startup -v manual execute /usr/lib/python3.6/site-packages/oslo_concurrency/processutils.py:384 > 2023-03-10 16:43:47.165 2880468 DEBUG oslo_concurrency.processutils [-] CMD "iscsiadm -m node -T iqn.2010-06.com.purestorage:flasharray.55893eb505d1d2a1 -p 10.224.18.49:3260 --op update -n node.startup -v manual" returned: 0 in 0.010s execute /usr/lib/python3.6/site-packages/oslo_concurrency/processutils.py:423 > 2023-03-10 16:43:47.165 2880468 DEBUG oslo.privsep.daemon [-] privsep: reply[140628271231200]: (4, ('', '')) _call_back /usr/lib/python3.6/site-packages/oslo_privsep/daemon.py:511 > 2023-03-10 16:43:47.166 2878341 DEBUG os_brick.initiator.connectors.iscsi [req-bdebfdef-daf3-4250-8594-9ed91adb7c00 f91779ad06064ebfbeeff54de535a6cd 8a676a415f9541c59705a373a36b0ec4 - - -] iscsiadm ('--op', 'update', '-n', 'node.startup', '-v', 'manual'): stdout= stderr= _run_iscsiadm /usr/lib/python3.6/site-packages/os_brick/initiator/connectors/iscsi.py:1009 > 2023-03-10 16:43:47.167 2880468 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): iscsiadm -m node -T iqn.2010-06.com.purestorage:flasharray.55893eb505d1d2a1 -p 10.224.18.49:3260 --logout execute /usr/lib/python3.6/site-packages/oslo_concurrency/processutils.py:384 > 2023-03-10 16:43:47.189 2880468 DEBUG oslo_concurrency.processutils [-] CMD "iscsiadm -m node -T iqn.2010-06.com.purestorage:flasharray.55893eb505d1d2a1 -p 10.224.18.49:3260 --logout" returned: 0 in 0.022s execute /usr/lib/python3.6/site-packages/oslo_concurrency/processutils.py:423 > 2023-03-10 16:43:47.190 2880468 DEBUG oslo.privsep.daemon [-] privsep: reply[140628271231200]: (4, ('Logging out of session [sid: 236, target: iqn.2010-06.com.purestorage:flasharray.55893eb505d1d2a1, portal: 10.224.18.49,3260]\nLogout of [sid: 236, target: iqn.2010-06.com.purestorage:flasharray.55893eb505d1d2a1, portal: 10.224.18.49,3260] successful.\n', '')) _call_back /usr/lib/python3.6/site-packages/oslo_privsep/daemon.py:511 > 2023-03-10 16:43:47.191 2878341 DEBUG os_brick.initiator.connectors.iscsi [req-bdebfdef-daf3-4250-8594-9ed91adb7c00 f91779ad06064ebfbeeff54de535a6cd 8a676a415f9541c59705a373a36b0ec4 - - -] iscsiadm ('--logout',): stdout=Logging out of session [sid: 236, target: iqn.2010-06.com.purestorage:flasharray.55893eb505d1d2a1, portal: 10.224.18.49,3260] > Logout of [sid: 236, target: iqn.2010-06.com.purestorage:flasharray.55893eb505d1d2a1, portal: 10.224.18.49,3260] successful. > stderr= _run_iscsiadm /usr/lib/python3.6/site-packages/os_brick/initiator/connectors/iscsi.py:1009 > 2023-03-10 16:43:47.192 2880468 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): iscsiadm -m node -T iqn.2010-06.com.purestorage:flasharray.55893eb505d1d2a1 -p 10.224.18.49:3260 --op delete execute /usr/lib/python3.6/site-packages/oslo_concurrency/processutils.py:384 > 2023-03-10 16:43:47.202 2880468 DEBUG oslo_concurrency.processutils [-] CMD "iscsiadm -m node -T iqn.2010-06.com.purestorage:flasharray.55893eb505d1d2a1 -p 10.224.18.49:3260 --op delete" returned: 0 in 0.010s execute /usr/lib/python3.6/site-packages/oslo_concurrency/processutils.py:423 > 2023-03-10 16:43:47.202 2880468 DEBUG oslo.privsep.daemon [-] privsep: reply[140628271231200]: (4, ('', '')) _call_back /usr/lib/python3.6/site-packages/oslo_privsep/daemon.py:511 > 2023-03-10 16:43:47.203 2878341 DEBUG os_brick.initiator.connectors.iscsi [req-bdebfdef-daf3-4250-8594-9ed91adb7c00 f91779ad06064ebfbeeff54de535a6cd 8a676a415f9541c59705a373a36b0ec4 - - -] iscsiadm ('--op', 'delete'): stdout= stderr= _run_iscsiadm /usr/lib/python3.6/site-packages/os_brick/initiator/connectors/iscsi.py:1009 > 2023-03-10 16:43:47.204 2878341 DEBUG os_brick.initiator.connectors.iscsi [req-bdebfdef-daf3-4250-8594-9ed91adb7c00 f91779ad06064ebfbeeff54de535a6cd 8a676a415f9541c59705a373a36b0ec4 - - -] Flushing again multipath 3624a93705842cfae35d7483200015fce now that we removed the devices. _cleanup_connection /usr/lib/python3.6/site-packages/os_brick/initiator/connectors/iscsi.py:941 > 2023-03-10 16:43:47.204 2878341 DEBUG os_brick.initiator.linuxscsi [req-bdebfdef-daf3-4250-8594-9ed91adb7c00 f91779ad06064ebfbeeff54de535a6cd 8a676a415f9541c59705a373a36b0ec4 - - -] Flush multipath device 3624a93705842cfae35d7483200015fce flush_multipath_device /usr/lib/python3.6/site-packages/os_brick/initiator/linuxscsi.py:376 > 2023-03-10 16:43:47.205 2880468 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): multipath -f 3624a93705842cfae35d7483200015fce execute /usr/lib/python3.6/site-packages/oslo_concurrency/processutils.py:384 > 2023-03-10 16:43:47.215 2880468 DEBUG oslo_concurrency.processutils [-] CMD "multipath -f 3624a93705842cfae35d7483200015fce" returned: 1 in 0.010s execute /usr/lib/python3.6/site-packages/oslo_concurrency/processutils.py:423 > 2023-03-10 16:43:47.216 2880468 DEBUG oslo_concurrency.processutils [-] 'multipath -f 3624a93705842cfae35d7483200015fce' failed. Retrying. execute /usr/lib/python3.6/site-packages/oslo_concurrency/processutils.py:478 > 2023-03-10 16:43:47.216 2880468 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): multipath -f 3624a93705842cfae35d7483200015fce execute /usr/lib/python3.6/site-packages/oslo_concurrency/processutils.py:384 > 2023-03-10 16:43:47.221 2880468 DEBUG os_brick.privileged.rootwrap [-] Sleeping for 20 seconds on_execute /usr/lib/python3.6/site-packages/os_brick/privileged/rootwrap.py:106 > 2023-03-10 16:43:55.994 2878341 DEBUG oslo_service.periodic_task [req-b7d7b4ae-b092-40bf-9105-97bede752389 - - - - -] Running periodic task BackupManager.publish_service_capabilities run_periodic_tasks /usr/lib/python3.6/site-packages/oslo_service/periodic_task.py:211 > 2023-03-10 16:43:55.995 2878341 DEBUG cinder.manager [req-b7d7b4ae-b092-40bf-9105-97bede752389 - - - - -] Notifying Schedulers of capabilities ... _publish_service_capabilities /usr/lib/python3.6/site-packages/cinder/manager.py:197 > 2023-03-10 16:44:07.242 2880468 DEBUG oslo_concurrency.processutils [-] CMD "multipath -f 3624a93705842cfae35d7483200015fce" returned: 1 in 20.026s execute /usr/lib/python3.6/site-packages/oslo_concurrency/processutils.py:423 > 2023-03-10 16:44:07.242 2880468 DEBUG oslo_concurrency.processutils [-] 'multipath -f 3624a93705842cfae35d7483200015fce' failed. Retrying. execute /usr/lib/python3.6/site-packages/oslo_concurrency/processutils.py:478 > 2023-03-10 16:44:07.242 2880468 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): multipath -f 3624a93705842cfae35d7483200015fce execute /usr/lib/python3.6/site-packages/oslo_concurrency/processutils.py:384 > 2023-03-10 16:44:07.249 2880468 DEBUG os_brick.privileged.rootwrap [-] Sleeping for 40 seconds on_execute /usr/lib/python3.6/site-packages/os_brick/privileged/rootwrap.py:106 > 2023-03-10 16:44:47.287 2880468 DEBUG oslo_concurrency.processutils [-] CMD "multipath -f 3624a93705842cfae35d7483200015fce" returned: 1 in 40.045s execute /usr/lib/python3.6/site-packages/oslo_concurrency/processutils.py:423 > 2023-03-10 16:44:47.287 2880468 DEBUG oslo_concurrency.processutils [-] 'multipath -f 3624a93705842cfae35d7483200015fce' failed. Not Retrying. execute /usr/lib/python3.6/site-packages/oslo_concurrency/processutils.py:474 > 2023-03-10 16:44:47.288 2880468 DEBUG oslo.privsep.daemon [-] privsep: Exception during request[140628271231200]: Unexpected error while running command. > Command: multipath -f 3624a93705842cfae35d7483200015fce > Exit code: 1 > Stdout: '' > Stderr: 'Mar 10 16:44:07 | 3624a93705842cfae35d7483200015fce is not a multipath device\n' _process_cmd /usr/lib/python3.6/site-packages/oslo_privsep/daemon.py:490 > Traceback (most recent call last): > File "/usr/lib/python3.6/site-packages/oslo_privsep/daemon.py", line 485, in _process_cmd > ret = func(*f_args, **f_kwargs) > File "/usr/lib/python3.6/site-packages/oslo_privsep/priv_context.py", line 249, in _wrap > return func(*args, **kwargs) > File "/usr/lib/python3.6/site-packages/os_brick/privileged/rootwrap.py", line 197, in execute_root > return custom_execute(*cmd, shell=False, run_as_root=False, **kwargs) > File "/usr/lib/python3.6/site-packages/os_brick/privileged/rootwrap.py", line 146, in custom_execute > on_completion=on_completion, *cmd, **kwargs) > File "/usr/lib/python3.6/site-packages/oslo_concurrency/processutils.py", line 441, in execute > cmd=sanitized_cmd) > oslo_concurrency.processutils.ProcessExecutionError: Unexpected error while running command. > Command: multipath -f 3624a93705842cfae35d7483200015fce > Exit code: 1 > Stdout: '' > Stderr: 'Mar 10 16:44:07 | 3624a93705842cfae35d7483200015fce is not a multipath device\n' > 2023-03-10 16:44:47.288 2880468 DEBUG oslo.privsep.daemon [-] privsep: reply[140628271231200]: (5, 'oslo_concurrency.processutils.ProcessExecutionError', ('', 'Mar 10 16:44:07 | 3624a93705842cfae35d7483200015fce is not a multipath device\n', 1, 'multipath -f 3624a93705842cfae35d7483200015fce', None)) _call_back /usr/lib/python3.6/site-packages/oslo_privsep/daemon.py:511 > 2023-03-10 16:44:47.289 2878341 DEBUG oslo_concurrency.lockutils [req-bdebfdef-daf3-4250-8594-9ed91adb7c00 f91779ad06064ebfbeeff54de535a6cd 8a676a415f9541c59705a373a36b0ec4 - - -] Lock "connect_volume" released by "os_brick.initiator.connectors.iscsi.ISCSIConnector.disconnect_volume" :: held 124.674s inner /usr/lib/python3.6/site-packages/oslo_concurrency/lockutils.py:371 > 2023-03-10 16:44:47.289 2878341 DEBUG os_brick.initiator.connectors.iscsi [req-bdebfdef-daf3-4250-8594-9ed91adb7c00 f91779ad06064ebfbeeff54de535a6cd 8a676a415f9541c59705a373a36b0ec4 - - -] <== disconnect_volume: exception (124674ms) ProcessExecutionError('', 'Mar 10 16:44:07 | 3624a93705842cfae35d7483200015fce is not a multipath device\n', 1, 'multipath -f 3624a93705842cfae35d7483200015fce', None) trace_logging_wrapper /usr/lib/python3.6/site-packages/os_brick/utils.py:160 > 2023-03-10 16:44:47.314 2878341 ERROR oslo_messaging.rpc.server [req-bdebfdef-daf3-4250-8594-9ed91adb7c00 f91779ad06064ebfbeeff54de535a6cd 8a676a415f9541c59705a373a36b0ec4 - - -] Exception during message handling: oslo_concurrency.processutils.ProcessExecutionError: Unexpected error while running command. > Command: multipath -f 3624a93705842cfae35d7483200015fce > Exit code: 1 > Stdout: '' > Stderr: 'Mar 10 16:44:07 | 3624a93705842cfae35d7483200015fce is not a multipath device\n' > 2023-03-10 16:44:47.314 2878341 ERROR oslo_messaging.rpc.server Traceback (most recent call last): > 2023-03-10 16:44:47.314 2878341 ERROR oslo_messaging.rpc.server File "/usr/lib/python3.6/site-packages/oslo_messaging/rpc/server.py", line 165, in _process_incoming > 2023-03-10 16:44:47.314 2878341 ERROR oslo_messaging.rpc.server res = self.dispatcher.dispatch(message) > 2023-03-10 16:44:47.314 2878341 ERROR oslo_messaging.rpc.server File "/usr/lib/python3.6/site-packages/oslo_messaging/rpc/dispatcher.py", line 309, in dispatch > 2023-03-10 16:44:47.314 2878341 ERROR oslo_messaging.rpc.server return self._do_dispatch(endpoint, method, ctxt, args) > 2023-03-10 16:44:47.314 2878341 ERROR oslo_messaging.rpc.server File "/usr/lib/python3.6/site-packages/oslo_messaging/rpc/dispatcher.py", line 229, in _do_dispatch > 2023-03-10 16:44:47.314 2878341 ERROR oslo_messaging.rpc.server result = func(ctxt, **new_args) > 2023-03-10 16:44:47.314 2878341 ERROR oslo_messaging.rpc.server File "/usr/lib/python3.6/site-packages/cinder/utils.py", line 890, in wrapper > 2023-03-10 16:44:47.314 2878341 ERROR oslo_messaging.rpc.server return func(self, *args, **kwargs) > 2023-03-10 16:44:47.314 2878341 ERROR oslo_messaging.rpc.server File "/usr/lib/python3.6/site-packages/cinder/backup/manager.py", line 410, in create_backup > 2023-03-10 16:44:47.314 2878341 ERROR oslo_messaging.rpc.server volume_utils.update_backup_error(backup, str(err)) > 2023-03-10 16:44:47.314 2878341 ERROR oslo_messaging.rpc.server File "/usr/lib/python3.6/site-packages/oslo_utils/excutils.py", line 227, in __exit__ > 2023-03-10 16:44:47.314 2878341 ERROR oslo_messaging.rpc.server self.force_reraise() > 2023-03-10 16:44:47.314 2878341 ERROR oslo_messaging.rpc.server File "/usr/lib/python3.6/site-packages/oslo_utils/excutils.py", line 200, in force_reraise > 2023-03-10 16:44:47.314 2878341 ERROR oslo_messaging.rpc.server raise self.value > 2023-03-10 16:44:47.314 2878341 ERROR oslo_messaging.rpc.server File "/usr/lib/python3.6/site-packages/cinder/backup/manager.py", line 399, in create_backup > 2023-03-10 16:44:47.314 2878341 ERROR oslo_messaging.rpc.server updates = self._run_backup(context, backup, volume) > 2023-03-10 16:44:47.314 2878341 ERROR oslo_messaging.rpc.server File "/usr/lib/python3.6/site-packages/cinder/backup/manager.py", line 493, in _run_backup > 2023-03-10 16:44:47.314 2878341 ERROR oslo_messaging.rpc.server ignore_errors=True) > 2023-03-10 16:44:47.314 2878341 ERROR oslo_messaging.rpc.server File "/usr/lib/python3.6/site-packages/cinder/backup/manager.py", line 1066, in _detach_device > 2023-03-10 16:44:47.314 2878341 ERROR oslo_messaging.rpc.server force=force, ignore_errors=ignore_errors) > 2023-03-10 16:44:47.314 2878341 ERROR oslo_messaging.rpc.server File "/usr/lib/python3.6/site-packages/os_brick/utils.py", line 154, in trace_logging_wrapper > 2023-03-10 16:44:47.314 2878341 ERROR oslo_messaging.rpc.server result = f(*args, **kwargs) > 2023-03-10 16:44:47.314 2878341 ERROR oslo_messaging.rpc.server File "/usr/lib/python3.6/site-packages/oslo_concurrency/lockutils.py", line 360, in inner > 2023-03-10 16:44:47.314 2878341 ERROR oslo_messaging.rpc.server return f(*args, **kwargs) > 2023-03-10 16:44:47.314 2878341 ERROR oslo_messaging.rpc.server File "/usr/lib/python3.6/site-packages/os_brick/initiator/connectors/iscsi.py", line 880, in disconnect_volume > 2023-03-10 16:44:47.314 2878341 ERROR oslo_messaging.rpc.server is_disconnect_call=True) > 2023-03-10 16:44:47.314 2878341 ERROR oslo_messaging.rpc.server File "/usr/lib/python3.6/site-packages/os_brick/initiator/connectors/iscsi.py", line 942, in _cleanup_connection > 2023-03-10 16:44:47.314 2878341 ERROR oslo_messaging.rpc.server self._linuxscsi.flush_multipath_device(multipath_name) > 2023-03-10 16:44:47.314 2878341 ERROR oslo_messaging.rpc.server File "/usr/lib/python3.6/site-packages/os_brick/initiator/linuxscsi.py", line 382, in flush_multipath_device > 2023-03-10 16:44:47.314 2878341 ERROR oslo_messaging.rpc.server root_helper=self._root_helper) > 2023-03-10 16:44:47.314 2878341 ERROR oslo_messaging.rpc.server File "/usr/lib/python3.6/site-packages/os_brick/executor.py", line 52, in _execute > 2023-03-10 16:44:47.314 2878341 ERROR oslo_messaging.rpc.server result = self.__execute(*args, **kwargs) > 2023-03-10 16:44:47.314 2878341 ERROR oslo_messaging.rpc.server File "/usr/lib/python3.6/site-packages/os_brick/privileged/rootwrap.py", line 172, in execute > 2023-03-10 16:44:47.314 2878341 ERROR oslo_messaging.rpc.server return execute_root(*cmd, **kwargs) > 2023-03-10 16:44:47.314 2878341 ERROR oslo_messaging.rpc.server File "/usr/lib/python3.6/site-packages/oslo_privsep/priv_context.py", line 247, in _wrap > 2023-03-10 16:44:47.314 2878341 ERROR oslo_messaging.rpc.server return self.channel.remote_call(name, args, kwargs) > 2023-03-10 16:44:47.314 2878341 ERROR oslo_messaging.rpc.server File "/usr/lib/python3.6/site-packages/oslo_privsep/daemon.py", line 224, in remote_call > 2023-03-10 16:44:47.314 2878341 ERROR oslo_messaging.rpc.server raise exc_type(*result[2]) > 2023-03-10 16:44:47.314 2878341 ERROR oslo_messaging.rpc.server oslo_concurrency.processutils.ProcessExecutionError: Unexpected error while running command. > 2023-03-10 16:44:47.314 2878341 ERROR oslo_messaging.rpc.server Command: multipath -f 3624a93705842cfae35d7483200015fce > 2023-03-10 16:44:47.314 2878341 ERROR oslo_messaging.rpc.server Exit code: 1 > 2023-03-10 16:44:47.314 2878341 ERROR oslo_messaging.rpc.server Stdout: '' > 2023-03-10 16:44:47.314 2878341 ERROR oslo_messaging.rpc.server Stderr: 'Mar 10 16:44:07 | 3624a93705842cfae35d7483200015fce is not a multipath device\n' > 2023-03-10 16:44:47.314 2878341 ERROR oslo_messaging.rpc.server

3 4