January 2023 - openstack-discuss - lists.openstack.org

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

23 Apr '25

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

3 2

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

22 Apr '25

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

2 1

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

24 Dec '24

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

4 4

Kolla 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

[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

[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

[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

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][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

[Openstack] Lack of Balance solution such as Watcher.
by Nguyễn Hữu Khôi 16 Mar '23

16 Mar '23

I am building a private cloud.Everything is ok. But I cannot find a way to balance vm when It have heavy load which cause impact other vm on the compute node. I found solutions such as Watcher and Leveller. But they need to be done manually. Watcher is not good because It need cpu metric such as cpu load in Ceilometer which is removed so we cannot use it. Leveller is good, but It is obsolete. Nguyen Huu Khoi

4 7

live resize
by Parsa Aminian 15 Mar '23

15 Mar '23

hello on openstack with ceph backend is it possible to live resize instances ? I want to change flavor without any down time .

5 6

[security-sig] Polls in preparation to revive our meetings
by Jeremy Stanley 01 Mar '23

01 Mar '23

As discussed at the last PTG, the present meeting time (15:00 UTC on the first Thursday of each month) is inconvenient for some attendees, and that combined with year-end holidays and general busy weeks recently have led to skipping them entirely. In order to start narrowing down the potential meeting schedule, I have two initial polls. The first is to determine what frequency we should meet. If you have an opinion on that, please fill out this poll before Thursday, February 9 (two weeks from today): https://framadate.org/wz7GioqmgyWeILkr The second poll is to hopefully determine what day of the week is optimal for potential attendees. If you have a preference for which day of the week to meet, please complete this one by the same date as the first: https://framadate.org/CyxKgZPT8PWxcCnJ Once I can analyze the results, I'll put together a more specific poll for choosing a time of day as well as possibly choosing which week(s) of the month (if we don't settle on weekly frequency). In the meantime, let's plan to hold February's meeting on Thursday the 2nd at 15:00-16:00 UTC as usual[*] for anyone who is able to attend, and I'll get an agenda together in preparation for that. [*] https://meetings.opendev.org/#OpenStack_Security_SIG_meeting -- Jeremy Stanley

1 1

[puppet] Retiring untested and unmaintained modules (murano, rally and tacker)
by Takashi Kajinami 27 Feb '23

27 Feb '23

Hello, In Puppet OpenStack projects we have multiple modules to support multiple OpenStack components. However unfortunately some of these have not been attracting enough interest from developers and have been unmaintained. During the past few cycles we retired a few incomplete modules but I'm wondering if we can retire a few unmaintained modules now, to reduce our maintenance/release effort. I checked the modules we have currently, and I think the following three can be first candidates. - puppet-murano - puppet-rally - puppet-tacker We haven't seen any feedback from users about these modules for a long time. Most of the changes for the past 2~3 years are proposed by me but I am not really using these components. These modules do not have proper test coverage and it's quite difficult for us to catch any breakage and honestly I'm not quite sure these modules can work properly with the latest code. Actually we've often caught up with the latest requirements several years after the change was made in the software side, and I'm afraid these are not well-maintained. eg. - support for tacker-conductor was added 4 years after the service was added - we didn't noticed that the openstack plugin was split out from the core rally package for several years If anybody has concerns with retiring these modules, then please let us know. If we don't hear any objections for a while, then I'll start proposing changes for project retirement. Thank you, Takashi -- ---------- Takashi Kajinami

4 9

[kolla-ansible] [yoga] [magnum] [k8s] cannot attach persistent volume to pod
by Stuart Whitman 24 Feb '23

24 Feb '23

Hello, When I try to attach a persistent cinder volume to a pod, I get FailedMount and FailedAttachVolume timeout events. I also get these errors in the log of the csi-cinder-controllerplugin-0 pod: E1020 13:38:41.747511 1 reflector.go:126] k8s.io/client-go/informers/factory.go:133: Failed to list *v1beta1.VolumeAttachment: the server could not find the requested resource E1020 13:38:41.748187 1 reflector.go:126] k8s.io/client-go/informers/factory.go:133: Failed to list *v1beta1.CSINode: the server could not find the requested resource I fixed a CrashLoopBackoff error with the csi-snapshotter container in the csi-cinder-controllerplugin-0 pod by providing the label "csi_snapshotter_tag=v4.0.0" when I created the cluster template. I found that suggestion in an issue on the GitHub cloud-provider-openstack project. I'm not finding any help with this error on Google. Thanks, -Stu _____________________________________ The information contained in this e-mail and any attachments from Group W may contain confidential and/or proprietary information and is intended only for the named recipient to whom it was originally addressed. If you are not the intended recipient, be aware that any disclosure, distribution, or copying of this e-mail or its attachments is strictly prohibited. If you have received this e-mail in error, please notify the sender immediately of that fact by return e-mail and permanently delete the e-mail and any attachments to it.

3 5

[Magnum]enable cluster user trust
by Nguyễn Hữu Khôi 16 Feb '23

16 Feb '23

Hello guys. I am going to use Magnum for production but I see that https://nvd.nist.gov/vuln/detail/CVE-2016-7404 if I want to use cinder for k8s cluster. Is there any way to fix or minimize this problem? Thanks. Nguyen Huu Khoi

2 3

[heat][release] Proposing to EOL Train, Ussuri and Victoria
by Brendan Shephard 10 Feb '23

10 Feb '23

Hi folks, We’re looking to move Train, Ussuri and Victoria branches to EOL for Heat projects. Just reaching out to see if there are any objections, if I don’t hear anything back I’ll move forward with that this week. Cheers, Brendan Shephard Senior Software Engineer Red Hat Australia

2 3

[magnum] Other Distro for k8s
by Nguyễn Hữu Khôi 10 Feb '23

10 Feb '23

Hello guys. I know that Magnum is using Fedora Coreos for k8s. Why don't we use a long-term distro such as Ubuntu for this project? I will be more stable. and this project seems obsolete with the old version for k8s. Nguyen Huu Khoi

3 6

[charms] Team Delegation proposal
by Chris MacNaughton 08 Feb '23

08 Feb '23

Hello All, <tl;dr> I would like to propose some new ACLs in Gerrit for the openstack-charms project: - openstack-core-charms - ceph-charms - network-charms - stable-maintenance </tl;dr> With an increasing focus split among the openstack-charmers team, I'm observing that people are focused on more specific subsets of the charms, and would like to propose that new ACLs are created to allow us to recognize that officially. I've chosen the breakdown above as it aligns neatly with where the focus lines are at this point, letting developers work on their specific focus areas. This proposal would not reduce permissions for anybody who is currently a core on the openstack-charms project and, in fact, future subteam core members could aspire to full openstack-charmers core as well. Ideally, this approach will let us escalate developers to "core" developers for the subteam(s) where they have demonstrated the expertise we expect in a core-charmer. It also allows a more gradual escalation to being a core in the openstack-charms project, making it a progression rather than a single destination. As a related addition, I'm appending to this proposal the creation of a stable-maintenance ACL which would allow members to manage backports without a full core-charmer grant. --- Chris MacNaughton

5 7

[ALL] Why we dont have an official forum?
by Nguyễn Hữu Khôi 08 Feb '23

08 Feb '23

Hello guys. Openstack is a very interesting project, many questions from users will make it grow more and more but I see that people, including me, still ask the same question. It is hard to sort or find knowledge by this way. If we hope this project spreads for people, we need a new way to share knowledge and skills, we are in the modern world but the way to access and exchange information in this project is too obsolete. This is a wall to slow down this project. Nguyen Huu Khoi

13 19

[qa][gate][stable] stable/wallaby gate is broken
by Ghanshyam Mann 07 Feb '23

07 Feb '23

Hello Everyone, You might know stable/wallaby which is in the EM phase is broken because of the Tempest master incompatibility. As this is in EM phase, Tempest master does support it and the fix is to use the old compatible Tempest. I have pushed the fix on devstack to pin Tempest 29.0.0 to test stable/wallaby, do not recheck until that is merged: - https://review.opendev.org/c/openstack/devstack/+/871782 This depends on a few other fixes which are in the gate. Like the Tempest pin, we need to pin tempest plugins also on stable/wallaby. I have pushed a few projects fix for that, please review those if the devstack patch alone does not fix the gate - https://review.opendev.org/q/topic:wallaby-pin-tempest+status:open - https://review.opendev.org/q/topic:bug%252F2003993 -gmann

2 4

[OSSA-2023-002] Cinder, Glance, Nova: Arbitrary file access through custom VMDK flat descriptor (CVE-2022-47951)
by Jeremy Stanley 07 Feb '23

07 Feb '23

======================================================================== OSSA-2023-002: Arbitrary file access through custom VMDK flat descriptor ======================================================================== :Date: January 24, 2023 :CVE: CVE-2022-47951 Affects ~~~~~~~ - Cinder, glance, nova: Cinder <19.1.2, >=20.0.0 <20.0.2, ==21.0.0; Glance <23.0.1, >=24.0.0 <24.1.1, ==25.0.0; Nova <24.1.2, >=25.0.0 <25.0.2, ==26.0.0 Description ~~~~~~~~~~~ Guillaume Espanel, Pierre Libeau, Arnaud Morin and Damien Rannou (OVH) reported a vulnerability in VMDK image processing for Cinder, Glance and Nova. By supplying a specially created VMDK flat image which references a specific backing file path, an authenticated user may convince systems to return a copy of that file's contents from the server resulting in unauthorized access to potentially sensitive data. All Cinder deployments are affected; only Glance deployments with image conversion enabled are affected; all Nova deployments are affected. Patches ~~~~~~~ - https://review.opendev.org/871631 (Train(cinder)) - https://review.opendev.org/871630 (Train(glance)) - https://review.opendev.org/871629 (Ussuri(cinder)) - https://review.opendev.org/871626 (Ussuri(glance)) - https://review.opendev.org/871628 (Victoria(cinder)) - https://review.opendev.org/871623 (Victoria(glance)) - https://review.opendev.org/871627 (Wallaby(cinder)) - https://review.opendev.org/871621 (Wallaby(glance)) - https://review.opendev.org/871625 (Xena(cinder)) - https://review.opendev.org/871619 (Xena(glance)) - https://review.opendev.org/871622 (Xena(nova)) - https://review.opendev.org/871620 (Yoga(cinder)) - https://review.opendev.org/871617 (Yoga(glance)) - https://review.opendev.org/871624 (Yoga(nova)) - https://review.opendev.org/871618 (Zed(cinder)) - https://review.opendev.org/871614 (Zed(glance)) - https://review.opendev.org/871616 (Zed(nova)) - https://review.opendev.org/871615 (2023.1/antelope(cinder)) - https://review.opendev.org/871613 (2023.1/antelope(glance)) - https://review.opendev.org/871612 (2023.1/antelope(nova)) Credits ~~~~~~~ - Guillaume Espanel from OVH (CVE-2022-47951) - Pierre Libeau from OVH (CVE-2022-47951) - Arnaud Morin from OVH (CVE-2022-47951) - Damien Rannou from OVH (CVE-2022-47951) References ~~~~~~~~~~ - https://launchpad.net/bugs/1996188 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-47951 Notes ~~~~~ - The stable/wallaby, stable/victoria, stable/ussuri, and stable/train branches are under extended maintenance and will receive no new point releases, but patches for them are provided as a courtesy where possible. -- Jeremy Stanley OpenStack Vulnerability Management Team

3 3

[neutron] Bumping of requirements on RDO before bumping them on Neutron
by Elvira Garcia Ruiz 04 Feb '23

04 Feb '23

Hi Neutrinos! RDO folks proposed that, in order to be able to correctly build CI gates for testing, it would be nice if we tried to update the neutron-distgit requirement file when we want to update the minimal version of a dependency before merging it on our repository. This would allow them to realize whether they need or not to update any Fedora package. In order to do that, we just need to send a small commit to their repository [0]. You can use your GitHub account for the login. Here you can find an example for pyroute2 in RDO [1] and the respective pyroute2 bump in Neutron [2]. Regards! Elvira García (elvira) [0] https://review.rdoproject.org/r/openstack/neutron-distgit [1] https://review.rdoproject.org/r/c/openstack/neutron-distgit/+/46809 [2] https://review.opendev.org/c/openstack/neutron/+/870963

7 9

[ironic] [baremetal] [ops] Mark the date: new bare metal SIG meetup on Feb 8th
by Dmitry Tantsur 04 Feb '23

04 Feb '23

Hi stackers! The bare metal SIG will start with a new format of meetings this year: quarterly and with more content. Please read the announcement: https://ironicbaremetal.org/blog/baremetal-sig-2023q1/ Let me know if you have any questions. Otherwise, we'll be looking forward to talking to you. Zoom link will be posted later. Dmitry P.S. Please help to spread the word! -- Red Hat GmbH <https://www.redhat.com/de/global/dach>, Registered seat: Werner von Siemens Ring 12, D-85630 Grasbrunn, Germany Commercial register: Amtsgericht Muenchen/Munich, HRB 153243,Managing Directors: Ryan Barnhart, Charles Cachera, Michael O'Neill, Amy Ross

2 1

[all][stable][ptl] Propose to EOL Rocky series
by Elõd Illés 03 Feb '23

03 Feb '23

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…

6 7

[kolla] local registry setup issue
by Satish Patel 02 Feb '23

02 Feb '23

Folks, I have set up a local registry using the following method as per official doc. docker run -d \ --network host \ --name registry \ --restart=always \ -e REGISTRY_HTTP_ADDR=0.0.0.0:4000 \ -v registry:/var/lib/registry \ registry:2 After that I ran the following command to import all images to the local registry. docker images | grep kolla | grep -v local | awk '{print $1,$2}' | while read -r image tag; do new_image_name=${image#"quay.io/"} docker tag ${image}:${tag} "localhost:4000"/${new_image_name}:${tag} docker push localhost:4000/${new_image_name}:${tag} done Now i can see images in local registry using docker images command (venv-kolla) root@kolla-infra-1:/etc/kolla# docker images | grep localhost localhost:4000/openstack.kolla/ubuntu-source-nova-novncproxy yoga 01dc100dc65a 2 days ago 1.2GB localhost:4000/openstack.kolla/ubuntu-source-horizon yoga a016e1f5b9af 2 days ago 1.1GB localhost:4000/openstack.kolla/ubuntu-source-nova-conductor yoga 381a64a368bd 2 days ago 1.11GB localhost:4000/openstack.kolla/ubuntu-source-nova-api yoga f90a15a09142 2 days ago 1.11GB .... .... I have added it in global.yml docker_registry: 10.73.0.181:4000 docker_registry_insecure: yes Now when i am trying to add compute nodes then I get a registry error like the following. Not sure why its trying to use https://10.73.0.181:4000/v2 instead of http;// TASK [common : include_tasks] **************************************************************************************************************************************************** included: /root/venv-kolla/share/kolla-ansible/ansible/roles/common/tasks/pull.yml for kolla-comp-2 TASK [service-images-pull : common | Pull images] ******************************************************************************************************************************** FAILED - RETRYING: common | Pull images (3 retries left). FAILED - RETRYING: common | Pull images (2 retries left). FAILED - RETRYING: common | Pull images (1 retries left). failed: [kolla-comp-2] (item=fluentd) => {"ansible_loop_var": "item", "attempts": 3, "changed": true, "item": {"key": "fluentd", "value": {"container_name": "fluentd", "dimensions": {}, "enabled": true, "environment": {"KOLLA_CONFIG_STRATEGY": "COPY_ALWAYS"}, "group": "fluentd", "image": " 10.73.0.181:4000/openstack.kolla/ubuntu-source-fluentd:yoga", "volumes": ["/etc/kolla/fluentd/:/var/lib/kolla/config_files/:ro", "/etc/localtime:/etc/localtime:ro", "/etc/timezone:/etc/timezone:ro", "kolla_logs:/var/log/kolla/", "fluentd_data:/var/lib/fluentd/data/"]}}, "msg": "'Traceback (most recent call last):\\n File \"/usr/lib/python3/dist-packages/docker/api/client.py\", line 261, in _raise_for_status\\n response.raise_for_status()\\n File \"/usr/lib/python3/dist-packages/requests/models.py\", line 940, in raise_for_status\\n raise HTTPError(http_error_msg, response=self)\\nrequests.exceptions.HTTPError: 500 Server Error: Internal Server Error for url: http+docker://localhost/v1.41/images/create?tag=yoga&fromImage=10.73.0.181%3A4000%2Fopenstack.kolla%2Fubuntu-source-fluentd\\n\\nDuring handling of the above exception, another exception occurred:\\n\\nTraceback (most recent call last):\\n File \"/tmp/ansible_kolla_docker_payload_6o9nw9xd/ansible_kolla_docker_payload.zip/ansible/modules/kolla_docker.py\", line 381, in main\\n File \"/tmp/ansible_kolla_docker_payload_6o9nw9xd/ansible_kolla_docker_payload.zip/ansible/module_utils/kolla_docker_worker.py\", line 450, in pull_image\\n json.loads(line.strip().decode(\\'utf-8\\')) for line in self.dc.pull(\\n File \"/usr/lib/python3/dist-packages/docker/api/image.py\", line 415, in pull\\n self._raise_for_status(response)\\n File \"/usr/lib/python3/dist-packages/docker/api/client.py\", line 263, in _raise_for_status\\n raise create_api_error_from_http_exception(e)\\n File \"/usr/lib/python3/dist-packages/docker/errors.py\", line 31, in create_api_error_from_http_exception\\n raise cls(e, response=response, explanation=explanation)\\ndocker.errors.APIError: 500 Server Error: Internal Server Error (\"Get \"https://10.73.0.181:4000/v2/\": http: server gave HTTP response to HTTPS client\")\\n'"} FAILED - RETRYING: common | Pull images (3 retries left).

3 5

Reddit query for openstack magnum for enterprise core component maker
by Gajendra D Ambi 02 Feb '23

02 Feb '23

https://www.reddit.com/r/openstack/comments/10hu68s/container_orchestrator_… . Hi team, request anyone of you from this project to please help us out. We also mean to contribute to the project because we know that we will need to add a lot more features to it that what api endpoints are already providing to us. When we do, it will all be contributed to the project after it is being tested for months in production. I am leaning towards openstack magnum and I do not have a lot of time to convince others of the same. Thanks and Regards, https://ambig.one/2/

2 3

[all][tc] Technical Committee next weekly meeting on 2023 Feb 1 at 1600 UTC
by Ghanshyam Mann 01 Feb '23

01 Feb '23

Hello Everyone, The technical Committee's next weekly meeting is scheduled for 2023 Feb 1, at 1600 UTC. If you would like to add topics for discussion, please add them to the below wiki page by Tuesday, Jan 31 at 2100 UTC. https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting -gmann

1 1

[ZED][Kyestone][Application_credentials] Conflict occurred attempting to store application_credential - Duplicate entry found
by Vish Mudemela 01 Feb '23

01 Feb '23

Hello all, 1. I have created application credentials with the name "sa_capacity" as role - reader. 2. I have deleted application credentials , I wanted to add some access rules. 3. verified by command - *openstack application credential show sa_capacity* got output as *"**No application credential with a name or ID of 'sa_capacity' exists."* 4.verified using *openstack application credential list *, confirmed there is no application credential with name "sa_capacity" 5. no application creds on my username too *"openstack application credential list --user <<username>> --user-domain <<domain_name>>"* 6. Trying to recreate application credentials with the *same name(sa_capacity) *with a role reader and added some access rules. I got an error* "Conflict occurred attempting to store application_credential - Duplicate entry found with name sa_capacity. (HTTP 409) (Request-ID: req-0e58b336-a59b-490d-b946-30c28ca44777)"* *7.* I even tried with a different name that's never been configured* "sa_capcity_1"* but it says *Conflict occurred attempting to store application_credential - Duplicate entry found with name sa_capacity_1. (HTTP 409)* Any idea what's wrong here? Below are the keystone logs. *keystone logs:* 2023-01-31 21:51:07.193 670 ERROR keystone.server.flask.application File "/var/lib/kolla/venv/lib/python3.10/site-packages/keystone/common/manager.py", line 115, in wrapped 2023-01-31 21:51:07.193 670 ERROR keystone.server.flask.application __ret_val = __f(*args, **kwargs) 2023-01-31 21:51:07.193 670 ERROR keystone.server.flask.application File "/var/lib/kolla/venv/lib/python3.10/site-packages/keystone/application_credential/core.py", line 137, in create_application_credential 2023-01-31 21:51:07.193 670 ERROR keystone.server.flask.application ref = self.driver.create_application_credential( 2023-01-31 21:51:07.193 670 ERROR keystone.server.flask.application File "/var/lib/kolla/venv/lib/python3.10/site-packages/keystone/common/sql/core.py", line 563, in wrapper 2023-01-31 21:51:07.193 670 ERROR keystone.server.flask.application raise exception.Conflict(type=conflict_type, 2023-01-31 21:51:07.193 670 ERROR keystone.server.flask.application keystone.exception.Conflict: Conflict occurred attempting to store application_credential - Duplicate entry found with name sa_capacity. 2023-01-31 21:51:07.193 670 ERROR keystone.server.flask.application 2023-01-31 21:53:10.461 669 INFO keystone.token.token_formatters [None req-75dc9499-18aa-4f55-8a63-633b9ef316c5 910a75448974f088b01f96e09db0667737b84a5663dbaa2a142c4648187f40de e68db2302b1d44beb5d62c6a6268ab26 - - e025affd9237457a9d7036fb10a9b626 e025affd9237457a9d7036fb10a9b626] Fernet token created with length of 268 characters, which exceeds 255 characters 2023-01-31 21:53:14.131 673 INFO keystone.token.token_formatters [None req-66aa818c-754e-46bf-a393-6115eb14b2d3 910a75448974f088b01f96e09db0667737b84a5663dbaa2a142c4648187f40de e68db2302b1d44beb5d62c6a6268ab26 - - e025affd9237457a9d7036fb10a9b626 e025affd9237457a9d7036fb10a9b626] Fernet token created with length of 268 characters, which exceeds 255 characters 2023-01-31 21:53:55.977 671 WARNING py.warnings [None req-0e58b336-a59b-490d-b946-30c28ca44777 fba6720038a31a4c1cf2e001022466a504d6d78ec9b10ac1a8adbfd7b8902fdc e68db2302b1d44beb5d62c6a6268ab26 - - e025affd9237457a9d7036fb10a9b626 e025affd9237457a9d7036fb10a9b626] /var/lib/kolla/venv/lib/python3.10/site-packages/keystone/application_credential/backends/sql.py:144: SAWarning: New instance <ApplicationCredentialAccessRuleModel at 0x7f714f74c910> with identity key (<class 'keystone.application_credential.backends.sql.ApplicationCredentialAccessRuleModel'>, (96, 249), None) conflicts with persistent instance <ApplicationCredentialAccessRuleModel at 0x7f714f74ec80> external_id=access_rule['id']).first() 2023-01-31 21:53:55.981 671 ERROR keystone.server.flask.application [None req-0e58b336-a59b-490d-b946-30c28ca44777 fba6720038a31a4c1cf2e001022466a504d6d78ec9b10ac1a8adbfd7b8902fdc e68db2302b1d44beb5d62c6a6268ab26 - - e025affd9237457a9d7036fb10a9b626 e025affd9237457a9d7036fb10a9b626] Conflict occurred attempting to store application_credential - Duplicate entry found with name sa_capacity.: keystone.exception.Conflict: Conflict occurred attempting to store application_credential - Duplicate entry found with name sa_capacity. 2023-01-31 21:53:55.981 671 ERROR keystone.server.flask.application Traceback (most recent call last): 2023-01-31 21:53:55.981 671 ERROR keystone.server.flask.application File "/var/lib/kolla/venv/lib/python3.10/site-packages/sqlalchemy/engine/base.py", line 1900, in _execute_context 2023-01-31 21:53:55.981 671 ERROR keystone.server.flask.application self.dialect.do_execute( 2023-01-31 21:53:55.981 671 ERROR keystone.server.flask.application File "/var/lib/kolla/venv/lib/python3.10/site-packages/sqlalchemy/engine/default.py", line 732, in do_execute 2023-01-31 21:53:55.981 671 ERROR keystone.server.flask.application cursor.execute(statement, parameters) 2023-01-31 21:53:55.981 671 ERROR keystone.server.flask.application File "/var/lib/kolla/venv/lib/python3.10/site-packages/pymysql/cursors.py", line 148, in execute 2023-01-31 21:53:55.981 671 ERROR keystone.server.flask.application result = self._query(query) 2023-01-31 21:53:55.981 671 ERROR keystone.server.flask.application File "/var/lib/kolla/venv/lib/python3.10/site-packages/pymysql/cursors.py", line 310, in _query 2023-01-31 21:53:55.981 671 ERROR keystone.server.flask.application conn.query(q) 2023-01-31 21:53:55.981 671 ERROR keystone.server.flask.application File "/var/lib/kolla/venv/lib/python3.10/site-packages/pymysql/connections.py", line 548, in query 2023-01-31 21:53:55.981 671 ERROR keystone.server.flask.application self._affected_rows = self._read_query_result(unbuffered=unbuffered) 2023-01-31 21:53:55.981 671 ERROR keystone.server.flask.application File "/var/lib/kolla/venv/lib/python3.10/site-packages/pymysql/connections.py", line 775, in _read_query_result 2023-01-31 21:53:55.981 671 ERROR keystone.server.flask.application result.read() 2023-01-31 21:53:55.981 671 ERROR keystone.server.flask.application File "/var/lib/kolla/venv/lib/python3.10/site-packages/pymysql/connections.py", line 1156, in read 2023-01-31 21:53:55.981 671 ERROR keystone.server.flask.application first_packet = self.connection._read_packet() 2023-01-31 21:53:55.981 671 ERROR keystone.server.flask.application File "/var/lib/kolla/venv/lib/python3.10/site-packages/pymysql/connections.py", line 725, in _read_packet 2023-01-31 21:53:55.981 671 ERROR keystone.server.flask.application packet.raise_for_error() 2023-01-31 21:53:55.981 671 ERROR keystone.server.flask.application File "/var/lib/kolla/venv/lib/python3.10/site-packages/pymysql/protocol.py", line 221, in raise_for_error 2023-01-31 21:53:55.981 671 ERROR keystone.server.flask.application err.raise_mysql_exception(self._data) 2023-01-31 21:53:55.981 671 ERROR keystone.server.flask.application File "/var/lib/kolla/venv/lib/python3.10/site-packages/pymysql/err.py", line 143, in raise_mysql_exception 2023-01-31 21:53:55.981 671 ERROR keystone.server.flask.application raise errorclass(errno, errval) 2023-01-31 21:53:55.981 671 ERROR keystone.server.flask.application pymysql.err.IntegrityError: (1062, "Duplicate entry '96-249' for key 'PRIMARY'") 2023-01-31 21:53:55.981 671 ERROR keystone.server.flask.application 2023-01-31 21:53:55.981 671 ERROR keystone.server.flask.application The above exception was the direct cause of the following exception: 2023-01-31 21:53:55.981 671 ERROR keystone.server.flask.application 2023-01-31 21:53:55.981 671 ERROR keystone.server.flask.application Traceback (most recent call last): 2023-01-31 21:53:55.981 671 ERROR keystone.server.flask.application File "/var/lib/kolla/venv/lib/python3.10/site-packages/keystone/common/sql/core.py", line 528, in wrapper 2023-01-31 21:53:55.981 671 ERROR keystone.server.flask.application return method(*args, **kwargs) 2023-01-31 21:53:55.981 671 ERROR keystone.server.flask.application File "/var/lib/kolla/venv/lib/python3.10/site-packages/keystone/application_credential/backends/sql.py", line 144, in create_application_credential 2023-01-31 21:53:55.981 671 ERROR keystone.server.flask.application external_id=access_rule['id']).first() 2023-01-31 21:53:55.981 671 ERROR keystone.server.flask.application File "/var/lib/kolla/venv/lib/python3.10/site-packages/sqlalchemy/orm/query.py", line 2823, in first 2023-01-31 21:53:55.981 671 ERROR keystone.server.flask.application return self.limit(1)._iter().first() 2023-01-31 21:53:55.981 671 ERROR keystone.server.flask.application File "/var/lib/kolla/venv/lib/python3.10/site-packages/sqlalchemy/orm/query.py", line 2907, in _iter 2023-01-31 21:53:55.981 671 ERROR keystone.server.flask.application result = self.session.execute( 2023-01-31 21:53:55.981 671 ERROR keystone.server.flask.application File "/var/lib/kolla/venv/lib/python3.10/site-packages/sqlalchemy/orm/session.py", line 1660, in execute 2023-01-31 21:53:55.981 671 ERROR keystone.server.flask.application ) = compile_state_cls.orm_pre_session_exec( 2023-01-31 21:53:55.981 671 ERROR keystone.server.flask.application File "/var/lib/kolla/venv/lib/python3.10/site-packages/sqlalchemy/orm/context.py", line 316, in orm_pre_session_exec 2023-01-31 21:53:55.981 671 ERROR keystone.server.flask.application session._autoflush() 2023-01-31 21:53:55.981 671 ERROR keystone.server.flask.application File "/var/lib/kolla/venv/lib/python3.10/site-packages/sqlalchemy/orm/session.py", line 2246, in _autoflush 2023-01-31 21:53:55.981 671 ERROR keystone.server.flask.application self.flush() 2023-01-31 21:53:55.981 671 ERROR keystone.server.flask.application File "/var/lib/kolla/venv/lib/python3.10/site-packages/sqlalchemy/orm/session.py", line 3383, in flush 2023-01-31 21:53:55.981 671 ERROR keystone.server.flask.application self._flush(objects) 2023-01-31 21:53:55.981 671 ERROR keystone.server.flask.application File "/var/lib/kolla/venv/lib/python3.10/site-packages/sqlalchemy/orm/session.py", line 3522, in _flush 2023-01-31 21:53:55.981 671 ERROR keystone.server.flask.application with util.safe_reraise(): 2023-01-31 21:53:55.981 671 ERROR keystone.server.flask.application File "/var/lib/kolla/venv/lib/python3.10/site-packages/sqlalchemy/util/langhelpers.py", line 70, in __exit__ 2023-01-31 21:53:55.981 671 ERROR keystone.server.flask.application compat.raise_( 2023-01-31 21:53:55.981 671 ERROR keystone.server.flask.application File "/var/lib/kolla/venv/lib/python3.10/site-packages/sqlalchemy/util/compat.py", line 208, in raise_ 2023-01-31 21:53:55.981 671 ERROR keystone.server.flask.application raise exception 2023-01-31 21:53:55.981 671 ERROR keystone.server.flask.application File "/var/lib/kolla/venv/lib/python3.10/site-packages/sqlalchemy/orm/session.py", line 3483, in _flush 2023-01-31 21:53:55.981 671 ERROR keystone.server.flask.application flush_context.execute() 2023-01-31 21:53:55.981 671 ERROR keystone.server.flask.application File "/var/lib/kolla/venv/lib/python3.10/site-packages/sqlalchemy/orm/unitofwork.py", line 456, in execute 2023-01-31 21:53:55.981 671 ERROR keystone.server.flask.application rec.execute(self) 2023-01-31 21:53:55.981 671 ERROR keystone.server.flask.application File "/var/lib/kolla/venv/lib/python3.10/site-packages/sqlalchemy/orm/unitofwork.py", line 630, in execute 2023-01-31 21:53:55.981 671 ERROR keystone.server.flask.application util.preloaded.orm_persistence.save_obj( 2023-01-31 21:53:55.981 671 ERROR keystone.server.flask.application File "/var/lib/kolla/venv/lib/python3.10/site-packages/sqlalchemy/orm/persistence.py", line 245, in save_obj 2023-01-31 21:53:55.981 671 ERROR keystone.server.flask.application _emit_insert_statements( 2023-01-31 21:53:55.981 671 ERROR keystone.server.flask.application File "/var/lib/kolla/venv/lib/python3.10/site-packages/sqlalchemy/orm/persistence.py", line 1097, in _emit_insert_statements 2023-01-31 21:53:55.981 671 ERROR keystone.server.flask.application c = connection._execute_20( 2023-01-31 21:53:55.981 671 ERROR keystone.server.flask.application File "/var/lib/kolla/venv/lib/python3.10/site-packages/sqlalchemy/engine/base.py", line 1705, in _execute_20 2023-01-31 21:53:55.981 671 ERROR keystone.server.flask.application return meth(self, args_10style, kwargs_10style, execution_options) 2023-01-31 21:53:55.981 671 ERROR keystone.server.flask.application File "/var/lib/kolla/venv/lib/python3.10/site-packages/sqlalchemy/sql/elements.py", line 333, in _execute_on_connection 2023-01-31 21:53:55.981 671 ERROR keystone.server.flask.application return connection._execute_clauseelement( 2023-01-31 21:53:55.981 671 ERROR keystone.server.flask.application File "/var/lib/kolla/venv/lib/python3.10/site-packages/sqlalchemy/engine/base.py", line 1572, in _execute_clauseelement 2023-01-31 21:53:55.981 671 ERROR keystone.server.flask.application ret = self._execute_context( 2023-01-31 21:53:55.981 671 ERROR keystone.server.flask.application File "/var/lib/kolla/venv/lib/python3.10/site-packages/sqlalchemy/engine/base.py", line 1943, in _execute_context 2023-01-31 21:53:55.981 671 ERROR keystone.server.flask.application self._handle_dbapi_exception( 2023-01-31 21:53:55.981 671 ERROR keystone.server.flask.application File "/var/lib/kolla/venv/lib/python3.10/site-packages/sqlalchemy/engine/base.py", line 2122, in _handle_dbapi_exception 2023-01-31 21:53:55.981 671 ERROR keystone.server.flask.application util.raise_(newraise, with_traceback=exc_info[2], from_=e) 2023-01-31 21:53:55.981 671 ERROR keystone.server.flask.application File "/var/lib/kolla/venv/lib/python3.10/site-packages/sqlalchemy/util/compat.py", line 208, in raise_ 2023-01-31 21:53:55.981 671 ERROR keystone.server.flask.application raise exception 2023-01-31 21:53:55.981 671 ERROR keystone.server.flask.application File "/var/lib/kolla/venv/lib/python3.10/site-packages/sqlalchemy/engine/base.py", line 1900, in _execute_context 2023-01-31 21:53:55.981 671 ERROR keystone.server.flask.application self.dialect.do_execute( 2023-01-31 21:53:55.981 671 ERROR keystone.server.flask.application File "/var/lib/kolla/venv/lib/python3.10/site-packages/sqlalchemy/engine/default.py", line 732, in do_execute 2023-01-31 21:53:55.981 671 ERROR keystone.server.flask.application cursor.execute(statement, parameters) 2023-01-31 21:53:55.981 671 ERROR keystone.server.flask.application File "/var/lib/kolla/venv/lib/python3.10/site-packages/pymysql/cursors.py", line 148, in execute 2023-01-31 21:53:55.981 671 ERROR keystone.server.flask.application result = self._query(query) 2023-01-31 21:53:55.981 671 ERROR keystone.server.flask.application File "/var/lib/kolla/venv/lib/python3.10/site-packages/pymysql/cursors.py", line 310, in _query 2023-01-31 21:53:55.981 671 ERROR keystone.server.flask.application conn.query(q) 2023-01-31 21:53:55.981 671 ERROR keystone.server.flask.application File "/var/lib/kolla/venv/lib/python3.10/site-packages/pymysql/connections.py", line 548, in query 2023-01-31 21:53:55.981 671 ERROR keystone.server.flask.application self._affected_rows = self._read_query_result(unbuffered=unbuffered) 2023-01-31 21:53:55.981 671 ERROR keystone.server.flask.application File "/var/lib/kolla/venv/lib/python3.10/site-packages/pymysql/connections.py", line 775, in _read_query_result 2023-01-31 21:53:55.981 671 ERROR keystone.server.flask.application result.read() 2023-01-31 21:53:55.981 671 ERROR keystone.server.flask.application File "/var/lib/kolla/venv/lib/python3.10/site-packages/pymysql/connections.py", line 1156, in read 2023-01-31 21:53:55.981 671 ERROR keystone.server.flask.application first_packet = self.connection._read_packet() 2023-01-31 21:53:55.981 671 ERROR keystone.server.flask.application File "/var/lib/kolla/venv/lib/python3.10/site-packages/pymysql/connections.py", line 725, in _read_packet 2023-01-31 21:53:55.981 671 ERROR keystone.server.flask.application packet.raise_for_error() 2023-01-31 21:53:55.981 671 ERROR keystone.server.flask.application File "/var/lib/kolla/venv/lib/python3.10/site-packages/pymysql/protocol.py", line 221, in raise_for_error 2023-01-31 21:53:55.981 671 ERROR keystone.server.flask.application err.raise_mysql_exception(self._data) 2023-01-31 21:53:55.981 671 ERROR keystone.server.flask.application File "/var/lib/kolla/venv/lib/python3.10/site-packages/pymysql/err.py", line 143, in raise_mysql_exception 2023-01-31 21:53:55.981 671 ERROR keystone.server.flask.application raise errorclass(errno, errval) 2023-01-31 21:53:55.981 671 ERROR keystone.server.flask.application oslo_db.exception.DBDuplicateEntry: (pymysql.err.IntegrityError) (1062, "Duplicate entry '96-249' for key 'PRIMARY'") 2023-01-31 21:53:55.981 671 ERROR keystone.server.flask.application [SQL: INSERT INTO application_credential_access_rule (application_credential_id, access_rule_id) VALUES (%(application_credential_id)s, %(access_rule_id)s)] 2023-01-31 21:53:55.981 671 ERROR keystone.server.flask.application [parameters: {'application_credential_id': 96, 'access_rule_id': 249}] 2023-01-31 21:53:55.981 671 ERROR keystone.server.flask.application (Background on this error at: https://sqlalche.me/e/14/gkpj) 2023-01-31 21:53:55.981 671 ERROR keystone.server.flask.application 2023-01-31 21:53:55.981 671 ERROR keystone.server.flask.application During handling of the above exception, another exception occurred: 2023-01-31 21:53:55.981 671 ERROR keystone.server.flask.application 2023-01-31 21:53:55.981 671 ERROR keystone.server.flask.application Traceback (most recent call last): 2023-01-31 21:53:55.981 671 ERROR keystone.server.flask.application File "/var/lib/kolla/venv/lib/python3.10/site-packages/flask/app.py", line 1820, in full_dispatch_request 2023-01-31 21:53:55.981 671 ERROR keystone.server.flask.application rv = self.dispatch_request() 2023-01-31 21:53:55.981 671 ERROR keystone.server.flask.application File "/var/lib/kolla/venv/lib/python3.10/site-packages/flask/app.py", line 1796, in dispatch_request 2023-01-31 21:53:55.981 671 ERROR keystone.server.flask.application return self.ensure_sync(self.view_functions[rule.endpoint])(**view_args) 2023-01-31 21:53:55.981 671 ERROR keystone.server.flask.application File "/var/lib/kolla/venv/lib/python3.10/site-packages/flask_restful/__init__.py", line 467, in wrapper 2023-01-31 21:53:55.981 671 ERROR keystone.server.flask.application resp = resource(*args, **kwargs) 2023-01-31 21:53:55.981 671 ERROR keystone.server.flask.application File "/var/lib/kolla/venv/lib/python3.10/site-packages/flask/views.py", line 107, in view 2023-01-31 21:53:55.981 671 ERROR keystone.server.flask.application return current_app.ensure_sync(self.dispatch_request)(**kwargs) 2023-01-31 21:53:55.981 671 ERROR keystone.server.flask.application File "/var/lib/kolla/venv/lib/python3.10/site-packages/flask_restful/__init__.py", line 582, in dispatch_request 2023-01-31 21:53:55.981 671 ERROR keystone.server.flask.application resp = meth(*args, **kwargs) 2023-01-31 21:53:55.981 671 ERROR keystone.server.flask.application File "/var/lib/kolla/venv/lib/python3.10/site-packages/keystone/api/users.py", line 669, in post 2023-01-31 21:53:55.981 671 ERROR keystone.server.flask.application ref = app_cred_api.create_application_credential( 2023-01-31 21:53:55.981 671 ERROR keystone.server.flask.application File "/var/lib/kolla/venv/lib/python3.10/site-packages/keystone/common/manager.py", line 115, in wrapped 2023-01-31 21:53:55.981 671 ERROR keystone.server.flask.application __ret_val = __f(*args, **kwargs) 2023-01-31 21:53:55.981 671 ERROR keystone.server.flask.application File "/var/lib/kolla/venv/lib/python3.10/site-packages/keystone/application_credential/core.py", line 137, in create_application_credential 2023-01-31 21:53:55.981 671 ERROR keystone.server.flask.application ref = self.driver.create_application_credential( 2023-01-31 21:53:55.981 671 ERROR keystone.server.flask.application File "/var/lib/kolla/venv/lib/python3.10/site-packages/keystone/common/sql/core.py", line 563, in wrapper 2023-01-31 21:53:55.981 671 ERROR keystone.server.flask.application raise exception.Conflict(type=conflict_type, 2023-01-31 21:53:55.981 671 ERROR keystone.server.flask.application keystone.exception.Conflict: Conflict occurred attempting to store application_credential - Duplicate entry found with name sa_capacity. 2023-01-31 21:53:55.981 671 ERROR keystone.server.flask.application Thanks Vish

1 0

[publiccloud-sig] Reminder - next meeting Feb 1st - 0800 UTC
by Felix Kronlage-Dammers 01 Feb '23

01 Feb '23

Hi everyone, a bit late but nevertheless a quick reminder: the next meeting of the Public Cloud SIG is on February 1st (tomorrow - depending on your timezone ;) at 0800 UTC. We meet on IRC in #openstack-operators. See also here for all other details: https://wiki.openstack.org/wiki/PublicCloudSIG regards felix

1 0

How to create a dynamic pollster subsystem to create a pollster for senlin cluster
by Uday Dikshit 31 Jan '23

31 Jan '23

Hello Team We are a public cloud provider based on Openstack. We are working to create Autoscaling with aodh and senlin in Kolla-ansible Openstack Wallaby release. We are facing an issue as ceilometer does not support metrics for senlin cluster as a resource. Our aim is to use https://docs.openstack.org/ceilometer/wallaby/admin/telemetry-dynamic-polls… to generate a pollster to collect data for senlin. We were looking if anybody in the community has ever used this feature. OpenStack Docs: Introduction to dynamic pollster subsystem<https://docs.openstack.org/ceilometer/wallaby/admin/telemetry-dynamic-polls…> Current limitations of the dynamic pollster system¶. Currently, the following types of APIs are not supported by the dynamic pollster system: Tenant APIs: Tenant APIs are the ones that need to be polled in a tenant fashion. docs.openstack.org Thanks & Regards, [https://acefone.com/email-signature/logo-new.png] [https://acefone.com/email-signature/facebook.png]<https://www.facebook.com/real.time.data.services/> [https://acefone.com/email-signature/linkedin.png]<https://www.linkedin.com/company/real-time-data-services/mycompany/> [https://acefone.com/email-signature/twitter.png]<https://twitter.com/rtdsindia> [https://acefone.com/email-signature/youtube.png]<https://www.youtube.com/channel/UCq93lA3ch6Pt5GzOAhRwgpw> [https://acefone.com/email-signature/glassdoor.png]<https://www.glassdoor.co.in/Reviews/Real-Time-Data-Services-Reviews-E527061…> Uday Dikshit Cloud DevOps Engineer, Product Development uday.dikshit(a)myrealdata.in www.myrealdata.in<http://www.myrealdata.in/> 809-A Udyog Vihar, Phase 5, Gurugram - 122015, Haryana

3 3

[trove] Unable to manage databases with mariadb 10.7
by Rishat Azizov 31 Jan '23

31 Jan '23

Hello! I get this error when listing databases: "An error occurred communicating with the guest: 'utf8mb3_general_ci' not a valid collation.\nTraceback (most recent call last):\n\n File \"/opt/guest-agent-venv/lib/python3.8/site-packages/oslo_messaging/rpc/server.py\", line 165, in _process_incoming\n res = self.dispatcher.dispatch(message)\n\n File \"/opt/guest-agent-venv/lib/python3.8/site-packages/oslo_messaging/rpc/dispatcher.py\", line 309, in dispatch\n return self._do_dispatch(endpoint, method, ctxt, args)\n\n File \"/opt/guest-agent-venv/lib/python3.8/site-packages/oslo_messaging/rpc/dispatcher.py\", line 229, in _do_dispatch\n result = func(ctxt, **new_args)\n\n File \"/opt/guest-agent-venv/lib/python3.8/site-packages/osprofiler/profiler.py\", line 160, in wrapper\n result = f(*args, **kwargs)\n\n File \"/opt/guest-agent-venv/lib/python3.8/site-packages/trove/guestagent/datastore/manager.py\", line 812, in list_databases\n return self.adm.list_databases(limit, marker, include_marker)\n\n File \"/opt/guest-agent-venv/lib/python3.8/site-packages/trove/guestagent/datastore/mysql_common/service.py\", line 341, in list_databases\n mysql_db = models.MySQLSchema(name=database[0],\n\n File \"/opt/guest-agent-venv/lib/python3.8/site-packages/trove/common/db/mysql/models.py\", line 46, in __init__\n self.collate = collate\n\n File \"/opt/guest-agent-venv/lib/python3.8/site-packages/trove/common/db/mysql/models.py\", line 85, in collate\n raise ValueError(_(\"'%s' not a valid collation.\") % value)\n\nValueError: 'utf8mb3_general_ci' not a valid collation.\n.❌ 400 get /instances/78ffcc29-9a36-486d-aa4f-f4133511696d/databases trustId: a8daa2804e404a28b64df50fb824bb63" Listing failed becase in mariadb 10.7 utf8_general_ci aliased to utf8mb3_general_ci. Could you please help with this error?

1 0

[neutron][kolla] Do neutron agents in compute nodes connect to neutron database ?
by ZAOUAM Soufian (EXT) 31 Jan '23

31 Jan '23

Hi all, Do neutron agents in compute nodes have to connect to neutron database ? We are maintaining an Openstack using kolla-ansible (ussuri version). We noticed that the 4 neutron agents on compute nodes: neutron-l3-agent, neutron-metadata-agent, neutron-openvswitch-agent, neutron-dhcp-agent are all using the same neutron.conf config file, but we are wondering if they actually use [database] or is it redundant ? If no, is it safe to remove the [database] section from the neutron.conf for these agents? Best regards, ========================================================= Ce message et toutes les pieces jointes (ci-apres le "message") sont confidentiels et susceptibles de contenir des informations couvertes par le secret professionnel. Ce message est etabli a l'intention exclusive de ses destinataires. Toute utilisation ou diffusion non autorisee interdite. Tout message electronique est susceptible d'alteration. La SOCIETE GENERALE et ses filiales declinent toute responsabilite au titre de ce message s'il a ete altere, deforme falsifie. ========================================================= This message and any attachments (the "message") are confidential, intended solely for the addresses, and may contain legally privileged information. Any unauthorized use or dissemination is prohibited. E-mails are susceptible to alteration. Neither SOCIETE GENERALE nor any of its subsidiaries or affiliates shall be liable for the message if altered, changed or falsified. =========================================================

2 1

[all][elections][ptl][tc] Combined PTL/TC bugbear cycle Election Season
by Ian Y. Choi 31 Jan '23

31 Jan '23

Election details: https://governance.openstack.org/election/ The nomination period officially begins Feb 01, 2023 23:45 UTC. Please read the stipulations and timelines for candidates and electorate contained in this governance documentation. Due to circumstances of timing, PTL and TC elections for the coming cycle will run concurrently; deadlines for their nomination and voting activities are synchronized but will still use separate ballots. Please note, if only one candidate is nominated as PTL for a project team during the PTL nomination period, that candidate will win by acclaim, and there will be no poll. There will only be a poll if there is more than one candidate stepping forward for a project team's PTL position. There will be further announcements posted to the mailing list as action is required from the electorate or candidates. This email is for information purposes only. If you have any questions which you feel affect others please reply to this email thread. If you have any questions that you which to discuss in private please email any of the election officials[1] so that we may address your concerns. Thank you, [1] https://governance.openstack.org/election/#election-officials

1 1

[cinder][requirements] python-cinderclient Yoga gate broken due to rtslib-fb
by Rajat Dhasmana 30 Jan '23

30 Jan '23

Hello, Currently python-cinderclient yoga gate is broken because *python-cinderclient-functional-py39* job is failing. Upon looking into the logs, I found the *cinder-rtstool delete *command failing[1]. Jan 16 07:58:14.935519 np0032740756 cinder-volume[115744]: ERROR cinder.volume.targets.lio Command: sudo cinder-rootwrap /etc/cinder/rootwrap.conf cinder-rtstool delete iqn.2010-10.org.openstack:volume-095ce534-8ef7-45c8-867c-f6d4fbc2b02d Jan 16 07:58:14.935519 np0032740756 cinder-volume[115744]: ERROR cinder.volume.targets.lio Exit code: 1 Jan 16 07:58:14.935519 np0032740756 cinder-volume[115744]: ERROR cinder.volume.targets.lio Stdout: '' Looking further into the traceback, this seems to be the main issue. line 215, in _gen_attached_luns\n for tpgt_dir in listdir(tpgts_base):\nNotADirectoryError: [Errno 20] Not a directory: \'/sys/kernel/config/target/iscsi/cpus_allowed_list\'\n' I found a similar (not exact) error in thread[2] to which there was a reply that it was fixed[3]. The fix is included in version 2.1.75[4] but the version pinned in upper constraints for yoga is 2.1.74[5]. I've tested the version bump in these DNM patches[6][7] and it works. A quick code search reveals that cinder is the only project actively using this lib[8]. My question for the requirements team is, is it OK to bump the requirement to allow cinderclient yoga gate to pass since it's blocking backports? [1] https://zuul.opendev.org/t/openstack/build/a282bfbb6b0a4148a69694db6ab7eb69… [2] https://www.spinics.net/lists/linux-scsi/msg172264.html [3] https://www.spinics.net/lists/linux-scsi/msg172265.html [4] https://github.com/open-iscsi/rtslib-fb/commit/8d2543c4da62e962661011fea5b1… [5] https://github.com/openstack/requirements/blob/stable/yoga/upper-constraint… [6] https://review.opendev.org/c/openstack/python-cinderclient/+/870513 [7] https://review.opendev.org/c/openstack/requirements/+/870714 [8] https://codesearch.opendev.org/?q=rtslib-fb&i=nope&literal=nope&files=&excl… Thanks Rajat Dhasmana

2 2

[Keystone | python-openstackclient] Fedartion with OAuth2.0/OIDC
by Niklas Schwarz 30 Jan '23

30 Jan '23

Hey there, I'm currently investigating the features of openstack federated identity and oauth2/oidc with keycloak as an identity provider. Following the documentation [1] I have successfully deployed a setup where it is possible to login via the horizion board using the login of keycloak. As defined in the documentation I'm using apache2 with the mod_auth_openidc module. So far so good... If I try to access the api via the openstack-cli using the following configuration ``` OS_AUTH_URL=https://<openstack-ip>/identity/v3 OS_AUTH_TYPE=v3oidcpassword OS_IDENTITY_PROVIDER=keycloak OS_PROTOCOL=openid OS_USERNAME=<keycloak-user> OS_PASSWORD=<keycloak-password> OS_PROJECT=test OS_OPENID_SCOPE='openid email profile' OS_DISCOVERY_ENDPOINT=https:// <keycloak-ip>/realms/<realm>/.well-known/openid-configuration OS_ACCESS_TOKEN_TYPE=access_token OS_CLIENT_ID=<client-id> OS_CLIENT_SECRET=<client-secret> ``` the http-status-code of the server is 500. Inspecting the logs , I found the problem in the mod_auth_openidc modul which expects a content-type of application/x-www-form-urlencoded. Is there any way to change the content-type the openstack-cli from json to urlencoded or am I missing a step in the configuration or something else? Thanks in advanced Niklas [1] https://docs.openstack.org/keystone/zed/admin/federation/configure_federati…

1 0

[Neutron] Bug Deputy Report January 23 - 29
by Oleg Bondarev 30 Jan '23

30 Jan '23

Hello Neutron Team, Bug report for the week of Jan 23 is below: *High:* - https://bugs.launchpad.net/neutron/+bug/2004012 - [Secure RBAC] Delete port on own network which is shared with other project is not possible Confirmed Unassigned - https://bugs.launchpad.net/neutron/+bug/2004015 - [Secure RBAC] Sharing Security groups don't works with new RBAC policies Edit Confirmed Unassigned - https://bugs.launchpad.net/neutron/+bug/2004014 - [Secure RBAC] Sharing QoS Policies don't works with new RBAC policies Confirmed Unassigned - https://bugs.launchpad.net/neutron/+bug/2004013 - [Secure RBAC] List QoS Policies filtered by tags is not possible with new RBAC policies Confirmed Unassigned - https://bugs.launchpad.net/neutron/+bug/2004017 - [Secure RBAC] List flavors don't work for regular user with new RBAC policies Confirmed Unassigned - https://bugs.launchpad.net/neutron/+bug/2004016 - [Secure RBAC] Cleaning shared networks fails with new RBAC policies Confirmed Unassigned *Medium:* - https://bugs.launchpad.net/neutron/+bug/2003706 - [OVN] Security group logging only logs half of the connection In progress: https://review.opendev.org/c/openstack/neutron/+/871096 Assigned to elvira - https://bugs.launchpad.net/neutron/+bug/2003842 - [OVN] A route inferred from a subnet's default gateway is not added to ovn-nb if segment_id is not None for a subnet Invalid Unassigned - https://bugs.launchpad.net/neutron/+bug/2004004 - keepalived virtual_routes wrong order Triaged Unassigned - https://bugs.launchpad.net/neutron/+bug/2003997 - [ovn-octavia-provider] ovn-lb with VIP on provider network not working In progress Assigned to ltomasbo *Low:* - https://bugs.launchpad.net/neutron/+bug/2003861 - Remove the CLI code from python-neutronclient Triaged Assigned to ralonsoh - https://bugs.launchpad.net/neutron/+bug/2003999 - Stateleful SG API extension should be disabled when old OVN is used In progres: https://review.opendev.org/c/openstack/neutron/+/871982, https://review.opendev.org/c/openstack/neutron/+/871983s Assigned to slaweq *Undecided:* - https://bugs.launchpad.net/neutron/+bug/2004041 - Missing flows with ovs dvr after openvswitch restart Incomplete: more info requested Unassigned Thanks, Oleg

1 0

hacluster_corosync container stuck in restarting
by Karera Tony 30 Jan '23

30 Jan '23

Dear Team, I installed Openstack Wallaby using kolla-ansible. Everything is fine except for the hacluster_corosync container stuck in restarting. Below are the corosync logs. Has anyone faced this issue before ? I have two controllers but this issue is on happening on one Jan 30 08:19:42 [7] controller1 corosync info [TOTEM ] kronosnet crypto initialized: aes256/sha384 Jan 30 08:19:42 [7] controller1 corosync info [TOTEM ] totemknet initialized Jan 30 08:19:42 [7] controller1 corosync info [KNET ] common: crypto_nss.so has been loaded from /usr/lib/x86_64-linux-gnu/kronosnet/crypto_nss.so Jan 30 08:19:42 [7] controller1 corosync notice [SERV ] Service engine loaded: corosync configuration map access [0] Jan 30 08:19:42 [7] controller1 corosync info [QB ] server name: cmap Jan 30 08:19:42 [7] controller1 corosync error [QB ] Could not bind AF_UNIX (): Address already in use (98) Jan 30 08:19:42 [7] controller1 corosync info [QB ] withdrawing server sockets Jan 30 08:19:42 [7] controller1 corosync error [MAIN ] Can't initialize IPC Jan 30 08:19:42 [7] controller1 corosync error [SERV ] Service engine 'corosync_cmap' failed to load for reason 'qb_ipcs_run error' Jan 30 08:19:42 [7] controller1 corosync error [MAIN ] Corosync Cluster Engine exiting with status 20 at service.c:356. Jan 30 08:20:43 [7] controller1 corosync notice [MAIN ] Corosync Cluster Engine 3.0.3 starting up Jan 30 08:20:43 [7] controller1 corosync info [MAIN ] Corosync built-in features: dbus monitoring watchdog augeas systemd xmlconf vqsim nozzle snmp pie relro bindnow Jan 30 08:20:43 [7] controller1 corosync warning [MAIN ] Could not increase RLIMIT_MEMLOCK, not locking memory: Operation not permitted (1) Jan 30 08:20:43 [7] controller1 corosync notice [TOTEM ] Initializing transport (Kronosnet). Jan 30 08:20:43 [7] controller1 corosync info [TOTEM ] kronosnet crypto initialized: aes256/sha384 Jan 30 08:20:43 [7] controller1 corosync info [TOTEM ] totemknet initialized Jan 30 08:20:43 [7] controller1 corosync info [KNET ] common: crypto_nss.so has been loaded from /usr/lib/x86_64-linux-gnu/kronosnet/crypto_nss.so Jan 30 08:20:43 [7] controller1 corosync notice [SERV ] Service engine loaded: corosync configuration map access [0] Jan 30 08:20:43 [7] controller1 corosync info [QB ] server name: cmap Jan 30 08:20:43 [7] controller1 corosync error [QB ] Could not bind AF_UNIX (): Address already in use (98) Jan 30 08:20:43 [7] controller1 corosync info [QB ] withdrawing server sockets Jan 30 08:20:43 [7] controller1 corosync error [MAIN ] Can't initialize IPC Jan 30 08:20:43 [7] controller1 corosync error [SERV ] Service engine 'corosync_cmap' failed to load for reason 'qb_ipcs_run error' Jan 30 08:20:43 [7] controller1 corosync error [MAIN ] Corosync Cluster Engine exiting with status 20 at service.c:356. Jan 30 08:21:43 [7] controller1 corosync notice [MAIN ] Corosync Cluster Engine 3.0.3 starting up Jan 30 08:21:43 [7] controller1 corosync info [MAIN ] Corosync built-in features: dbus monitoring watchdog augeas systemd xmlconf vqsim nozzle snmp pie relro bindnow Jan 30 08:21:43 [7] controller1 corosync warning [MAIN ] Could not increase RLIMIT_MEMLOCK, not locking memory: Operation not permitted (1) Jan 30 08:21:43 [7] controller1 corosync notice [TOTEM ] Initializing transport (Kronosnet). Jan 30 08:21:44 [7] controller1 corosync info [TOTEM ] kronosnet crypto initialized: aes256/sha384 Jan 30 08:21:44 [7] controller1 corosync info [TOTEM ] totemknet initialized Jan 30 08:21:44 [7] controller1 corosync info [KNET ] common: crypto_nss.so has been loaded from /usr/lib/x86_64-linux-gnu/kronosnet/crypto_nss.so Jan 30 08:21:44 [7] controller1 corosync notice [SERV ] Service engine loaded: corosync configuration map access [0] Jan 30 08:21:44 [7] controller1 corosync info [QB ] server name: cmap Jan 30 08:21:44 [7] controller1 corosync error [QB ] Could not bind AF_UNIX (): Address already in use (98) Jan 30 08:21:44 [7] controller1 corosync info [QB ] withdrawing server sockets Jan 30 08:21:44 [7] controller1 corosync error [MAIN ] Can't initialize IPC Jan 30 08:21:44 [7] controller1 corosync error [SERV ] Service engine 'corosync_cmap' failed to load for reason 'qb_ipcs_run error' Jan 30 08:21:44 [7] controller1 corosync error [MAIN ] Corosync Cluster Engine exiting with status 20 at service.c:356. Regards Regards Tony Karera

1 0

hacluster_corosync container stuck in restarting
by Karera Tony 30 Jan '23

30 Jan '23

Dear Team, I installed Openstack Wallaby using kolla-ansible. Everything is fine except for hacluster_corosync container stuck in restarting. Below are the corosync logs. Has anyone faced this issue before ? Jan 30 08:19:42 [7] controller1 corosync info [TOTEM ] kronosnet crypto initialized: aes256/sha384 Jan 30 08:19:42 [7] controller1 corosync info [TOTEM ] totemknet initialized Jan 30 08:19:42 [7] controller1 corosync info [KNET ] common: crypto_nss.so has been loaded from /usr/lib/x86_64-linux-gnu/kronosnet/crypto_nss.so Jan 30 08:19:42 [7] controller1 corosync notice [SERV ] Service engine loaded: corosync configuration map access [0] Jan 30 08:19:42 [7] controller1 corosync info [QB ] server name: cmap Jan 30 08:19:42 [7] controller1 corosync error [QB ] Could not bind AF_UNIX (): Address already in use (98) Jan 30 08:19:42 [7] controller1 corosync info [QB ] withdrawing server sockets Jan 30 08:19:42 [7] controller1 corosync error [MAIN ] Can't initialize IPC Jan 30 08:19:42 [7] controller1 corosync error [SERV ] Service engine 'corosync_cmap' failed to load for reason 'qb_ipcs_run error' Jan 30 08:19:42 [7] controller1 corosync error [MAIN ] Corosync Cluster Engine exiting with status 20 at service.c:356. Jan 30 08:20:43 [7] controller1 corosync notice [MAIN ] Corosync Cluster Engine 3.0.3 starting up Jan 30 08:20:43 [7] controller1 corosync info [MAIN ] Corosync built-in features: dbus monitoring watchdog augeas systemd xmlconf vqsim nozzle snmp pie relro bindnow Jan 30 08:20:43 [7] controller1 corosync warning [MAIN ] Could not increase RLIMIT_MEMLOCK, not locking memory: Operation not permitted (1) Jan 30 08:20:43 [7] controller1 corosync notice [TOTEM ] Initializing transport (Kronosnet). Jan 30 08:20:43 [7] controller1 corosync info [TOTEM ] kronosnet crypto initialized: aes256/sha384 Jan 30 08:20:43 [7] controller1 corosync info [TOTEM ] totemknet initialized Jan 30 08:20:43 [7] controller1 corosync info [KNET ] common: crypto_nss.so has been loaded from /usr/lib/x86_64-linux-gnu/kronosnet/crypto_nss.so Jan 30 08:20:43 [7] controller1 corosync notice [SERV ] Service engine loaded: corosync configuration map access [0] Jan 30 08:20:43 [7] controller1 corosync info [QB ] server name: cmap Jan 30 08:20:43 [7] controller1 corosync error [QB ] Could not bind AF_UNIX (): Address already in use (98) Jan 30 08:20:43 [7] controller1 corosync info [QB ] withdrawing server sockets Jan 30 08:20:43 [7] controller1 corosync error [MAIN ] Can't initialize IPC Jan 30 08:20:43 [7] controller1 corosync error [SERV ] Service engine 'corosync_cmap' failed to load for reason 'qb_ipcs_run error' Jan 30 08:20:43 [7] controller1 corosync error [MAIN ] Corosync Cluster Engine exiting with status 20 at service.c:356. Jan 30 08:21:43 [7] controller1 corosync notice [MAIN ] Corosync Cluster Engine 3.0.3 starting up Jan 30 08:21:43 [7] controller1 corosync info [MAIN ] Corosync built-in features: dbus monitoring watchdog augeas systemd xmlconf vqsim nozzle snmp pie relro bindnow Jan 30 08:21:43 [7] controller1 corosync warning [MAIN ] Could not increase RLIMIT_MEMLOCK, not locking memory: Operation not permitted (1) Jan 30 08:21:43 [7] controller1 corosync notice [TOTEM ] Initializing transport (Kronosnet). Jan 30 08:21:44 [7] controller1 corosync info [TOTEM ] kronosnet crypto initialized: aes256/sha384 Jan 30 08:21:44 [7] controller1 corosync info [TOTEM ] totemknet initialized Jan 30 08:21:44 [7] controller1 corosync info [KNET ] common: crypto_nss.so has been loaded from /usr/lib/x86_64-linux-gnu/kronosnet/crypto_nss.so Jan 30 08:21:44 [7] controller1 corosync notice [SERV ] Service engine loaded: corosync configuration map access [0] Jan 30 08:21:44 [7] controller1 corosync info [QB ] server name: cmap Jan 30 08:21:44 [7] controller1 corosync error [QB ] Could not bind AF_UNIX (): Address already in use (98) Jan 30 08:21:44 [7] controller1 corosync info [QB ] withdrawing server sockets Jan 30 08:21:44 [7] controller1 corosync error [MAIN ] Can't initialize IPC Jan 30 08:21:44 [7] controller1 corosync error [SERV ] Service engine 'corosync_cmap' failed to load for reason 'qb_ipcs_run error' Jan 30 08:21:44 [7] controller1 corosync error [MAIN ] Corosync Cluster Engine exiting with status 20 at service.c:356. Regards Tony Karera

1 0

Re: [all][stable][ptl] Propose to EOL Rocky series
by Thomas Goirand 28 Jan '23

28 Jan '23

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… > >> >

1 0

Pulling plugins from my Github repository
by vincent lee 28 Jan '23

28 Jan '23

Hi everyone, I would like to know where exactly I can replace the path for the GitHub repository. For example, I want to pull some plugins, such as zun_ui, blazar_dashboard, etc., from my own GitHub repository instead of the default GitHub repository. I am currently using Kolla-ansible for deploying OpenStack in the yoga version. Best, Vincent

1 0

[all][tc] What's happening in Technical Committee: summary 2023 Jan 27: Reading: 5 min
by Ghanshyam Mann 28 Jan '23

28 Jan '23

Hello Everyone, Here is this week's summary of the Technical Committee activities. 1. TC Meetings: ============ * We had this week's meeting on Jan 25. Most of the meeting discussions are summarized in this email. Meeting logs are available @ https://meetings.opendev.org/meetings/tc/2023/tc.2023-01-25-16.00.log.html * The next TC weekly meeting will be on Feb 1 Wed at 16:00 UTC, Feel free to add the topic to the agenda[1] by Jan 31. 2. What we completed this week: ========================= * Added Axel to Mistral project DPL list[2] * Remaining two projects (Mistral and Zaqar) which were less active (their release was in question) are green and active now. Their beta releases are also completed[3][4][5][6]. 3. Activities In progress: ================== TC Tracker for the 2023.1 cycle ------------------------------------- * Current cycle working items and their progress are present in the 2023.1 tracker etherpad[7]. Open Reviews ----------------- * Two open reviews for ongoing activities[8]. Cleanup of PyPI maintainer list for OpenStack Projects ---------------------------------------------------------------- The audit process is going on and a few projects have been completed [9]. There is a discussion also going on in ML[10]. The TC discussed it in this week's meeting also and no change in the initial plan for the cleanup of additional PyPi maintainers. The process to find the less active projects early in the cycle: ------------------------------------------------------------------------ I think in every cycle we get some less active projects and that is too little late in the cycle which adds extra work for the release team to release such projects. We discussed in PTG that TC should come up with some process to find such less active projects a little early in the cycle. JayF started the etherpad to collect the data and define the criteria to help in this process[11]. Project updates ------------------- * Add Cinder Huawei charm[12] * Add the woodpecker charm to Openstack charms[13] 4. How to contact the TC: ==================== If you would like to discuss or give feedback to TC, you can reach out to us in multiple ways: 1. Email: you can send the email with tag [tc] on openstack-discuss ML[14]. 2. Weekly meeting: The Technical Committee conduct a weekly meeting every Thursday 15:00 UTC [15] 3. Ping us using 'tc-members' nickname on #openstack-tc IRC channel. [1] https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Agenda_Suggesti… [2] https://review.opendev.org/c/openstack/governance/+/871302 [3] https://review.opendev.org/c/openstack/releases/+/869470 [4] https://review.opendev.org/c/openstack/releases/+/869448 [5] https://review.opendev.org/c/openstack/zaqar/+/857924 [6] https://review.opendev.org/c/openstack/releases/+/871399 [7] https://etherpad.opendev.org/p/tc-2023.1-tracker [8] https://review.opendev.org/q/projects:openstack/governance+status:open [9] https://etherpad.opendev.org/p/openstack-pypi-maintainers-cleanup [10] https://lists.openstack.org/pipermail/openstack-discuss/2023-January/031848… [11] https://etherpad.opendev.org/p/project-health-check [12] https://review.opendev.org/c/openstack/governance/+/867588 [13] https://review.opendev.org/c/openstack/governance/+/869752 [14] hhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss [15] http://eavesdrop.openstack.org/#Technical_Committee_Meeting -gmann

1 0

[kolla] [senlin] [xena] Self-signed cert errors during Senlin auth
by Rob Jefferson 27 Jan '23

27 Jan '23

Folks, I am deploying OpenStack Xena via Kolla. As part of improving our orchestration offerings, I am investigating the use of Senlin in our deployments. Using `enable_senlin: "yes"`, the containers install as expected. When I attempt to create an initial profile, I get the following error: > HttpException: 500: Server Error for url: https://external:8778/v1/profiles, > Could not find versioned identity endpoints when attempting to authenticate. > Please check that your auth_url is correct. SSL exception connecting > to https://internal:35357: HTTPSConnectionPool(host='internal', > port=35357): Max retries exceeded with url: / (Caused by > SSLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] > certificate verify failed: self signed certificate in > certificate chain (_ssl.c:1131)'))) I have tried setting `verify_ssl = False` in senlin.conf, but no dice. I don't see this issue on the other services for which we're using the same certificates (e.g., Heat, Keystone, Barbican). Looking in the containers, I don't see <service>-cert.pem or <service>-key.pem files for Senlin as I did for other services. Moreover, the authentication configurations look the same in all relevant respects, between Senlin and the services that do work. I'm positively flummoxed about why the certs aren't getting distributed. When I take a look at the documentation for Kolla TLS [1], I saw the following: > Enabling TLS on the backend services secures communication between the > HAProxy listing on the internal/external VIP and the OpenStack > services. It also enables secure end-to-end communication between > OpenStack services that support TLS termination. The OpenStack services > that support backend TLS termination in Victoria are: Nova, Ironic, > Neutron, Keystone, Glance, Heat, Placement, Horizon, Barbican, and > Cinder. Missing from here is Senlin, and looking at the same document from subsequent OpenStack releases suggests this hasn't changed. I don't know if this is a relevant issue to the problem I've been having (to be fair, I don't see Octavia, which we've also been using, on the list, even though we also haven't been having issues with Octavia certs). Is this something that I can fix via configuration, or is this a thing wherein we need to change how Kolla deploys Senlin, or even adding in SSL termination to the Senlin service? Any help on this would be greatly appreciated. Thanks, Rob [1] https://github.com/openstack/kolla-ansible/blob/stable/xena/doc/source/admi…

1 0

[Openstack][cinder] multiple backend generic volume group issue
by Ignazio Cassano 27 Jan '23

27 Jan '23

Hello All, I created a cinder configuration using multiple backends based on netapp ontap nfs with the same backend name and the same volume type. So my nfsgold1, nfsgold2 and nfsgold3 are addressed by the nfsgold volume backend name and nfsgold volume type. Each one has its own svm on netapp. This help me to distribute nfsgold volumes using scheduler filters based on free capacity. So when I create a volume with volume type nfsgold the scheduler allocates it on nfsgold1 or nfsgold2 or nfsgold3 using the capacity filter. Since some virtual machines need to have volumes on the same backend (for example nfsgold1) because they belong to the same application, I use the cinder scheduler hint. Why I need to store those volumes on the same backend? It is because they must belong to the same generic volume group for snaphotting at the same time. For this reason I need to create a generic volume group. Generic volume group creation need the volume type, in my case nfsgold. But like the volume, when I create a generic volume group, it is scheduled on nfsgold1 or nfsgold2 or nfsgold3 and it is obvious looking in the cinder database. So if I want to groups volumes of an application I must: 1 check if they are on the same backend (nfsgold1/nfsgold2/nfsgold3) 2) check on which backend the volume group is allocated (nfsgold1,/nfsgold2/nfsgold3) and it can be done only looking in the cinder database). Volumes and volume goups must stay on the same real backend. If not, when I create a group snapshot, it gives some errors because it checks the host related to the real backend (nfsgold1/nfsgold2/nfsgold3) and returns errors failing the operation. When I create a volume group by api or by command line, I must specify the volume type but I cannot know which is the real backend associated to it without looking in the cinder database. I think this is a bug. In the above situation, how can obtain consistent volume group snapshot ? Sorry for my bad english. I hope who is reading can understand what I mean. Ignazio

1 0

[openstack-ansible] Meeting on 31st of January 2023 is cancelled
by Dmitriy Rabotyagov 27 Jan '23

27 Jan '23

Hi everyone, Due to limited availability of core members for the upcoming meeting that should have taken place on 31.01.2023, I'm informing you that this meeting will be cancelled. Hoping to see everyone for the next meeting on 7th of February.

1 0

[release] Release countdown for week R-7, Jan 30 - Feb 03
by Elõd Illés 27 Jan '23

27 Jan '23

Development Focus ----------------- We are entering the last weeks of the 2023.1 Antelope development cycle. From now until the final release, we'll send a countdown email like this every week. It's probably a good time for teams to take stock of their library and client work that needs to be completed yet. The non-client library freeze is coming up, followed closely by the client lib freeze. Please plan accordingly to avoid any last minute rushes to get key functionality in. General Information ------------------- Next week is the Extra-ATC freeze, in preparation for elections. All contributions to OpenStack are valuable, but some are not expressed as Gerrit code changes. Please list active contributors to your project team who do not have a code contribution this cycle, and therefore won't automatically be considered an Active Technical Contributor and allowed to vote. This is done by adding extra-atcs to https://opendev.org/openstack/governance/src/branch/master/reference/projec… before the Extra-ATC freeze on February 2nd, 2023. A quick reminder of the upcoming freeze dates. Those vary depending on deliverable type: * General libraries (except client libraries) need to have their last feature release before Non-client library freeze (February 9th, 2023). Their stable branches are cut early. * Client libraries (think python-*client libraries) need to have their last feature release before Client library freeze (February 16th, 2023) * Deliverables following a cycle-with-rc model (that would be most services) observe a Feature freeze on that same date, February 16th, 2023. Any feature addition beyond that date should be discussed on the mailing-list and get PTL approval. After feature freeze, cycle-with-rc deliverables need to produce a first release candidate (and a stable branch) before RC1 deadline (March 2nd, 2023) * Deliverables following cycle-with-intermediary model can release as necessary, but in all cases before Final RC deadline (March 16th, 2023) Finally, now is also a good time to start planning what highlights you want for your deliverables in the cycle highlights. The deadline to submit an initial version for those is set to Feature freeze (February 16th, 2023). Background on cycle-highlights: http://lists.openstack.org/pipermail/openstack-dev/2017-December/125613.html Project Team Guide, Cycle-Highlights: https://docs.openstack.org/project-team-guide/release-management.html#cycle… knelson [at] openstack.org/diablo_rojo on IRC is available if you need help selecting or writing your highlights Upcoming Deadlines & Dates -------------------------- Extra-ATC freeze: February 2nd, 2023 (R-7 week) Non-client library freeze: February 9th, 2023 (R-6 week) Client library freeze: February 16th, 2023 (R-5 week) Antelope-3 milestone: February 16th, 2023 (R-5 week) 2023.2 Bobcat Virtual PTG: March 27-31, 2023 Előd Illés irc: elodilles @ #openstack-release

1 0

cloud dcn01 (edge) not found in External Deployment Post deployment Tasks | tripleo | wallaby | centos 8 stream
by Swogat Pradhan 27 Jan '23

27 Jan '23

Hi, I am trying to deploy DCN and in the final step getting the following error: 2023-01-27 18:31:10.843012 | 48d539a1-1679-1cbd-45d5-0000000000fe | TASK | Nova: Manage aggregate and availability zone and add hosts to the zone Using module file /usr/lib/python3.6/site-packages/ansible/modules/cloud/openstack/os_nova_host_aggregate.py Pipelining is enabled. <localhost> ESTABLISH LOCAL CONNECTION FOR USER: stack <localhost> EXEC /bin/sh -c 'sudo -H -S -n -u root /bin/sh -c '"'"'echo BECOME-SUCCESS-bhcwyaeoxhaczfutgazdvosyznxmddwq ; OS_CLOUD=dcn01 /usr/bin/python3'"'"' && sleep 0' The full traceback is: File "/tmp/ansible_os_nova_host_aggregate_payload_uur0b1qu/ansible_os_nova_host_aggregate_payload.zip/ansible/module_utils/openstack.py", line 159, in openstack_cloud_from_module interface=module.params['interface'], File "/usr/lib/python3.6/site-packages/openstack/__init__.py", line 63, in connect options=options, **kwargs) File "/usr/lib/python3.6/site-packages/openstack/config/__init__.py", line 36, in get_cloud_region return config.get_one(options=parsed_options, **kwargs) File "/usr/lib/python3.6/site-packages/openstack/config/loader.py", line 1107, in get_one config = self._get_base_cloud_config(cloud, profile) File "/usr/lib/python3.6/site-packages/openstack/config/loader.py", line 509, in _get_base_cloud_config name=name)) 2023-01-27 18:31:14.137975 | 48d539a1-1679-1cbd-45d5-0000000000fe | FATAL | Nova: Manage aggregate and availability zone and add hosts to the zone | undercloud | error={ "changed": false, "invocation": { "module_args": { "api_timeout": null, "auth": null, "auth_type": null, "availability_zone": "dcn01", "ca_cert": null, "client_cert": null, "client_key": null, "hosts": [ "dcn01-hci-0.bdxworld.com", "dcn01-hci-1.bdxworld.com", "dcn01-hci-2.bdxworld.com" ], "interface": "public", "metadata": null, "name": "dcn01", "region_name": null, "state": "present", "timeout": 180, "validate_certs": null, "wait": true } }, "msg": "Cloud dcn01 was not found." } 2023-01-27 18:31:14.139916 | 48d539a1-1679-1cbd-45d5 Deploy step: (undercloud) [stack@hkg2director dcn01]$ cat deploy_dcn01.sh #!/bin/bash THT=/usr/share/openstack-tripleo-heat-templates/ CNF=/home/stack/ openstack overcloud deploy \ --stack dcn01 \ --templates $THT \ -r $CNF/dcn01/dcn01_roles.yaml \ -n $CNF/dcn01/custom_network_data.yaml \ -e $CNF/dcn01/node-info.yaml \ -e $CNF/dcn01/scheduler-hints.yaml \ -e $CNF/dcn01/overcloud-networks-deployed.yaml \ -e $CNF/dcn01/vip-deployed-environment.yaml \ -e ~/containers-prepare-parameter.yaml \ -e $THT/environments/services/neutron-ovn-dvr-ha.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/podman.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/dcn-storage.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/cephadm/cephadm-rbd-only.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/nova-az-config.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/services/etcd.yaml \ -e $CNF/dcn01/dcn01_overcloud-baremetal-deployed.yaml \ -e $CNF/dcn01/glance_dcn01.yaml \ -e $CNF/dcn01/deployed_ceph.yaml \ -e $CNF/dcn01/dcn01_parameters.yaml \ -e $CNF/dcn01/overcloud-export.yaml \ -e $CNF/dcn01/clouddomain.yaml \ --ntp-server 172.25.201.68 -vv Can you please tell me what this issue could be? How to fix it? With regards, Swogat Pradhan

1 0

[neutron] Neutron drivers meeting
by Rodolfo Alonso Hernandez 27 Jan '23

27 Jan '23

Hello Neutrinos: This is just a reminder of the meeting we have today at 1400UTC. Please check today's agenda: https://wiki.openstack.org/wiki/Meetings/NeutronDrivers See you in IRC.

1 0

OpenInfra Live - Jan. 26 at 9 am CT / 15:00 UTC
by Kristin Barrientos 26 Jan '23

26 Jan '23

Hi everyone, This week’s OpenInfra Live episode is brought to you by the OpenStack Large Scale SIG. Episode: In the "Large Scale Ops Deep Dive" series, a panel of OpenStack operators invites special guests to talk about their deployment and discuss their operations. For this episode, our guests will be Benjamin Fuhrmann and Stanislav Dmitriev from Ubisoft, the famous video game publisher. Date and time: Jan. 26 at 9 a.m. CT (15:00 UTC) You can watch us live on: YouTube: https://youtu.be/H1DunJM1zoc <https://youtu.be/r8WLM9TM6w4> LinkedIn: https://www.linkedin.com/video/event/urn:li:ugcPost:7017187840652427264/ <https://www.linkedin.com/video/event/urn:li:ugcPost:7004177126690017280/> Facebook: https://www.facebook.com/events/835737927534901 <http://www.facebook.com/events/862505974941677> WeChat: recording will be posted on OpenStack WeChat after the live stream Speakers: Benjamin Fuhrmann, Stanislav Dmitriev, Felix Huettner, Arnaud Morin and Thierry Carrez Have an idea for a future episode? Share it now at ideas.openinfra.live. Thanks, Kristin Barrientos Marketing Coordinator OpenInfra Foundation

1 0

[oslo][ironic] oslo.service (and IPA) TLS v1.3
by Jay Faulkner 25 Jan '23

25 Jan '23

Hey all, Ironic Python Agent uses oslo.service's wsgi module as a wsgi server, with the built in TLS support from sslutils.py. This sslutils.py support only works up to TLS v1.2. It needs some enhancement. It was indicated to me in #openstack-oslo that there's nobody working on this module currently. I know that Ironic can't be the only consumer of this across OpenStack, so this is a call for interested parties and help. We have to update this to support modern TLS. It's not an option. I'd rather not do it alone -- who wants to help? I was tempted to put something up about this at the PTG; but I'm not sure it's significant enough to be worth that discussion so I'm starting here :). Thanks, Jay Faulkner Ironic PTL

2 1

[cinder] Bug Report from 01-25-2023
by Sofia Enriquez 25 Jan '23

25 Jan '23

This is a bug report from 01-18-2022 to 01-25-2023. Agenda: https://etherpad.opendev.org/p/cinder-bug-squad-meeting ----------------------------------------------------------------------------------------- Medium - https://bugs.launchpad.net/cinder/+bug/2003804 "Group actions enable, disable and failover replication can leave volume's replication status in transient states enabling, disabling and failing-over respectively." Fix proposed to master. Wishlist - https://bugs.launchpad.net/cinder/+bug/2003300 "[SVf] : Enable support for replication volume with mirror pool option." Fix proposed to master. Opinion - https://bugs.launchpad.net/cinder/+bug/2003245 "[HPE] cinder 3par FC driver not connecting to 3PAR storage." -- Sofía Enriquez she/her Software Engineer Red Hat PnT <https://www.redhat.com> IRC: @enriquetaso @RedHat <https://twitter.com/redhat> Red Hat <https://www.linkedin.com/company/red-hat> Red Hat <https://www.facebook.com/RedHatInc> <https://www.redhat.com>

1 0

[kolla-ansible] TASK [Link kolla_logs volume to /var/log/kolla] error after changing docker directory
by A Monster 25 Jan '23

25 Jan '23

THis occurred after I changed the default docker directory from /var/lib/docker to /custom_path because the /var partition's size is not sufficient TASK [common : Link kolla_logs volume to /var/log/kolla] ********************************************************************************************************************************************************** fatal: [Storage]: FAILED! => {"changed": false, "msg": "src file does not exist, use \"force=yes\" if you really want to create the link: /var/lib/docker/volumes/kolla_logs/_data", "path": "/var/log/kolla", "src": "/var/lib/docker/volumes/kolla_logs/_data"} knowing that the changes I made are for only this specific node, the default docker directory is used for the others, so is there a custom configuration I could do in globals.yml file, or add in a custom config file or is it that it's not possible to use custom working directories for docker?

1 0

Live Snapshot ERROR
by Kaiser Wassilij 25 Jan '23

25 Jan '23

Hi, I want to take a Live-snapshot. The instances are not switched off. Ubuntu 20.04 # Ansible managed DISTRIB_ID="OSA" DISTRIB_RELEASE="25.2.0" DISTRIB_CODENAME="Yoga" DISTRIB_DESCRIPTION="OpenStack-Ansible" nova-25.0.2.dev8.dist-info Compiled against library: libvirt 8.0.0 Using library: libvirt 8.0.0 Using API: QEMU 8.0.0 Running hypervisor: QEMU 4.2.1 ii apparmor 2.13.3-7ubuntu5.1 amd64 user-space parser utility for AppArmor I've also Adjusted virt-aa-helper: #include <tunables/global> profile virt-aa-helper /usr/lib/libvirt/virt-aa-helper flags=(complain) { #include <abstractions/base> #include <abstractions/openssl> # needed for searching directories capability dac_override, capability dac_read_search, # needed for when disk is on a network filesystem network inet, network inet6, deny @{PROC}/[0-9]*/mounts r, @{PROC}/[0-9]*/net/psched r, owner @{PROC}/[0-9]*/status r, @{PROC}/filesystems r, # Used when internally running another command (namely apparmor_parser) @{PROC}/@{pid}/fd/ r, # allow reading libnl's classid file /etc/libnl{,-3}/classid r, # for gl enabled graphics /dev/dri/{,*} r, # for hostdev /sys/devices/ r, /sys/devices/** r, /sys/bus/usb/devices/ r, deny /dev/sd* r, deny /dev/vd* r, deny /dev/dm-* r, deny /dev/drbd[0-9]* r, deny /dev/dasd* r, deny /dev/nvme* r, deny /dev/zd[0-9]* r, deny /dev/mapper/ r, deny /dev/mapper/* r, /usr/lib/libvirt/virt-aa-helper mr, /{usr/,}sbin/apparmor_parser Ux, /etc/apparmor.d/libvirt/* r, /etc/apparmor.d/libvirt/libvirt-[0-9a-f]*-[0-9a-f]*-[0-9a-f]*-[0-9a-f]*-[0-9a-f]* rw, # for backingstore -- allow access to non-hidden files in @{HOME} as well # as storage pools audit deny @{HOME}/.* mrwkl, audit deny @{HOME}/.*/ rw, audit deny @{HOME}/.*/** mrwkl, audit deny @{HOME}/bin/ rw, audit deny @{HOME}/bin/** mrwkl, @{HOME}/ r, @{HOME}/** r, /var/lib/libvirt/images/ rw, /var/lib/libvirt/images/** rw, # nova base images (LP: #907269 https://bugs.launchpad.net/bugs/907269 ) /var/lib/nova/images/** rw, /var/lib/nova/instances/_base/** rw, # nova snapshots (LP: #1244694 https://bugs.launchpad.net/bugs/1244694 ) /var/lib/nova/instances/snapshots/** rw, } Filesystem: OCFS2 [keystone_authtoken] insecure = False auth_type = password auth_url = www_authenticate_uri = project_domain_id = default user_domain_id = default project_name = service username = nova password = region_name = RegionOne service_token_roles_required = False service_token_roles = service service_type = compute memcached_servers = token_cache_time = 300 [libvirt] inject_partition = -2 inject_password = False inject_key = False virt_type = kvm live_migration_with_native_tls = true live_migration_scheme = tls live_migration_inbound_addr = xxx.xxx.xxx.xxx hw_disk_discard = ignore disk_cachemodes = iscsi_use_multipath = True Jan 25 09:46:07 bc2bl13 libvirtd[154472]: internal error: Child process (LIBVIRT_LOG_OUTPUTS=3:stderr /usr/lib/libvirt/virt-aa-helper -r -u libvirt-c6aa0368-8ae5-4fe4-8ae5-93a92329aa74) unexpected exit status 1: 2023-01-25 09:46:07.871+0000: 376129: info : libvirt version: 8.0.0, package: 1ubuntu7.1~cloud0 (Openstack Ubuntu Testing Bot <openstack-testing-bot(a)ubuntu.com> Wed, 25 May 2022 14:51:12 +0000) 2023-01-25 09:46:07.871+0000: 376129: info : hostname: bc2bl13 2023-01-25 09:46:07.871+0000: 376129: error : virDomainDiskDefMirrorParse:8800 : unsupported configuration: unknown mirror job type '' virt-aa-helper: error: could not parse XML virt-aa-helper: error: could not get VM definition Jan 25 09:46:07 bc2bl13 libvirtd[154472]: internal error: cannot update AppArmor profile 'libvirt-c6aa0368-8ae5-4fe4-8ae5-93a92329aa74' Jan 25 09:46:07 bc2bl13 libvirtd[154472]: Unable to restore security label on /var/lib/nova/instances/snapshots/tmpej9y72fr/c8d4bb94296746d6bff6b747386b4a90.delta

1 0

Live Snapshot
by Kaiser Wassilij 25 Jan '23

25 Jan '23

Hi, I want to take a Live-snapshot. The instances are not switched off. Ubuntu 20.04 # Ansible managed DISTRIB_ID="OSA" DISTRIB_RELEASE="25.2.0" DISTRIB_CODENAME="Yoga" DISTRIB_DESCRIPTION="OpenStack-Ansible" nova-25.0.2.dev8.dist-info Compiled against library: libvirt 8.0.0 Using library: libvirt 8.0.0 Using API: QEMU 8.0.0 Running hypervisor: QEMU 4.2.1 ii apparmor 2.13.3-7ubuntu5.1 amd64 user-space parser utility for AppArmor I've also Adjusted virt-aa-helper: #include <tunables/global> profile virt-aa-helper /usr/lib/libvirt/virt-aa-helper flags=(complain) { #include <abstractions/base> #include <abstractions/openssl> # needed for searching directories capability dac_override, capability dac_read_search, # needed for when disk is on a network filesystem network inet, network inet6, deny @{PROC}/[0-9]*/mounts r, @{PROC}/[0-9]*/net/psched r, owner @{PROC}/[0-9]*/status r, @{PROC}/filesystems r, # Used when internally running another command (namely apparmor_parser) @{PROC}/@{pid}/fd/ r, # allow reading libnl's classid file /etc/libnl{,-3}/classid r, # for gl enabled graphics /dev/dri/{,*} r, # for hostdev /sys/devices/ r, /sys/devices/** r, /sys/bus/usb/devices/ r, deny /dev/sd* r, deny /dev/vd* r, deny /dev/dm-* r, deny /dev/drbd[0-9]* r, deny /dev/dasd* r, deny /dev/nvme* r, deny /dev/zd[0-9]* r, deny /dev/mapper/ r, deny /dev/mapper/* r, /usr/lib/libvirt/virt-aa-helper mr, /{usr/,}sbin/apparmor_parser Ux, /etc/apparmor.d/libvirt/* r, /etc/apparmor.d/libvirt/libvirt-[0-9a-f]*-[0-9a-f]*-[0-9a-f]*-[0-9a-f]*-[0-9a-f]* rw, # for backingstore -- allow access to non-hidden files in @{HOME} as well # as storage pools audit deny @{HOME}/.* mrwkl, audit deny @{HOME}/.*/ rw, audit deny @{HOME}/.*/** mrwkl, audit deny @{HOME}/bin/ rw, audit deny @{HOME}/bin/** mrwkl, @{HOME}/ r, @{HOME}/** r, /var/lib/libvirt/images/ rw, /var/lib/libvirt/images/** rw, # nova base images (LP: #907269 https://bugs.launchpad.net/bugs/907269 ) /var/lib/nova/images/** rw, /var/lib/nova/instances/_base/** rw, # nova snapshots (LP: #1244694 https://bugs.launchpad.net/bugs/1244694 ) /var/lib/nova/instances/snapshots/** rw, } Filesystem: OCFS2 [keystone_authtoken] insecure = False auth_type = password auth_url = www_authenticate_uri = project_domain_id = default user_domain_id = default project_name = service username = nova password = region_name = RegionOne service_token_roles_required = False service_token_roles = service service_type = compute memcached_servers = token_cache_time = 300 [libvirt] inject_partition = -2 inject_password = False inject_key = False virt_type = kvm live_migration_with_native_tls = true live_migration_scheme = tls live_migration_inbound_addr = xxx.xxx.xxx.xxx hw_disk_discard = ignore disk_cachemodes = iscsi_use_multipath = True Jan 25 09:46:07 bc2bl13 libvirtd[154472]: internal error: Child process (LIBVIRT_LOG_OUTPUTS=3:stderr /usr/lib/libvirt/virt-aa-helper -r -u libvirt-c6aa0368-8ae5-4fe4-8ae5-93a92329aa74) unexpected exit status 1: 2023-01-25 09:46:07.871+0000: 376129: info : libvirt version: 8.0.0, package: 1ubuntu7.1~cloud0 (Openstack Ubuntu Testing Bot <openstack-testing-bot(a)ubuntu.com> Wed, 25 May 2022 14:51:12 +0000) 2023-01-25 09:46:07.871+0000: 376129: info : hostname: bc2bl13 2023-01-25 09:46:07.871+0000: 376129: error : virDomainDiskDefMirrorParse:8800 : unsupported configuration: unknown mirror job type '' virt-aa-helper: error: could not parse XML virt-aa-helper: error: could not get VM definition Jan 25 09:46:07 bc2bl13 libvirtd[154472]: internal error: cannot update AppArmor profile 'libvirt-c6aa0368-8ae5-4fe4-8ae5-93a92329aa74' Jan 25 09:46:07 bc2bl13 libvirtd[154472]: Unable to restore security label on /var/lib/nova/instances/snapshots/tmpej9y72fr/c8d4bb94296746d6bff6b747386b4a90.delta

1 0

Retiring untested and unmaintained modules (murano, rally and tacker)
by Takashi Kajinami 25 Jan '23

25 Jan '23

Hello, In Puppet OpenStack projects we have multiple modules to support multiple OpenStack components. However unfortunately some of these have not been attracting enough interest from developers and have been unmaintained. During the past few cycles we retired a few incomplete modules but I'm wondering if we can retire a few unmaintained modules now, to reduce our maintenance/release effort. I checked the modules we have currently, and I think the following three can be first candidates. - puppet-murano - puppet-rally - puppet-tacker We haven't seen any feedback from users about these modules for a long time. Most of the changes for the past 2~3 years are proposed by me but I am not really using these components. These modules do not have proper test coverage and it's quite difficult for us to catch any breakage and honestly I'm not quite sure these modules can work properly with the latest code. Actually we've often caught up with the latest requirements several years after the change was made in the software side, and I'm afraid these are not well-maintained. eg. - support for tacker-conductor was added 4 years after the service was added - we didn't noticed that the openstack plugin was split out from the core rally package for several years If anybody has concerns with retiring these modules, then please let us know. If we don't hear any objections for a while, then I'll start proposing changes for project retirement. Thank you, Takashi -- ---------- Takashi Kajinami

1 1

[all][tc] Technical Committee next weekly meeting on 2023 Jan 25 at 1600 UTC
by Ghanshyam Mann 25 Jan '23

25 Jan '23

Hello Everyone, The technical Committee's next weekly meeting is scheduled for 2023 Jan 25, at 1600 UTC. If you would like to add topics for discussion, please add them to the below wiki page by Tuesday, Jan 24 at 2100 UTC. https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting -gmann

1 1

openstack client integration to fetch and provide OIDC access tokens (v3oidcaccesstoken)?
by Christian Rohmann 25 Jan '23

25 Jan '23

Hey openstack-discuss, while there is support for OpenID Connect and its various flows in the openstack client (https://docs.openstack.org/python-openstackclient/latest/cli/man/openstack.…) I would like to have the user authenticate only with central IdP login via a web page and then receive an access token and not have each user's openstack cli be a full OIDC client handling credentials and authenticating against the IdP via the users password itself. The tricky bit here is having good tooling for users to authenticate via the existing SSO and then to get and refresh tokens which are then fed to the openstack CLI. I was wondering if anybody knows of some nice integrations / plugins / hooks to make it easy for users to deal with the authentication (usually via some web site) and then to inject the token (v3oidcaccesstoken) into openstack-cli? I found that Fedcloud.eu (https://www.fedcloud.eu/) does something like this (see https://fedcloudclient.fedcloud.eu/usage.html#authentication) via OIDC-Agent. But most platforms making use of OIDC seem to configure the openstack client with client_id and secret and have it authenticate directly with the IdP. Regards, Christian

3 5

podman manifest error | status 404 | openstack wallaby
by Swogat Pradhan 24 Jan '23

24 Jan '23

Hi, I am currently trying DCN for my openstack and when running the deployment command for the edge site i am getting the following error: FATAL | Pre-fetch all the containers | dcn01-hci-0 | item= 172.25.201.68:8787/tripleomaster/openstack-etcd:current-tripleo | error={"ansible_loop_var": "prefetch_image", "changed": false, "msg": "Failed to pull image 172.25.201.68:8787/tripleomaster/openstack-etcd:current-tripleo", "prefetch_image": " 172.25.201.68:8787/tripleomaster/openstack-etcd:current-tripleo"} Can someone please guide me on how to fix this issue? With regards, Swogat Pradhan

1 0

[Glance] No weekly meeting this week
by Pranali Deore 24 Jan '23

24 Jan '23

Hello, Thursday, 26th Jan is public holiday in India and almost half of the team will not be around, so cancelling glance weekly meeting for this week. Thanks & Regards, Pranali

1 0

[horizon][xstatic] xstatic-font-awesome and xstatic-jquery.tablesorter leaving OpenStack
by Radomir Dopieralski 24 Jan '23

24 Jan '23

Hi everyone, a few years ago we have a adopted under the OpenStack umbrella a number of xstatic packages used by Horizon and its plugins, because they seemed to be unmaintained at the time, and we needed to keep them secure. A few weeks ago one of those packages, xstatic-font-awesome, got a new release by its original authors – the good people at the MoinMoin Wiki project, where the XStatic mechanism originated. That surprised us a little, and raised some concerns, since the release wasn't done using the OpenStack process, so we reached out to clear this situation. After discussion, we have decided to remove two xstatic packages: xstatic-font-awesome and xstatic-jquery.tablesorter from the OpenStack repositories and let them be maintained by the MoinMoin Wiki contributors instead, together with many other xstatic packages they use, so that there is no more confusion about who is responsible for them. We will continue to use pinned versions of those packages in Horizon, but we will no longer keep them as part of the OpenStack project. We will start the retirement process on the repositories for those packages shortly. -- Radomir Dopieralski

1 0

[charms] Release of charmhub Openstack dedicated ussuri, victoria, wallaby for Ubuntu 20.04 (focal) LTS
by Alex Kavanagh 24 Jan '23

24 Jan '23

Hello As the charm-guide [1] explains, OpenStack, Ceph, OVN and supporting charms moved from a single stable charm (for each OpenStack component) that supported multiple OpenStack releases, to individual tracks that each targets a specific release [2]. The current Zed release also recently [6] became stable. Today, we have (re)released updated individual charms to the ussuri/stable, victoria/stable and wallaby/stable tracks. These are derived from the stable 21.10 charms (that supported queens -> xena). We have also released the Ceph octopus/stable track to support ussuri and victoria, and the existing Ceph pacific (which was already stable) that supports wallaby (and xena). The full list of charms for the Xena, Victoria and Wallaby OpenStack systems, includiong Ceph, OVN, mysql8, hacluster, rabbitmq-server, vault and others can be seen in the docs at [3]. The ussuri, victoria, wallaby, and xena tracks have been designed to be upgradable from the 21.10 charms if you are running the associated OpenStack version, but please do read the docs [4] about how to go about upgrading charms. The relevant track (e.g. victoria/stable) is also able to upgrade from the previous version. Please again consult the docs [5] for upgrading advice. This was a significant piece of work by all those involved, so many, many thanks to all who contributed and made this happen! Thanks! [1] https://docs.openstack.org/charm-guide/latest/project/charm-delivery.html [2] https://juju.is/docs/olm/deploy-a-charm-from-charmhub#heading--specify-a-ch… [3] https://docs.openstack.org/charm-guide/latest/project/charm-delivery.html#c… [4] https://docs.openstack.org/project-deploy-guide/charm-deployment-guide/late… [5] https://docs.openstack.org/project-deploy-guide/charm-deployment-guide/late… [6] https://lists.openstack.org/pipermail/openstack-discuss/2023-January/031872… -- Alex Kavanagh OpenStack Engineering - Canonical Ltd

1 0

[neutron] CI meeting 24.01.2023 cancelled
by Slawek Kaplonski 24 Jan '23

24 Jan '23

Hi, Due to overlapping internal meeting this week I will not be able to chair neutron ci meeting. There is nothing critical to discuss there so with Rodolfo we decided to cancel that meeting this week. See You all on the CI meeting next week. -- Slawek Kaplonski Principal Software Engineer Red Hat

1 0

Error Nova Compute during snapshot
by Kaiser Wassilij 24 Jan '23

24 Jan '23

Hi, I start creating snapshot. Wherever the instance is, I start journalctl -f . The following error occurs in libvirtd # Ansible managed DISTRIB_ID="OSA" DISTRIB_RELEASE="25.2.0" DISTRIB_CODENAME="Yoga" DISTRIB_DESCRIPTION="OpenStack-Ansible" internal error: cannot update AppArmor profile 'libvirt-c6aa0368-8ae5-4fe4-8ae5-93a92329aa74' Jan 23 16:04:42 bc2bl13 libvirtd[1321612]: Unable to restore security label on /var/lib/nova/instances/snapshots/tmpyhucdu8x/37698cb66b8a44599601c5166902552c.delta Jan 23 16:09:37 bc2bl13 libvirtd[1321612]: invalid argument: disk vda does not have an active block job Jan 23 16:09:46 bc2bl13 libvirtd[1321612]: internal error: Child process (LIBVIRT_LOG_OUTPUTS=3:stderr /usr/lib/libvirt/virt-aa-helper -r -u libvirt-c6aa0368-8ae5-4fe4-8ae5-93a92329aa74) unexpected exit status 1: 2023-01-23 16:09:46.640+0000: 3744159: info : libvirt version: 8.0.0, package: 1ubuntu7.1~cloud0 (Openstack Ubuntu Testing Bot <openstack-testing-bot(a)ubuntu.com> Wed, 25 May 2023 libvirt version: 8.0.0, package: 1ubuntu7.1~cloud0 (Openstack Ubuntu Testing Bot <openstack-testing-bot(a)ubuntu.com> Wed, 25 May 2022 14:51:12 +0000) 2023-01-23 16:09:46.640+0000: 3744159: info : hostname: bc2bl13 2023-01-23 16:09:46.640+0000: 3744159: error : virDomainDiskDefMirrorParse:8800 : unsupported configuration: unknown mirror job type '' virt-aa-helper: error: could not parse XML virt-aa-helper: error: could not get VM definition Jan 23 16:09:46 bc2bl13 libvirtd[1321612]: internal error: cannot update AppArmor profile 'libvirt-c6aa0368-8ae5-4fe4-8ae5-93a92329aa74' Jan 23 16:09:46 bc2bl13 libvirtd[1321612]: Unable to restore security label on /var/lib/nova/instances/snapshots/tmp_a9upl2m/d3d15a89bd6a4dcb8255cfe50d2adb68.delta Jan 24 09:17:56 bc2bl13 libvirtd[1321612]: invalid argument: disk vda does not have an active block job Jan 24 09:18:09 bc2bl13 libvirtd[1321612]: internal error: Child process (LIBVIRT_LOG_OUTPUTS=3:stderr /usr/lib/libvirt/virt-aa-helper -r -u libvirt-c6aa0368-8ae5-4fe4-8ae5-93a92329aa74) unexpected exit status 1: 2023-01-24 09:18:09.865+0000: 4081179: info : info : libvirt version: 8.0.0, package: 1ubuntu7.1~cloud0 (Openstack Ubuntu Testing Bot <openstack-testing-bot(a)ubuntu.com> Wed, 25 May 2023 libvirt version: 8.0.0, package: 1ubuntu7.1~cloud0 (Openstack Ubuntu Testing Bot <openstack-testing-bot(a)ubuntu.com> Wed, 25 May 2022 14:51:12 +0000) 2023-01-24 09:18:09.865+0000: 4081179: info : hostname: bc2bl13 2023-01-24 09:18:09.865+0000: 4081179: error : virDomainDiskDefMirrorParse:8800 : unsupported configuration: unknown mirror job type '' virt-aa-helper: error: could not parse XML virt-aa-helper: error: could not get VM definition Jan 24 09:18:09 bc2bl13 libvirtd[1321612]: internal error: cannot update AppArmor profile 'libvirt-c6aa0368-8ae5-4fe4-8ae5-93a92329aa74' Jan 24 09:18:09 bc2bl13 libvirtd[1321612]: Unable to restore security label on /var/lib/nova/instances/snapshots/tmpv4gdu8fe/b0b8a1ac3ea64e3ca74363175cc17bd4.delta has anyone had the same error. What have you done?

1 0

[ironic] moving on
by Ruby Loo 24 Jan '23

24 Jan '23

Hi ironic'ers, I'm moving on to a non-Ironic, non-OpenStack world. I'm glad to have been on this journey. The ironic community has been, and continues to be, great -- welcoming and helpful. Keep up the great work and the big visions [1]. I look forward to Ironic taking over the world ;) Thanks to everyone that I encountered; YOU are what made it so special and fun! --ruby [1] https://docs.openstack.org/ironic/latest/contributor/vision.html

3 2

Snapshots disappear during saving
by Karera Tony 24 Jan '23

24 Jan '23

Dear Team, I am using Openstack Wallaby deployed using kolla-ansible. I installed Glance with the ceph backend and all was well. However when I create snapshots, they disappear when they are saved. Any idea on how to resolve this? Regards Tony Karera

2 4

Instance Snapshots disappear while being saved
by Karera Tony 24 Jan '23

24 Jan '23

Dear Team, I have deployed Openstack Wallby using kolla-ansible. I faced no challenge during the Installation. However when I create an instance snapshot, It disappears while being saved and below are the glance logs that seem to show errors. The Glance_backend_storage is ceph. Please assist 24/Jan/2023 06:25:10] "GET /v2/images?limit=1000&sort_key=created_at&sort_dir=desc HTTP/1.1" 200 5995 0.058022 2023-01-24 06:25:12.381 50 INFO glance.api.v2.image_data [req-7eebf051-b8b0-4dff-9b7e-8d5085d77b5d f75f32a3c1fd4cf68cdb7b76d70ee9a8 bf5353fb17604156b492d5a7f00992ff - default default] Unable to create trust: no such option collect_timing in group [keystone_authtoken] Use the existing user token. 2023-01-24 06:25:12.470 50 WARNING glance_store._drivers.rbd [req-7eebf051-b8b0-4dff-9b7e-8d5085d77b5d f75f32a3c1fd4cf68cdb7b76d70ee9a8 bf5353fb17604156b492d5a7f00992ff - default default] Since image size is zero we will be doing resize-before-write which will be slower than normal 2023-01-24 06:25:13.010 51 INFO eventlet.wsgi.server [req-b91e54ba-f3fa-4fad-ab7a-1ef1ad2750fb f75f32a3c1fd4cf68cdb7b76d70ee9a8 bf5353fb17604156b492d5a7f00992ff - default default] 10.10.13.27,10.10.13.28 - - [24/Jan/2023 06:25:13] "GET /v2/schemas/image HTTP/1.1" 200 6259 0.008496 2023-01-24 06:25:15.657 52 INFO eventlet.wsgi.server [req-c9fa16c8-232d-45ff-b425-55504f332597 f75f32a3c1fd4cf68cdb7b76d70ee9a8 bf5353fb17604156b492d5a7f00992ff - default default] 10.10.13.27,10.10.13.28 - - [24/Jan/2023 06:25:15] "GET /v2/schemas/image HTTP/1.1" 200 6259 0.008760 2023-01-24 06:25:16.404 50 ERROR glance_store._drivers.rbd [req-7eebf051-b8b0-4dff-9b7e-8d5085d77b5d f75f32a3c1fd4cf68cdb7b76d70ee9a8 bf5353fb17604156b492d5a7f00992ff - default default] Failed to store image 57e5c3ee-6576-4cf7-a72a-2038c86456bc Store Exception invalid literal for int() with base 16: b'': eventlet.wsgi.ChunkReadError: invalid literal for int() with base 16: b'' 2023-01-24 06:25:16.629 50 ERROR glance.api.v2.image_data [req-7eebf051-b8b0-4dff-9b7e-8d5085d77b5d f75f32a3c1fd4cf68cdb7b76d70ee9a8 bf5353fb17604156b492d5a7f00992ff - default default] Failed to upload image data due to HTTP error: webob.exc.HTTPBadRequest: invalid literal for int() with base 16: b'' 2023-01-24 06:25:16.697 50 INFO eventlet.wsgi.server [req-7eebf051-b8b0-4dff-9b7e-8d5085d77b5d f75f32a3c1fd4cf68cdb7b76d70ee9a8 bf5353fb17604156b492d5a7f00992ff - default default] Traceback (most recent call last): File "/var/lib/kolla/venv/lib/python3.8/site-packages/eventlet/wsgi.py", line 604, in handle_one_response write(b''.join(towrite)) File "/var/lib/kolla/venv/lib/python3.8/site-packages/eventlet/wsgi.py", line 538, in write wfile.flush() File "/usr/lib/python3.8/socket.py", line 687, in write return self._sock.send(b) File "/var/lib/kolla/venv/lib/python3.8/site-packages/eventlet/greenio/base.py", line 396, in send return self._send_loop(self.fd.send, data, flags) File "/var/lib/kolla/venv/lib/python3.8/site-packages/eventlet/greenio/base.py", line 383, in _send_loop return send_method(data, *args) BrokenPipeError: [Errno 32] Broken pipe 2023-01-24 06:25:16.697 50 INFO eventlet.wsgi.server [req-7eebf051-b8b0-4dff-9b7e-8d5085d77b5d f75f32a3c1fd4cf68cdb7b76d70ee9a8 bf5353fb17604156b492d5a7f00992ff - default default] 10.10.13.30,10.10.13.28 - - [24/Jan/2023 06:25:16] "PUT /v2/images/57e5c3ee-6576-4cf7-a72a-2038c86456bc/file HTTP/1.1" 400 0 4.384073 2023-01-24 06:25:18.281 49 INFO eventlet.wsgi.server [req-dcd70adf-5dd4-4a15-abe0-f1e074030346 f75f32a3c1fd4cf68cdb7b76d70ee9a8 bf5353fb17604156b492d5a7f00992ff - default default] 10.10.13.27,10.10.13.28 - - [24/Jan/2023 06:25:18] "GET /v2/images?limit=1000&sort_key=created_at&sort_dir=desc HTTP/1.1" 200 5995 0.067056 2023-01-24 06:25:20.935 52 INFO eventlet.wsgi.server [req-065021ef-2fa4-456f-bad8-22e4a06fec9a f75f32a3c1fd4cf68cdb7b76d70ee9a8 bf5353fb17604156b492d5a7f00992ff - default default] 10.10.13.27,10.10.13.28 - - [24/Jan/2023 06:25:20] "GET /v2/images?limit=1000&sort_key=created_at&sort_dir=desc HTTP/1.1" 200 5995 0.064581 2023-01-24 06:25:23.367 50 INFO eventlet.wsgi.server [-] 10.10.13.27 - - [24/Jan/2023 06:25:23] "GET / HTTP/1.1" 300 1517 0.003469 2023-01-24 06:25:23.583 51 INFO eventlet.wsgi.server [req-a0a51dc6-01c5-4dff-afe9-6c67a279e7fa f75f32a3c1fd4cf68cdb7b76d70ee9a8 bf5353fb17604156b492d5a7f00992ff - default default] 10.10.13.27,10.10.13.28 - - [24/Jan/2023 06:25:23] "GET /v2/images?limit=1000&sort_key=created_at&sort_dir=desc HTTP/1.1" 200 5995 0.072727 2023-01-24 06:25:26.211 49 INFO eventlet.wsgi.server [req-052bc425-90c3-4e4e-94e3-15aba795c96b f75f32a3c1fd4cf68cdb7b76d70ee9a8 bf5353fb17604156b492d5a7f00992ff - default default] 10.10.13.27,10.10.13.28 - - [24/Jan/2023 06:25:26] "GET /v2/images?limit=1000&sort_key=created_at&sort_dir=desc HTTP/1.1" 200 5995 0.055309 2023-01-24 06:25:28.039 49 INFO glance.api.v2.image_data [req-7eebf051-b8b0-4dff-9b7e-8d5085d77b5d f75f32a3c1fd4cf68cdb7b76d70ee9a8 bf5353fb17604156b492d5a7f00992ff - default default] Unable to create trust: no such option collect_timing in group [keystone_authtoken] Use the existing user token. 2023-01-24 06:25:28.168 49 WARNING glance_store._drivers.rbd [req-7eebf051-b8b0-4dff-9b7e-8d5085d77b5d f75f32a3c1fd4cf68cdb7b76d70ee9a8 bf5353fb17604156b492d5a7f00992ff - default default] Since image size is zero we will be doing resize-before-write which will be slower than normal 2023-01-24 06:25:28.887 51 INFO eventlet.wsgi.server [req-4664a441-2fa6-41fa-b985-b6290712e597 f75f32a3c1fd4cf68cdb7b76d70ee9a8 bf5353fb17604156b492d5a7f00992ff - default default] 10.10.13.27,10.10.13.28 - - [24/Jan/2023 06:25:28] "GET /v2/schemas/image HTTP/1.1" 200 6259 0.008411 2023-01-24 06:25:31.541 52 INFO eventlet.wsgi.server [req-31a7d4fc-a266-40a7-9b0d-6ba1e8c0cf47 f75f32a3c1fd4cf68cdb7b76d70ee9a8 bf5353fb17604156b492d5a7f00992ff - default default] 10.10.13.27,10.10.13.28 - - [24/Jan/2023 06:25:31] "GET /v2/schemas/image HTTP/1.1" 200 6259 0.008032 2023-01-24 06:25:34.168 52 INFO eventlet.wsgi.server [req-d8e4513e-9945-4f0c-9b2d-a1e191982f0b f75f32a3c1fd4cf68cdb7b76d70ee9a8 bf5353fb17604156b492d5a7f00992ff - default default] 10.10.13.27,10.10.13.28 - - [24/Jan/2023 06:25:34] "GET /v2/schemas/image HTTP/1.1" 200 6259 0.009528 2023-01-24 06:25:36.798 52 INFO eventlet.wsgi.server [req-02c6e354-6137-4f31-9cf3-a2e9c0258938 f75f32a3c1fd4cf68cdb7b76d70ee9a8 bf5353fb17604156b492d5a7f00992ff - default default] 10.10.13.27,10.10.13.28 - - [24/Jan/2023 06:25:36] "GET /v2/schemas/image HTTP/1.1" 200 6259 0.008272 2023-01-24 06:25:39.435 50 INFO eventlet.wsgi.server [req-a30d0de8-9b34-414f-81ef-9a3457cf2758 f75f32a3c1fd4cf68cdb7b76d70ee9a8 bf5353fb17604156b492d5a7f00992ff - default default] 10.10.13.27,10.10.13.28 - - [24/Jan/2023 06:25:39] "GET /v2/schemas/image HTTP/1.1" 200 6259 0.008886 2023-01-24 06:25:42.059 52 INFO eventlet.wsgi.server [req-409a24f7-7d8e-4bb8-8cab-ef730cf35478 f75f32a3c1fd4cf68cdb7b76d70ee9a8 bf5353fb17604156b492d5a7f00992ff - default default] 10.10.13.27,10.10.13.28 - - [24/Jan/2023 06:25:42] "GET /v2/schemas/image HTTP/1.1" 200 6259 0.008929 2023-01-24 06:25:44.709 52 INFO eventlet.wsgi.server [req-ebee0818-8afe-488e-a9f2-52bcdfb65983 f75f32a3c1fd4cf68cdb7b76d70ee9a8 bf5353fb17604156b492d5a7f00992ff - default default] 10.10.13.27,10.10.13.28 - - [24/Jan/2023 06:25:44] "GET /v2/schemas/image HTTP/1.1" 200 6259 0.008267 2023-01-24 06:25:47.346 52 INFO eventlet.wsgi.server [req-71ad7a1a-acee-40f1-a3ed-70fe64428644 f75f32a3c1fd4cf68cdb7b76d70ee9a8 bf5353fb17604156b492d5a7f00992ff - default default] 10.10.13.27,10.10.13.28 - - [24/Jan/2023 06:25:47] "GET /v2/schemas/image HTTP/1.1" 200 6259 0.008255 2023-01-24 06:25:50.005 50 INFO eventlet.wsgi.server [req-a69f1a44-7689-494c-9e84-c434a1ea9838 f75f32a3c1fd4cf68cdb7b76d70ee9a8 bf5353fb17604156b492d5a7f00992ff - default default] 10.10.13.27,10.10.13.28 - - [24/Jan/2023 06:25:50] "GET /v2/schemas/image HTTP/1.1" 200 6259 0.008565 2023-01-24 06:25:52.631 50 INFO eventlet.wsgi.server [req-08c7e2db-c60e-4cfe-ab0e-78269924f60d f75f32a3c1fd4cf68cdb7b76d70ee9a8 bf5353fb17604156b492d5a7f00992ff - default default] 10.10.13.27,10.10.13.28 - - [24/Jan/2023 06:25:52] "GET /v2/schemas/image HTTP/1.1" 200 6259 0.008409 2023-01-24 06:25:53.521 48 INFO eventlet.wsgi.server [-] 10.10.13.27 - - [24/Jan/2023 06:25:53] "GET / HTTP/1.1" 300 1517 0.001898 2023-01-24 06:25:55.271 51 INFO eventlet.wsgi.server [req-63d5645d-c9dc-4ec4-86b6-48305b05ebe8 f75f32a3c1fd4cf68cdb7b76d70ee9a8 bf5353fb17604156b492d5a7f00992ff - default default] 10.10.13.27,10.10.13.28 - - [24/Jan/2023 06:25:55] "GET /v2/schemas/image HTTP/1.1" 200 6259 0.005122 2023-01-24 06:25:57.911 50 INFO eventlet.wsgi.server [req-67b0f1e9-89a1-4e34-8f95-132f32f9c478 f75f32a3c1fd4cf68cdb7b76d70ee9a8 bf5353fb17604156b492d5a7f00992ff - default default] 10.10.13.27,10.10.13.28 - - [24/Jan/2023 06:25:57] "GET /v2/schemas/image HTTP/1.1" 200 6259 0.009235 2023-01-24 06:26:00.554 48 INFO eventlet.wsgi.server [req-cc7033b2-698b-4bd5-96cf-589d864485ff f75f32a3c1fd4cf68cdb7b76d70ee9a8 bf5353fb17604156b492d5a7f00992ff - default default] 10.10.13.27,10.10.13.28 - - [24/Jan/2023 06:26:00] "GET /v2/schemas/image HTTP/1.1" 200 6259 0.008637 2023-01-24 06:26:03.181 50 INFO eventlet.wsgi.server [req-26a2b823-8a26-49b8-9d79-af6bf36c0e2a f75f32a3c1fd4cf68cdb7b76d70ee9a8 bf5353fb17604156b492d5a7f00992ff - default default] 10.10.13.27,10.10.13.28 - - [24/Jan/2023 06:26:03] "GET /v2/schemas/image HTTP/1.1" 200 6259 0.007718 2023-01-24 06:26:05.835 50 INFO eventlet.wsgi.server [req-1be8a06e-6c3a-4966-9031-a1548b6b0f7a f75f32a3c1fd4cf68cdb7b76d70ee9a8 bf5353fb17604156b492d5a7f00992ff - default default] 10.10.13.27,10.10.13.28 - - [24/Jan/2023 06:26:05] "GET /v2/schemas/image HTTP/1.1" 200 6259 0.008469 2023-01-24 06:26:08.483 50 INFO eventlet.wsgi.server [req-b24990c6-319d-4837-8128-406f49d38530 f75f32a3c1fd4cf68cdb7b76d70ee9a8 bf5353fb17604156b492d5a7f00992ff - default default] 10.10.13.27,10.10.13.28 - - [24/Jan/2023 06:26:08] "GET /v2/schemas/image HTTP/1.1" 200 6259 0.008319 2023-01-24 06:26:11.134 50 INFO eventlet.wsgi.server [req-5393b80e-5069-47ee-a1f0-ef7174c1e09b f75f32a3c1fd4cf68cdb7b76d70ee9a8 bf5353fb17604156b492d5a7f00992ff - default default] 10.10.13.27,10.10.13.28 - - [24/Jan/2023 06:26:11] "GET /v2/schemas/image HTTP/1.1" 200 6259 0.008237 2023-01-24 06:26:13.765 50 INFO eventlet.wsgi.server [req-fcbc3f21-ddb5-4b3f-869c-b489ace9a453 f75f32a3c1fd4cf68cdb7b76d70ee9a8 bf5353fb17604156b492d5a7f00992ff - default default] 10.10.13.27,10.10.13.28 - - [24/Jan/2023 06:26:13] "GET /v2/schemas/image HTTP/1.1" 200 6259 0.008331 2023-01-24 06:26:16.405 52 INFO eventlet.wsgi.server [req-20d98cec-4e1e-4582-aaa2-68043927ab7f f75f32a3c1fd4cf68cdb7b76d70ee9a8 bf5353fb17604156b492d5a7f00992ff - default default] 10.10.13.27,10.10.13.28 - - [24/Jan/2023 06:26:16] "GET /v2/schemas/image HTTP/1.1" 200 6259 0.008366 2023-01-24 06:26:19.028 50 INFO eventlet.wsgi.server [req-2f1bc312-00b8-4e92-91ac-a3ba1f951742 f75f32a3c1fd4cf68cdb7b76d70ee9a8 bf5353fb17604156b492d5a7f00992ff - default default] 10.10.13.27,10.10.13.28 - - [24/Jan/2023 06:26:19] "GET /v2/schemas/image HTTP/1.1" 200 6259 0.008365 2023-01-24 06:26:20.032 49 ERROR glance_store._drivers.rbd [req-7eebf051-b8b0-4dff-9b7e-8d5085d77b5d f75f32a3c1fd4cf68cdb7b76d70ee9a8 bf5353fb17604156b492d5a7f00992ff - default default] Failed to store image 57e5c3ee-6576-4cf7-a72a-2038c86456bc Store Exception unexpected end of file while parsing chunked data: OSError: unexpected end of file while parsing chunked data 2023-01-24 06:26:20.443 49 ERROR glance.api.v2.image_data [req-7eebf051-b8b0-4dff-9b7e-8d5085d77b5d f75f32a3c1fd4cf68cdb7b76d70ee9a8 bf5353fb17604156b492d5a7f00992ff - default default] Failed to upload image data due to internal error: OSError: unexpected end of file while parsing chunked data 2023-01-24 06:26:20.563 49 ERROR glance.common.wsgi [req-7eebf051-b8b0-4dff-9b7e-8d5085d77b5d f75f32a3c1fd4cf68cdb7b76d70ee9a8 bf5353fb17604156b492d5a7f00992ff - default default] Caught error: unexpected end of file while parsing chunked data: OSError: unexpected end of file while parsing chunked data 2023-01-24 06:26:20.563 49 ERROR glance.common.wsgi Traceback (most recent call last): 2023-01-24 06:26:20.563 49 ERROR glance.common.wsgi File "/var/lib/kolla/venv/lib/python3.8/site-packages/glance/common/wsgi.py", line 1353, in __call__ 2023-01-24 06:26:20.563 49 ERROR glance.common.wsgi action_result = self.dispatch(self.controller, action, 2023-01-24 06:26:20.563 49 ERROR glance.common.wsgi File "/var/lib/kolla/venv/lib/python3.8/site-packages/glance/common/wsgi.py", line 1397, in dispatch 2023-01-24 06:26:20.563 49 ERROR glance.common.wsgi return method(*args, **kwargs) 2023-01-24 06:26:20.563 49 ERROR glance.common.wsgi File "/var/lib/kolla/venv/lib/python3.8/site-packages/glance/common/utils.py", line 416, in wrapped 2023-01-24 06:26:20.563 49 ERROR glance.common.wsgi return func(self, req, *args, **kwargs) 2023-01-24 06:26:20.563 49 ERROR glance.common.wsgi File "/var/lib/kolla/venv/lib/python3.8/site-packages/glance/api/v2/image_data.py", line 300, in upload 2023-01-24 06:26:20.563 49 ERROR glance.common.wsgi self._restore(image_repo, image) 2023-01-24 06:26:20.563 49 ERROR glance.common.wsgi File "/var/lib/kolla/venv/lib/python3.8/site-packages/oslo_utils/excutils.py", line 227, in __exit__ 2023-01-24 06:26:20.563 49 ERROR glance.common.wsgi self.force_reraise() 2023-01-24 06:26:20.563 49 ERROR glance.common.wsgi File "/var/lib/kolla/venv/lib/python3.8/site-packages/oslo_utils/excutils.py", line 200, in force_reraise 2023-01-24 06:26:20.563 49 ERROR glance.common.wsgi raise self.value 2023-01-24 06:26:20.563 49 ERROR glance.common.wsgi File "/var/lib/kolla/venv/lib/python3.8/site-packages/glance/api/v2/image_data.py", line 165, in upload 2023-01-24 06:26:20.563 49 ERROR glance.common.wsgi image.set_data(data, size, backend=backend) 2023-01-24 06:26:20.563 49 ERROR glance.common.wsgi File "/var/lib/kolla/venv/lib/python3.8/site-packages/glance/domain/proxy.py", line 208, in set_data 2023-01-24 06:26:20.563 49 ERROR glance.common.wsgi self.base.set_data(data, size, backend=backend, set_active=set_active) 2023-01-24 06:26:20.563 49 ERROR glance.common.wsgi File "/var/lib/kolla/venv/lib/python3.8/site-packages/glance/notifier.py", line 501, in set_data 2023-01-24 06:26:20.563 49 ERROR glance.common.wsgi _send_notification(notify_error, 'image.upload', msg) 2023-01-24 06:26:20.563 49 ERROR glance.common.wsgi File "/var/lib/kolla/venv/lib/python3.8/site-packages/oslo_utils/excutils.py", line 227, in __exit__ 2023-01-24 06:26:20.563 49 ERROR glance.common.wsgi self.force_reraise() 2023-01-24 06:26:20.563 49 ERROR glance.common.wsgi File "/var/lib/kolla/venv/lib/python3.8/site-packages/oslo_utils/excutils.py", line 200, in force_reraise 2023-01-24 06:26:20.563 49 ERROR glance.common.wsgi raise self.value 2023-01-24 06:26:20.563 49 ERROR glance.common.wsgi File "/var/lib/kolla/venv/lib/python3.8/site-packages/glance/notifier.py", line 447, in set_data 2023-01-24 06:26:20.563 49 ERROR glance.common.wsgi self.repo.set_data(data, size, backend=backend, 2023-01-24 06:26:20.563 49 ERROR glance.common.wsgi File "/var/lib/kolla/venv/lib/python3.8/site-packages/glance/api/policy.py", line 273, in set_data 2023-01-24 06:26:20.563 49 ERROR glance.common.wsgi return self.image.set_data(*args, **kwargs) 2023-01-24 06:26:20.563 49 ERROR glance.common.wsgi File "/var/lib/kolla/venv/lib/python3.8/site-packages/glance/quota/__init__.py", line 322, in set_data 2023-01-24 06:26:20.563 49 ERROR glance.common.wsgi self.image.set_data(data, size=size, backend=backend, 2023-01-24 06:26:20.563 49 ERROR glance.common.wsgi File "/var/lib/kolla/venv/lib/python3.8/site-packages/glance/location.py", line 567, in set_data 2023-01-24 06:26:20.563 49 ERROR glance.common.wsgi self._upload_to_store(data, verifier, backend, size) 2023-01-24 06:26:20.563 49 ERROR glance.common.wsgi File "/var/lib/kolla/venv/lib/python3.8/site-packages/glance/location.py", line 458, in _upload_to_store 2023-01-24 06:26:20.563 49 ERROR glance.common.wsgi multihash, loc_meta) = self.store_api.add_with_multihash( 2023-01-24 06:26:20.563 49 ERROR glance.common.wsgi File "/var/lib/kolla/venv/lib/python3.8/site-packages/glance_store/multi_backend.py", line 398, in add_with_multihash 2023-01-24 06:26:20.563 49 ERROR glance.common.wsgi return store_add_to_backend_with_multihash( 2023-01-24 06:26:20.563 49 ERROR glance.common.wsgi File "/var/lib/kolla/venv/lib/python3.8/site-packages/glance_store/multi_backend.py", line 480, in store_add_to_backend_with_multihash 2023-01-24 06:26:20.563 49 ERROR glance.common.wsgi (location, size, checksum, multihash, metadata) = store.add( 2023-01-24 06:26:20.563 49 ERROR glance.common.wsgi File "/var/lib/kolla/venv/lib/python3.8/site-packages/glance_store/driver.py", line 279, in add_adapter 2023-01-24 06:26:20.563 49 ERROR glance.common.wsgi metadata_dict) = store_add_fun(*args, **kwargs) 2023-01-24 06:26:20.563 49 ERROR glance.common.wsgi File "/var/lib/kolla/venv/lib/python3.8/site-packages/glance_store/capabilities.py", line 176, in op_checker 2023-01-24 06:26:20.563 49 ERROR glance.common.wsgi return store_op_fun(store, *args, **kwargs) 2023-01-24 06:26:20.563 49 ERROR glance.common.wsgi File "/var/lib/kolla/venv/lib/python3.8/site-packages/glance_store/_drivers/rbd.py", line 629, in add 2023-01-24 06:26:20.563 49 ERROR glance.common.wsgi raise exc 2023-01-24 06:26:20.563 49 ERROR glance.common.wsgi File "/var/lib/kolla/venv/lib/python3.8/site-packages/glance_store/_drivers/rbd.py", line 574, in add 2023-01-24 06:26:20.563 49 ERROR glance.common.wsgi for chunk in chunks: 2023-01-24 06:26:20.563 49 ERROR glance.common.wsgi File "/var/lib/kolla/venv/lib/python3.8/site-packages/glance_store/common/utils.py", line 73, in chunkiter 2023-01-24 06:26:20.563 49 ERROR glance.common.wsgi chunk = fp.read(chunk_size) 2023-01-24 06:26:20.563 49 ERROR glance.common.wsgi File "/var/lib/kolla/venv/lib/python3.8/site-packages/glance/common/utils.py", line 294, in read 2023-01-24 06:26:20.563 49 ERROR glance.common.wsgi result = self.data.read(i) 2023-01-24 06:26:20.563 49 ERROR glance.common.wsgi File "/var/lib/kolla/venv/lib/python3.8/site-packages/glance/common/utils.py", line 121, in readfn 2023-01-24 06:26:20.563 49 ERROR glance.common.wsgi result = fd.read(*args) 2023-01-24 06:26:20.563 49 ERROR glance.common.wsgi File "/var/lib/kolla/venv/lib/python3.8/site-packages/glance/common/format_inspector.py", line 658, in read 2023-01-24 06:26:20.563 49 ERROR glance.common.wsgi chunk = self._source.read(size) 2023-01-24 06:26:20.563 49 ERROR glance.common.wsgi File "/var/lib/kolla/venv/lib/python3.8/site-packages/eventlet/wsgi.py", line 221, in read 2023-01-24 06:26:20.563 49 ERROR glance.common.wsgi return self._chunked_read(self.rfile, length) 2023-01-24 06:26:20.563 49 ERROR glance.common.wsgi File "/var/lib/kolla/venv/lib/python3.8/site-packages/eventlet/wsgi.py", line 192, in _chunked_read 2023-01-24 06:26:20.563 49 ERROR glance.common.wsgi raise IOError("unexpected end of file while parsing chunked data") 2023-01-24 06:26:20.563 49 ERROR glance.common.wsgi OSError: unexpected end of file while parsing chunked data 2023-01-24 06:26:20.563 49 ERROR glance.common.wsgi 2023-01-24 06:26:20.570 49 INFO eventlet.wsgi.server [req-7eebf051-b8b0-4dff-9b7e-8d5085d77b5d f75f32a3c1fd4cf68cdb7b76d70ee9a8 bf5353fb17604156b492d5a7f00992ff - default default] Traceback (most recent call last): File "/var/lib/kolla/venv/lib/python3.8/site-packages/eventlet/wsgi.py", line 604, in handle_one_response write(b''.join(towrite)) File "/var/lib/kolla/venv/lib/python3.8/site-packages/eventlet/wsgi.py", line 538, in write wfile.flush() File "/usr/lib/python3.8/socket.py", line 687, in write return self._sock.send(b) File "/var/lib/kolla/venv/lib/python3.8/site-packages/eventlet/greenio/base.py", line 396, in send return self._send_loop(self.fd.send, data, flags) File "/var/lib/kolla/venv/lib/python3.8/site-packages/eventlet/greenio/base.py", line 383, in _send_loop return send_method(data, *args) BrokenPipeError: [Errno 32] Broken pipe 2023-01-24 06:26:20.571 49 INFO eventlet.wsgi.server [req-7eebf051-b8b0-4dff-9b7e-8d5085d77b5d f75f32a3c1fd4cf68cdb7b76d70ee9a8 bf5353fb17604156b492d5a7f00992ff - default default] 10.10.13.30,10.10.13.28 - - [24/Jan/2023 06:26:20] "PUT /v2/images/57e5c3ee-6576-4cf7-a72a-2038c86456bc/file HTTP/1.1" 500 0 52.610723 2023-01-24 06:26:21.649 51 INFO eventlet.wsgi.server [req-9eea9898-f4e7-4cb1-b02c-019b56fa00a9 f75f32a3c1fd4cf68cdb7b76d70ee9a8 bf5353fb17604156b492d5a7f00992ff - default default] 10.10.13.27,10.10.13.28 - - [24/Jan/2023 06:26:21] "GET /v2/images?limit=1000&sort_key=created_at&sort_dir=desc HTTP/1.1" 200 4774 0.068947 2023-01-24 06:26:23.635 50 INFO eventlet.wsgi.server [-] 10.10.13.27 - - [24/Jan/2023 06:26:23] "GET / HTTP/1.1" 300 1517 0.001586 ^C root@controller1:/home/stack#24/Jan/2023 06:25:10] "GET /v2/images?limit=1000&sort_key=created_at&sort_dir=desc HTTP/1.1" 200 5995 0.058022 2023-01-24 06:25:12.381 50 INFO glance.api.v2.image_data [req-7eebf051-b8b0-4dff-9b7e-8d5085d77b5d f75f32a3c1fd4cf68cdb7b76d70ee9a8 bf5353fb17604156b492d5a7f00992ff - default default] Unable to create trust: no such option collect_timing in group [keystone_authtoken] Use the existing user token. 2023-01-24 06:25:12.470 50 WARNING glance_store._drivers.rbd [req-7eebf051-b8b0-4dff-9b7e-8d5085d77b5d f75f32a3c1fd4cf68cdb7b76d70ee9a8 bf5353fb17604156b492d5a7f00992ff - default default] Since image size is zero we will be doing resize-before-write which will be slower than normal 2023-01-24 06:25:13.010 51 INFO eventlet.wsgi.server [req-b91e54ba-f3fa-4fad-ab7a-1ef1ad2750fb f75f32a3c1fd4cf68cdb7b76d70ee9a8 bf5353fb17604156b492d5a7f00992ff - default default] 10.10.13.27,10.10.13.28 - - [24/Jan/2023 06:25:13] "GET /v2/schemas/image HTTP/1.1" 200 6259 0.008496 2023-01-24 06:25:15.657 52 INFO eventlet.wsgi.server [req-c9fa16c8-232d-45ff-b425-55504f332597 f75f32a3c1fd4cf68cdb7b76d70ee9a8 bf5353fb17604156b492d5a7f00992ff - default default] 10.10.13.27,10.10.13.28 - - [24/Jan/2023 06:25:15] "GET /v2/schemas/image HTTP/1.1" 200 6259 0.008760 2023-01-24 06:25:16.404 50 ERROR glance_store._drivers.rbd [req-7eebf051-b8b0-4dff-9b7e-8d5085d77b5d f75f32a3c1fd4cf68cdb7b76d70ee9a8 bf5353fb17604156b492d5a7f00992ff - default default] Failed to store image 57e5c3ee-6576-4cf7-a72a-2038c86456bc Store Exception invalid literal for int() with base 16: b'': eventlet.wsgi.ChunkReadError: invalid literal for int() with base 16: b'' 2023-01-24 06:25:16.629 50 ERROR glance.api.v2.image_data [req-7eebf051-b8b0-4dff-9b7e-8d5085d77b5d f75f32a3c1fd4cf68cdb7b76d70ee9a8 bf5353fb17604156b492d5a7f00992ff - default default] Failed to upload image data due to HTTP error: webob.exc.HTTPBadRequest: invalid literal for int() with base 16: b'' 2023-01-24 06:25:16.697 50 INFO eventlet.wsgi.server [req-7eebf051-b8b0-4dff-9b7e-8d5085d77b5d f75f32a3c1fd4cf68cdb7b76d70ee9a8 bf5353fb17604156b492d5a7f00992ff - default default] Traceback (most recent call last): File "/var/lib/kolla/venv/lib/python3.8/site-packages/eventlet/wsgi.py", line 604, in handle_one_response write(b''.join(towrite)) File "/var/lib/kolla/venv/lib/python3.8/site-packages/eventlet/wsgi.py", line 538, in write wfile.flush() File "/usr/lib/python3.8/socket.py", line 687, in write return self._sock.send(b) File "/var/lib/kolla/venv/lib/python3.8/site-packages/eventlet/greenio/base.py", line 396, in send return self._send_loop(self.fd.send, data, flags) File "/var/lib/kolla/venv/lib/python3.8/site-packages/eventlet/greenio/base.py", line 383, in _send_loop return send_method(data, *args) BrokenPipeError: [Errno 32] Broken pipe 2023-01-24 06:25:16.697 50 INFO eventlet.wsgi.server [req-7eebf051-b8b0-4dff-9b7e-8d5085d77b5d f75f32a3c1fd4cf68cdb7b76d70ee9a8 bf5353fb17604156b492d5a7f00992ff - default default] 10.10.13.30,10.10.13.28 - - [24/Jan/2023 06:25:16] "PUT /v2/images/57e5c3ee-6576-4cf7-a72a-2038c86456bc/file HTTP/1.1" 400 0 4.384073 2023-01-24 06:25:18.281 49 INFO eventlet.wsgi.server [req-dcd70adf-5dd4-4a15-abe0-f1e074030346 f75f32a3c1fd4cf68cdb7b76d70ee9a8 bf5353fb17604156b492d5a7f00992ff - default default] 10.10.13.27,10.10.13.28 - - [24/Jan/2023 06:25:18] "GET /v2/images?limit=1000&sort_key=created_at&sort_dir=desc HTTP/1.1" 200 5995 0.067056 2023-01-24 06:25:20.935 52 INFO eventlet.wsgi.server [req-065021ef-2fa4-456f-bad8-22e4a06fec9a f75f32a3c1fd4cf68cdb7b76d70ee9a8 bf5353fb17604156b492d5a7f00992ff - default default] 10.10.13.27,10.10.13.28 - - [24/Jan/2023 06:25:20] "GET /v2/images?limit=1000&sort_key=created_at&sort_dir=desc HTTP/1.1" 200 5995 0.064581 2023-01-24 06:25:23.367 50 INFO eventlet.wsgi.server [-] 10.10.13.27 - - [24/Jan/2023 06:25:23] "GET / HTTP/1.1" 300 1517 0.003469 2023-01-24 06:25:23.583 51 INFO eventlet.wsgi.server [req-a0a51dc6-01c5-4dff-afe9-6c67a279e7fa f75f32a3c1fd4cf68cdb7b76d70ee9a8 bf5353fb17604156b492d5a7f00992ff - default default] 10.10.13.27,10.10.13.28 - - [24/Jan/2023 06:25:23] "GET /v2/images?limit=1000&sort_key=created_at&sort_dir=desc HTTP/1.1" 200 5995 0.072727 2023-01-24 06:25:26.211 49 INFO eventlet.wsgi.server [req-052bc425-90c3-4e4e-94e3-15aba795c96b f75f32a3c1fd4cf68cdb7b76d70ee9a8 bf5353fb17604156b492d5a7f00992ff - default default] 10.10.13.27,10.10.13.28 - - [24/Jan/2023 06:25:26] "GET /v2/images?limit=1000&sort_key=created_at&sort_dir=desc HTTP/1.1" 200 5995 0.055309 2023-01-24 06:25:28.039 49 INFO glance.api.v2.image_data [req-7eebf051-b8b0-4dff-9b7e-8d5085d77b5d f75f32a3c1fd4cf68cdb7b76d70ee9a8 bf5353fb17604156b492d5a7f00992ff - default default] Unable to create trust: no such option collect_timing in group [keystone_authtoken] Use the existing user token. 2023-01-24 06:25:28.168 49 WARNING glance_store._drivers.rbd [req-7eebf051-b8b0-4dff-9b7e-8d5085d77b5d f75f32a3c1fd4cf68cdb7b76d70ee9a8 bf5353fb17604156b492d5a7f00992ff - default default] Since image size is zero we will be doing resize-before-write which will be slower than normal 2023-01-24 06:25:28.887 51 INFO eventlet.wsgi.server [req-4664a441-2fa6-41fa-b985-b6290712e597 f75f32a3c1fd4cf68cdb7b76d70ee9a8 bf5353fb17604156b492d5a7f00992ff - default default] 10.10.13.27,10.10.13.28 - - [24/Jan/2023 06:25:28] "GET /v2/schemas/image HTTP/1.1" 200 6259 0.008411 2023-01-24 06:25:31.541 52 INFO eventlet.wsgi.server [req-31a7d4fc-a266-40a7-9b0d-6ba1e8c0cf47 f75f32a3c1fd4cf68cdb7b76d70ee9a8 bf5353fb17604156b492d5a7f00992ff - default default] 10.10.13.27,10.10.13.28 - - [24/Jan/2023 06:25:31] "GET /v2/schemas/image HTTP/1.1" 200 6259 0.008032 2023-01-24 06:25:34.168 52 INFO eventlet.wsgi.server [req-d8e4513e-9945-4f0c-9b2d-a1e191982f0b f75f32a3c1fd4cf68cdb7b76d70ee9a8 bf5353fb17604156b492d5a7f00992ff - default default] 10.10.13.27,10.10.13.28 - - [24/Jan/2023 06:25:34] "GET /v2/schemas/image HTTP/1.1" 200 6259 0.009528 2023-01-24 06:25:36.798 52 INFO eventlet.wsgi.server [req-02c6e354-6137-4f31-9cf3-a2e9c0258938 f75f32a3c1fd4cf68cdb7b76d70ee9a8 bf5353fb17604156b492d5a7f00992ff - default default] 10.10.13.27,10.10.13.28 - - [24/Jan/2023 06:25:36] "GET /v2/schemas/image HTTP/1.1" 200 6259 0.008272 2023-01-24 06:25:39.435 50 INFO eventlet.wsgi.server [req-a30d0de8-9b34-414f-81ef-9a3457cf2758 f75f32a3c1fd4cf68cdb7b76d70ee9a8 bf5353fb17604156b492d5a7f00992ff - default default] 10.10.13.27,10.10.13.28 - - [24/Jan/2023 06:25:39] "GET /v2/schemas/image HTTP/1.1" 200 6259 0.008886 2023-01-24 06:25:42.059 52 INFO eventlet.wsgi.server [req-409a24f7-7d8e-4bb8-8cab-ef730cf35478 f75f32a3c1fd4cf68cdb7b76d70ee9a8 bf5353fb17604156b492d5a7f00992ff - default default] 10.10.13.27,10.10.13.28 - - [24/Jan/2023 06:25:42] "GET /v2/schemas/image HTTP/1.1" 200 6259 0.008929 2023-01-24 06:25:44.709 52 INFO eventlet.wsgi.server [req-ebee0818-8afe-488e-a9f2-52bcdfb65983 f75f32a3c1fd4cf68cdb7b76d70ee9a8 bf5353fb17604156b492d5a7f00992ff - default default] 10.10.13.27,10.10.13.28 - - [24/Jan/2023 06:25:44] "GET /v2/schemas/image HTTP/1.1" 200 6259 0.008267 2023-01-24 06:25:47.346 52 INFO eventlet.wsgi.server [req-71ad7a1a-acee-40f1-a3ed-70fe64428644 f75f32a3c1fd4cf68cdb7b76d70ee9a8 bf5353fb17604156b492d5a7f00992ff - default default] 10.10.13.27,10.10.13.28 - - [24/Jan/2023 06:25:47] "GET /v2/schemas/image HTTP/1.1" 200 6259 0.008255 2023-01-24 06:25:50.005 50 INFO eventlet.wsgi.server [req-a69f1a44-7689-494c-9e84-c434a1ea9838 f75f32a3c1fd4cf68cdb7b76d70ee9a8 bf5353fb17604156b492d5a7f00992ff - default default] 10.10.13.27,10.10.13.28 - - [24/Jan/2023 06:25:50] "GET /v2/schemas/image HTTP/1.1" 200 6259 0.008565 2023-01-24 06:25:52.631 50 INFO eventlet.wsgi.server [req-08c7e2db-c60e-4cfe-ab0e-78269924f60d f75f32a3c1fd4cf68cdb7b76d70ee9a8 bf5353fb17604156b492d5a7f00992ff - default default] 10.10.13.27,10.10.13.28 - - [24/Jan/2023 06:25:52] "GET /v2/schemas/image HTTP/1.1" 200 6259 0.008409 2023-01-24 06:25:53.521 48 INFO eventlet.wsgi.server [-] 10.10.13.27 - - [24/Jan/2023 06:25:53] "GET / HTTP/1.1" 300 1517 0.001898 2023-01-24 06:25:55.271 51 INFO eventlet.wsgi.server [req-63d5645d-c9dc-4ec4-86b6-48305b05ebe8 f75f32a3c1fd4cf68cdb7b76d70ee9a8 bf5353fb17604156b492d5a7f00992ff - default default] 10.10.13.27,10.10.13.28 - - [24/Jan/2023 06:25:55] "GET /v2/schemas/image HTTP/1.1" 200 6259 0.005122 2023-01-24 06:25:57.911 50 INFO eventlet.wsgi.server [req-67b0f1e9-89a1-4e34-8f95-132f32f9c478 f75f32a3c1fd4cf68cdb7b76d70ee9a8 bf5353fb17604156b492d5a7f00992ff - default default] 10.10.13.27,10.10.13.28 - - [24/Jan/2023 06:25:57] "GET /v2/schemas/image HTTP/1.1" 200 6259 0.009235 2023-01-24 06:26:00.554 48 INFO eventlet.wsgi.server [req-cc7033b2-698b-4bd5-96cf-589d864485ff f75f32a3c1fd4cf68cdb7b76d70ee9a8 bf5353fb17604156b492d5a7f00992ff - default default] 10.10.13.27,10.10.13.28 - - [24/Jan/2023 06:26:00] "GET /v2/schemas/image HTTP/1.1" 200 6259 0.008637 2023-01-24 06:26:03.181 50 INFO eventlet.wsgi.server [req-26a2b823-8a26-49b8-9d79-af6bf36c0e2a f75f32a3c1fd4cf68cdb7b76d70ee9a8 bf5353fb17604156b492d5a7f00992ff - default default] 10.10.13.27,10.10.13.28 - - [24/Jan/2023 06:26:03] "GET /v2/schemas/image HTTP/1.1" 200 6259 0.007718 2023-01-24 06:26:05.835 50 INFO eventlet.wsgi.server [req-1be8a06e-6c3a-4966-9031-a1548b6b0f7a f75f32a3c1fd4cf68cdb7b76d70ee9a8 bf5353fb17604156b492d5a7f00992ff - default default] 10.10.13.27,10.10.13.28 - - [24/Jan/2023 06:26:05] "GET /v2/schemas/image HTTP/1.1" 200 6259 0.008469 2023-01-24 06:26:08.483 50 INFO eventlet.wsgi.server [req-b24990c6-319d-4837-8128-406f49d38530 f75f32a3c1fd4cf68cdb7b76d70ee9a8 bf5353fb17604156b492d5a7f00992ff - default default] 10.10.13.27,10.10.13.28 - - [24/Jan/2023 06:26:08] "GET /v2/schemas/image HTTP/1.1" 200 6259 0.008319 2023-01-24 06:26:11.134 50 INFO eventlet.wsgi.server [req-5393b80e-5069-47ee-a1f0-ef7174c1e09b f75f32a3c1fd4cf68cdb7b76d70ee9a8 bf5353fb17604156b492d5a7f00992ff - default default] 10.10.13.27,10.10.13.28 - - [24/Jan/2023 06:26:11] "GET /v2/schemas/image HTTP/1.1" 200 6259 0.008237 2023-01-24 06:26:13.765 50 INFO eventlet.wsgi.server [req-fcbc3f21-ddb5-4b3f-869c-b489ace9a453 f75f32a3c1fd4cf68cdb7b76d70ee9a8 bf5353fb17604156b492d5a7f00992ff - default default] 10.10.13.27,10.10.13.28 - - [24/Jan/2023 06:26:13] "GET /v2/schemas/image HTTP/1.1" 200 6259 0.008331 2023-01-24 06:26:16.405 52 INFO eventlet.wsgi.server [req-20d98cec-4e1e-4582-aaa2-68043927ab7f f75f32a3c1fd4cf68cdb7b76d70ee9a8 bf5353fb17604156b492d5a7f00992ff - default default] 10.10.13.27,10.10.13.28 - - [24/Jan/2023 06:26:16] "GET /v2/schemas/image HTTP/1.1" 200 6259 0.008366 2023-01-24 06:26:19.028 50 INFO eventlet.wsgi.server [req-2f1bc312-00b8-4e92-91ac-a3ba1f951742 f75f32a3c1fd4cf68cdb7b76d70ee9a8 bf5353fb17604156b492d5a7f00992ff - default default] 10.10.13.27,10.10.13.28 - - [24/Jan/2023 06:26:19] "GET /v2/schemas/image HTTP/1.1" 200 6259 0.008365 2023-01-24 06:26:20.032 49 ERROR glance_store._drivers.rbd [req-7eebf051-b8b0-4dff-9b7e-8d5085d77b5d f75f32a3c1fd4cf68cdb7b76d70ee9a8 bf5353fb17604156b492d5a7f00992ff - default default] Failed to store image 57e5c3ee-6576-4cf7-a72a-2038c86456bc Store Exception unexpected end of file while parsing chunked data: OSError: unexpected end of file while parsing chunked data 2023-01-24 06:26:20.443 49 ERROR glance.api.v2.image_data [req-7eebf051-b8b0-4dff-9b7e-8d5085d77b5d f75f32a3c1fd4cf68cdb7b76d70ee9a8 bf5353fb17604156b492d5a7f00992ff - default default] Failed to upload image data due to internal error: OSError: unexpected end of file while parsing chunked data 2023-01-24 06:26:20.563 49 ERROR glance.common.wsgi [req-7eebf051-b8b0-4dff-9b7e-8d5085d77b5d f75f32a3c1fd4cf68cdb7b76d70ee9a8 bf5353fb17604156b492d5a7f00992ff - default default] Caught error: unexpected end of file while parsing chunked data: OSError: unexpected end of file while parsing chunked data 2023-01-24 06:26:20.563 49 ERROR glance.common.wsgi Traceback (most recent call last): 2023-01-24 06:26:20.563 49 ERROR glance.common.wsgi File "/var/lib/kolla/venv/lib/python3.8/site-packages/glance/common/wsgi.py", line 1353, in __call__ 2023-01-24 06:26:20.563 49 ERROR glance.common.wsgi action_result = self.dispatch(self.controller, action, 2023-01-24 06:26:20.563 49 ERROR glance.common.wsgi File "/var/lib/kolla/venv/lib/python3.8/site-packages/glance/common/wsgi.py", line 1397, in dispatch 2023-01-24 06:26:20.563 49 ERROR glance.common.wsgi return method(*args, **kwargs) 2023-01-24 06:26:20.563 49 ERROR glance.common.wsgi File "/var/lib/kolla/venv/lib/python3.8/site-packages/glance/common/utils.py", line 416, in wrapped 2023-01-24 06:26:20.563 49 ERROR glance.common.wsgi return func(self, req, *args, **kwargs) 2023-01-24 06:26:20.563 49 ERROR glance.common.wsgi File "/var/lib/kolla/venv/lib/python3.8/site-packages/glance/api/v2/image_data.py", line 300, in upload 2023-01-24 06:26:20.563 49 ERROR glance.common.wsgi self._restore(image_repo, image) 2023-01-24 06:26:20.563 49 ERROR glance.common.wsgi File "/var/lib/kolla/venv/lib/python3.8/site-packages/oslo_utils/excutils.py", line 227, in __exit__ 2023-01-24 06:26:20.563 49 ERROR glance.common.wsgi self.force_reraise() 2023-01-24 06:26:20.563 49 ERROR glance.common.wsgi File "/var/lib/kolla/venv/lib/python3.8/site-packages/oslo_utils/excutils.py", line 200, in force_reraise 2023-01-24 06:26:20.563 49 ERROR glance.common.wsgi raise self.value 2023-01-24 06:26:20.563 49 ERROR glance.common.wsgi File "/var/lib/kolla/venv/lib/python3.8/site-packages/glance/api/v2/image_data.py", line 165, in upload 2023-01-24 06:26:20.563 49 ERROR glance.common.wsgi image.set_data(data, size, backend=backend) 2023-01-24 06:26:20.563 49 ERROR glance.common.wsgi File "/var/lib/kolla/venv/lib/python3.8/site-packages/glance/domain/proxy.py", line 208, in set_data 2023-01-24 06:26:20.563 49 ERROR glance.common.wsgi self.base.set_data(data, size, backend=backend, set_active=set_active) 2023-01-24 06:26:20.563 49 ERROR glance.common.wsgi File "/var/lib/kolla/venv/lib/python3.8/site-packages/glance/notifier.py", line 501, in set_data 2023-01-24 06:26:20.563 49 ERROR glance.common.wsgi _send_notification(notify_error, 'image.upload', msg) 2023-01-24 06:26:20.563 49 ERROR glance.common.wsgi File "/var/lib/kolla/venv/lib/python3.8/site-packages/oslo_utils/excutils.py", line 227, in __exit__ 2023-01-24 06:26:20.563 49 ERROR glance.common.wsgi self.force_reraise() 2023-01-24 06:26:20.563 49 ERROR glance.common.wsgi File "/var/lib/kolla/venv/lib/python3.8/site-packages/oslo_utils/excutils.py", line 200, in force_reraise 2023-01-24 06:26:20.563 49 ERROR glance.common.wsgi raise self.value 2023-01-24 06:26:20.563 49 ERROR glance.common.wsgi File "/var/lib/kolla/venv/lib/python3.8/site-packages/glance/notifier.py", line 447, in set_data 2023-01-24 06:26:20.563 49 ERROR glance.common.wsgi self.repo.set_data(data, size, backend=backend, 2023-01-24 06:26:20.563 49 ERROR glance.common.wsgi File "/var/lib/kolla/venv/lib/python3.8/site-packages/glance/api/policy.py", line 273, in set_data 2023-01-24 06:26:20.563 49 ERROR glance.common.wsgi return self.image.set_data(*args, **kwargs) 2023-01-24 06:26:20.563 49 ERROR glance.common.wsgi File "/var/lib/kolla/venv/lib/python3.8/site-packages/glance/quota/__init__.py", line 322, in set_data 2023-01-24 06:26:20.563 49 ERROR glance.common.wsgi self.image.set_data(data, size=size, backend=backend, 2023-01-24 06:26:20.563 49 ERROR glance.common.wsgi File "/var/lib/kolla/venv/lib/python3.8/site-packages/glance/location.py", line 567, in set_data 2023-01-24 06:26:20.563 49 ERROR glance.common.wsgi self._upload_to_store(data, verifier, backend, size) 2023-01-24 06:26:20.563 49 ERROR glance.common.wsgi File "/var/lib/kolla/venv/lib/python3.8/site-packages/glance/location.py", line 458, in _upload_to_store 2023-01-24 06:26:20.563 49 ERROR glance.common.wsgi multihash, loc_meta) = self.store_api.add_with_multihash( 2023-01-24 06:26:20.563 49 ERROR glance.common.wsgi File "/var/lib/kolla/venv/lib/python3.8/site-packages/glance_store/multi_backend.py", line 398, in add_with_multihash 2023-01-24 06:26:20.563 49 ERROR glance.common.wsgi return store_add_to_backend_with_multihash( 2023-01-24 06:26:20.563 49 ERROR glance.common.wsgi File "/var/lib/kolla/venv/lib/python3.8/site-packages/glance_store/multi_backend.py", line 480, in store_add_to_backend_with_multihash 2023-01-24 06:26:20.563 49 ERROR glance.common.wsgi (location, size, checksum, multihash, metadata) = store.add( 2023-01-24 06:26:20.563 49 ERROR glance.common.wsgi File "/var/lib/kolla/venv/lib/python3.8/site-packages/glance_store/driver.py", line 279, in add_adapter 2023-01-24 06:26:20.563 49 ERROR glance.common.wsgi metadata_dict) = store_add_fun(*args, **kwargs) 2023-01-24 06:26:20.563 49 ERROR glance.common.wsgi File "/var/lib/kolla/venv/lib/python3.8/site-packages/glance_store/capabilities.py", line 176, in op_checker 2023-01-24 06:26:20.563 49 ERROR glance.common.wsgi return store_op_fun(store, *args, **kwargs) 2023-01-24 06:26:20.563 49 ERROR glance.common.wsgi File "/var/lib/kolla/venv/lib/python3.8/site-packages/glance_store/_drivers/rbd.py", line 629, in add 2023-01-24 06:26:20.563 49 ERROR glance.common.wsgi raise exc 2023-01-24 06:26:20.563 49 ERROR glance.common.wsgi File "/var/lib/kolla/venv/lib/python3.8/site-packages/glance_store/_drivers/rbd.py", line 574, in add 2023-01-24 06:26:20.563 49 ERROR glance.common.wsgi for chunk in chunks: 2023-01-24 06:26:20.563 49 ERROR glance.common.wsgi File "/var/lib/kolla/venv/lib/python3.8/site-packages/glance_store/common/utils.py", line 73, in chunkiter 2023-01-24 06:26:20.563 49 ERROR glance.common.wsgi chunk = fp.read(chunk_size) 2023-01-24 06:26:20.563 49 ERROR glance.common.wsgi File "/var/lib/kolla/venv/lib/python3.8/site-packages/glance/common/utils.py", line 294, in read 2023-01-24 06:26:20.563 49 ERROR glance.common.wsgi result = self.data.read(i) 2023-01-24 06:26:20.563 49 ERROR glance.common.wsgi File "/var/lib/kolla/venv/lib/python3.8/site-packages/glance/common/utils.py", line 121, in readfn 2023-01-24 06:26:20.563 49 ERROR glance.common.wsgi result = fd.read(*args) 2023-01-24 06:26:20.563 49 ERROR glance.common.wsgi File "/var/lib/kolla/venv/lib/python3.8/site-packages/glance/common/format_inspector.py", line 658, in read 2023-01-24 06:26:20.563 49 ERROR glance.common.wsgi chunk = self._source.read(size) 2023-01-24 06:26:20.563 49 ERROR glance.common.wsgi File "/var/lib/kolla/venv/lib/python3.8/site-packages/eventlet/wsgi.py", line 221, in read 2023-01-24 06:26:20.563 49 ERROR glance.common.wsgi return self._chunked_read(self.rfile, length) 2023-01-24 06:26:20.563 49 ERROR glance.common.wsgi File "/var/lib/kolla/venv/lib/python3.8/site-packages/eventlet/wsgi.py", line 192, in _chunked_read 2023-01-24 06:26:20.563 49 ERROR glance.common.wsgi raise IOError("unexpected end of file while parsing chunked data") 2023-01-24 06:26:20.563 49 ERROR glance.common.wsgi OSError: unexpected end of file while parsing chunked data 2023-01-24 06:26:20.563 49 ERROR glance.common.wsgi 2023-01-24 06:26:20.570 49 INFO eventlet.wsgi.server [req-7eebf051-b8b0-4dff-9b7e-8d5085d77b5d f75f32a3c1fd4cf68cdb7b76d70ee9a8 bf5353fb17604156b492d5a7f00992ff - default default] Traceback (most recent call last): File "/var/lib/kolla/venv/lib/python3.8/site-packages/eventlet/wsgi.py", line 604, in handle_one_response write(b''.join(towrite)) File "/var/lib/kolla/venv/lib/python3.8/site-packages/eventlet/wsgi.py", line 538, in write wfile.flush() File "/usr/lib/python3.8/socket.py", line 687, in write return self._sock.send(b) File "/var/lib/kolla/venv/lib/python3.8/site-packages/eventlet/greenio/base.py", line 396, in send return self._send_loop(self.fd.send, data, flags) File "/var/lib/kolla/venv/lib/python3.8/site-packages/eventlet/greenio/base.py", line 383, in _send_loop return send_method(data, *args) BrokenPipeError: [Errno 32] Broken pipe 2023-01-24 06:26:20.571 49 INFO eventlet.wsgi.server [req-7eebf051-b8b0-4dff-9b7e-8d5085d77b5d f75f32a3c1fd4cf68cdb7b76d70ee9a8 bf5353fb17604156b492d5a7f00992ff - default default] 10.10.13.30,10.10.13.28 - - [24/Jan/2023 06:26:20] "PUT /v2/images/57e5c3ee-6576-4cf7-a72a-2038c86456bc/file HTTP/1.1" 500 0 52.610723 2023-01-24 06:26:21.649 51 INFO eventlet.wsgi.server [req-9eea9898-f4e7-4cb1-b02c-019b56fa00a9 f75f32a3c1fd4cf68cdb7b76d70ee9a8 bf5353fb17604156b492d5a7f00992ff - default default] 10.10.13.27,10.10.13.28 - - [24/Jan/2023 06:26:21] "GET /v2/images?limit=1000&sort_key=created_at&sort_dir=desc HTTP/1.1" 200 4774 0.068947 2023-01-24 06:26:23.635 50 INFO eventlet.wsgi.server [-] 10.10.13.27 - - [24/Jan/2023 06:26:23] "GET / HTTP/1.1" 300 1517 0.001586 ^C root@controller1:/home/stack# Regards Tony Karera

1 0

[charms] OpenStack Charms Zed release is now available
by Peter Matulis 23 Jan '23

23 Jan '23

The Zed release of the OpenStack Charms is now available. Please see the Release notes for full details: https://docs.openstack.org/charm-guide/latest/release-notes/zed.html -- This is the second release since the OpenStack Charms project changed from a time-based release to one based on charm payload versions. Individual charms are no longer developed to work with every supported OpenStack release. Charms now leverage Charmhub tracks, each of which determines a supported payload. See the following resource for details: https://docs.openstack.org/charm-guide/latest/project/charm-delivery.html == Highlights == * Channel migrations Much effort in this cycle was directed at migrating previous OpenStack releases (Queens through Xena) to channels in the Charmhub store. * OpenStack Zed OpenStack Zed is now supported on Ubuntu 22.04 LTS (via UCA) and Ubuntu 22.10 natively. * OVN 22.03 on Focal There is better support for OVN 22.03 on Focal via a new OVN specific UCA pocket. * COS Lite support in the ceph-mon charm Support for sending metrics to the prometheus-k8s charm in the COS Lite observability stack has been added to the ceph-mon charm. Consequently, support for the prometheus2 charm is now deprecated. * NVIDIA vGPU Virtual Workstation The Nova vGPU features in the Nova Compute charms were validated for use as the graphical display driver for Virtual Workstation usage. * Documentation updates Documentation highlights include: - Completion of Deploy Guide to Charm Guide content migration - Improvements to: - Getting Started tutorial - Documentation contributor content - Upgrade pages - OVN pages - SR-IOV page - Charm delivery page == OpenStack Charms team == The OpenStack Charms team can be contacted in the Juju user forum [0] (tag 'openstack') or by chat in the OpenStack Charms Mattermost channel [1]. [0]: https://discourse.charmhub.io/tags/c/juju/6/openstack [1]: https://chat.charmhub.io/charmhub/channels/openstack-charms == Thank you == Lots of thanks to the 56 contributors below who squashed bugs, enabled new features, and improved the documentation! Alex Kavanagh Aliaksandr Vasiuk Billy Olsen Brett Milford Chi Wai, Chan Chris MacNaughton Connor Chamberlain Corey Bryant David Andersson Dmitrii Shcherbakov Edin Sarajlic Edward Hope-Morley Erhan Sunar Ethan Myers Felipe Reyes Francesco de Simone Frode Nordahl Gabriel Adrian Samfira Gokhan Cetinkaya Guilherme Maluf Balzana Hemanth Nakkina Hicham El Gharbi James Page John P Lettman Jorge Merlino Juan Pablo Norena Ksawery Dziekoński Liam Young Luciano Lo Giudice Marcus Boden Martin Kalcok Mert Kırpıcı Muhammad Ahmad Mustafa Kemal Gilor Nicholas Malacarne Nobuto Murata NucciTheBoss Pedro Castillo Peter Matulis Peter Sabaini Rodrigo Barbieri Samuel Walladge Simon Dodsley Sudeep Bhandari Tiago Pasqualini Tianqi Xiao Tilman Baumann Utkarsh Bhatt dongdong tao fdesi jneo8 ljhuang niuke peppepetra86 sudeephb tushargite96 -- OpenStack Charms Team

1 0

Re: Snapshot error
by Kaiser Wassilij 23 Jan '23

23 Jan '23

Hi Dmitriy Rabotyagov glance --version 3.6.0 Where is this Information,"backend driver do you use for glance??" Did you mean glance-api service? > openstack-discuss-request(a)lists.openstack.org hat am 23. Januar 2023 um 16:29 > geschrieben: > > > Send openstack-discuss mailing list submissions to > openstack-discuss(a)lists.openstack.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss > > or, via email, send a message with subject or body 'help' to > openstack-discuss-request(a)lists.openstack.org > > You can reach the person managing the list at > openstack-discuss-owner(a)lists.openstack.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of openstack-discuss digest..." > > > Today's Topics: > > 1. Re: Snapshot error (Dmitriy Rabotyagov) > 2. Re: Snapshots disappear during saving (Karera Tony) > 3. Re: [kolla-ansible] [cinder] Setting up multiple LVM cinder > backends located on different servers (Alan Bishop) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 23 Jan 2023 15:56:16 +0100 > From: Dmitriy Rabotyagov <noonedeadpunk(a)gmail.com> > Cc: openstack-discuss(a)lists.openstack.org > Subject: Re: Snapshot error > Message-ID: > <CAPd_6AuideLVJebPUX4zBf-Q7GmM4zVOVXjY=dsma8+PGiEnow(a)mail.gmail.com> > Content-Type: text/plain; charset="UTF-8" > > Hi there, > > Can you kindly describe what the error actually is? Also what backend > driver do you use for glance? > > As the mentioned bug should be already covered by 25.2.0 release and > it was limited to Swift backend from what I got. > > ??, 23 ???. 2023 ?. ? 15:42, Kaiser Wassilij > <wassilij.kaiser(a)dhbw-mannheim.de>: > > > > > > > > Hello, > > > > I upgraded from Victoria to Yoga. > > > > DISTRIB_ID="OSA" > > DISTRIB_RELEASE="25.2.0" > > DISTRIB_CODENAME="Yoga" > > DISTRIB_DESCRIPTION="OpenStack-Ansible" > > > > I have error > > > > infra1-glance-container-dc13a04b glance-wsgi-api[282311]: 2023-01-23 > > 13:25:06.745 282311 INFO glance.api.v2.image_data > > [req-10359154-0be4-4da1-9e85-2d94079c17b4 b2dca74976034d5b9925bdcb03470603 > > 021ce436ab004cde851055bac66370bc - default default] Unable to create trust: > > no such option collect_timing in group [keystone_authtoken] Use the existing > > user token. > > > > 2023-01-23 14:09:28.890 282298 DEBUG glance.api.v2.images > > [req-bf237e2c-9aca-4089-a56f-dfa245afdcc6 b2dca74976034d5b9925bdcb03470603 > > 021ce436ab004cde851055bac66370bc - default default] The 'locations' list of > > image 2995602a-b5da-4758-a1f9-f6b083815f9b is empty _format_image > > /openstack/venvs/glance-25.2.0/lib/python3.8/site-packages/glance/api/v2/images.py > > > > https://bugs.launchpad.net/glance/+bug/1916052 > > > > > > > > Do any have the same error and how did you solve it > > > > > > Kind regards > > > > > > > > ------------------------------ > > Message: 2 > Date: Mon, 23 Jan 2023 16:56:31 +0200 > From: Karera Tony <tonykarera(a)gmail.com> > To: Sofia Enriquez <senrique(a)redhat.com> > Cc: openstack-discuss <openstack-discuss(a)lists.openstack.org> > Subject: Re: Snapshots disappear during saving > Message-ID: > <CA+69TL0PLcg0XHmpj9Wd55QtatHUHony6ciWKek-q6Ca6AfW+A(a)mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Hello Sofia, > > It is actually Instance snapshot not Volume snapshot. > I click on create Snapshot on the Instance options. > > Regards > > Tony Karera > > > > > On Mon, Jan 23, 2023 at 3:59 PM Sofia Enriquez <senrique(a)redhat.com> wrote: > > > Hi Karera, hope this email finds you well > > > > We need more information in order to reproduce this issue. > > > > - Do you mind sharing c-vol logs of the operation to see if there's any > > errors? > > - How do you create the snapshot? Do you mind sharing the steps to > > reproduce this? > > > > Thanks in advance, > > Sofia > > > > On Mon, Jan 23, 2023 at 1:20 PM Karera Tony <tonykarera(a)gmail.com> wrote: > > > >> Dear Team, > >> > >> I am using Openstack Wallaby deployed using kolla-ansible. > >> > >> I installed Glance with the ceph backend and all was well. > >> However when I create snapshots, they disappear when they are saved. > >> > >> Any idea on how to resolve this? > >> > >> Regards > >> > >> Tony Karera > >> > >> > >> > > > > -- > > > > Sof?a Enriquez > > > > she/her > > > > Software Engineer > > > > Red Hat PnT <https://www.redhat.com> > > > > IRC: @enriquetaso > > @RedHat <https://twitter.com/redhat> Red Hat > > <https://www.linkedin.com/company/red-hat> Red Hat > > <https://www.facebook.com/RedHatInc> > > <https://www.redhat.com> > > > > >

1 0

[outreachy] Call for Outreachy mentors and mentoring organizations for May 2023 internships
by Sofia Enriquez 23 Jan '23

23 Jan '23

Outreachy is seeking open source and open science communities to mentor interns! Outreachy is hosting a live streamed chat with past Outreachy mentors. If you know someone interested in mentoring, please encourage them to attend! See the "Mentor Chats" section below for details. Important dates: - Jan. 17 at 3pm UTC - Mentor chat on YouTube and PeerTube - Feb. 6 at 3pm UTC - Mentor chat on YouTube and PeerTube - Feb. 10 at 4pm UTC - Deadline for open source and open science communities to sign up to be an Outreachy mentoring organization - Feb. 24 at 4pm UTC - Deadline for mentors to submit project descriptions for May 2023 interns to work on What is Outreachy? --- Outreachy is a paid, remote internship program. Outreachy promotes diversity in open source and open science. Our internships are for people who face under-representation, and discrimination or systemic bias in the technology industry of their country. Open source and open science communities can apply to be an Outreachy mentoring organization here: https://www.outreachy.org/communities/cfp/ Please see our blog post for additional details: https://www.outreachy.org/blog/2023-01-05/may-2023-call-for-mentoring-organ… Schedule -------- Jan. 17, 2023 at 3pm UTC - Mentor chat on YouTube and PeerTube Feb. 6, 2023 at 3pm UTC - Mentor chat on YouTube and PeerTube Feb. 10, 2023 - last day for mentoring organizations to sign up Feb. 24, 2023 - last day for mentors to submit projects Mar. 6, 2023 at 4pm UTC - contribution period opens Apr. 3, 2023 at 4pm UTC - contribution period closes May 4, 2023 - interns announced May 29, 2023 to Aug. 25, 2023 - internship -- Sofía Enriquez she/her Software Engineer Red Hat PnT <https://www.redhat.com> IRC: @enriquetaso @RedHat <https://twitter.com/redhat> Red Hat <https://www.linkedin.com/company/red-hat> Red Hat <https://www.facebook.com/RedHatInc> <https://www.redhat.com>

1 0

[Neutron] Bug Deputy Report January 16 - 23
by Jakub Libosvar 23 Jan '23

23 Jan '23

Hi, I was bug deputy last week. There is one critical bug but Slawek is on top of it. Here is the rest of the report: Critical - tempest slow jobs fails https://bugs.launchpad.net/neutron/+bug/2003063 Proposed patch: https://review.opendev.org/c/openstack/neutron/+/871272 Assigned to Slawek High - [FT] Error in “test_arp_spoof_doesnt_block_ipv6” https://bugs.launchpad.net/neutron/+bug/2003196 Patch to gather more information: https://review.opendev.org/c/openstack/neutron/+/871101 Assigned to Rodolfo - [ovn] MTU issues due to centralized vlan provider networks https://bugs.launchpad.net/neutron/+bug/2003455 Assigned to Luis Medium - DVR HA router gets stuck in backup state https://bugs.launchpad.net/neutron/+bug/2003359 Needs an assignee - Floating IP stuck in snat-ns after binding host to associated fixed IP https://bugs.launchpad.net/neutron/+bug/2003532 Needs an assignee but Rodolfo attempts to reproduce - Some port attributes are ignored in bulk port create: allowed_address_pairs, extra_dhcp_opts https://bugs.launchpad.net/neutron/+bug/2003553 Proposed patch: https://review.opendev.org/c/openstack/neutron/+/871294 Assigned to Bence - [OVN] Security group logging only logs half of the connection https://bugs.launchpad.net/neutron/+bug/2003706 Assigned to Elvira Low - neutron-keepalived-state-change unconditional debug mode https://bugs.launchpad.net/neutron/+bug/2003534 Proposed fix: https://review.opendev.org/c/openstack/neutron/+/871274 Assigned to Rodolfo RFEs: - [RFE] Provide Port Binding Information for Manila Share Server Live Migration https://bugs.launchpad.net/neutron/+bug/2003095

1 0

[kolla-ansible] [cinder] Setting up multiple LVM cinder backends located on different servers
by A Monster 23 Jan '23

23 Jan '23

I have an openstack configuration, with 3 controller nodes and multiple compute nodes , one of the controllers has an LVM storage based on HDD drives, while another one has an SDD one, and when I tried to configure the two different types of storage as cinder backends I faced a dilemma since according to the documentation I have to specify the two different backends in the cinder configuration as it is explained here <https://docs.openstack.org/cinder/latest/admin/multi-backend.html> however and since I want to separate disks type when creating volumes, I had to specify different backend names, but I don't know if this configuration should be written in both the storage nodes, or should I specify for each one of these storage nodes the configuration related to its own type of disks. Now, I tried writing the same configuration for both nodes, but I found out that the volume service related to server1 concerning disks in server2 is down, and the volume service in server2 concerning disks in server1 is also down. $ openstack volume service list+------------------+---------------------+------+---------+-------+----------------------------+| Binary | Host | Zone | Status | State | Updated At |+------------------+---------------------+------+---------+-------+----------------------------+| cinder-scheduler | controller-01 | nova | enabled | up | 2023-01-18T14:27:51.000000 || cinder-scheduler | controller-02 | nova | enabled | up | 2023-01-18T14:27:41.000000 || cinder-scheduler | controller-03 | nova | enabled | up | 2023-01-18T14:27:50.000000 || cinder-volume | controller-03@lvm-1 | nova | enabled | up | 2023-01-18T14:27:42.000000 || cinder-volume | controller-01@lvm-1 | nova | enabled | down | 2023-01-18T14:10:00.000000 || cinder-volume | controller-01@lvm-3 | nova | enabled | down | 2023-01-18T14:09:42.000000 || cinder-volume | controller-03@lvm-3 | nova | enabled | down | 2023-01-18T12:12:19.000000|+------------------+---------------------+------+---------+-------+----------------------------+ This is the configuration I have written on the configuration files for cinder_api _cinder_scheduler and cinder_volume for both servers. enabled_backends= lvm-1,lvm-3 [lvm-1] volume_group = cinder-volumes volume_driver = cinder.volume.drivers.lvm.LVMVolumeDriver volume_backend_name = lvm-1 target_helper = lioadm target_protocol = iscsi report_discard_supported = true [lvm-3] volume_group=cinder-volumes-ssd volume_driver=cinder.volume.drivers.lvm.LVMVolumeDriver volume_backend_name=lvm-3 target_helper = lioadm target_protocol = iscsi report_discard_supported = true

2 3

Snapshot error
by Kaiser Wassilij 23 Jan '23

23 Jan '23

Hello, I upgraded from Victoria to Yoga. DISTRIB_ID="OSA" DISTRIB_RELEASE="25.2.0" DISTRIB_CODENAME="Yoga" DISTRIB_DESCRIPTION="OpenStack-Ansible" I have error infra1-glance-container-dc13a04b glance-wsgi-api[282311]: 2023-01-23 13:25:06.745 282311 INFO glance.api.v2.image_data [req-10359154-0be4-4da1-9e85-2d94079c17b4 b2dca74976034d5b9925bdcb03470603 021ce436ab004cde851055bac66370bc - default default] Unable to create trust: no such option collect_timing in group [keystone_authtoken] Use the existing user token. 2023-01-23 14:09:28.890 282298 DEBUG glance.api.v2.images [req-bf237e2c-9aca-4089-a56f-dfa245afdcc6 b2dca74976034d5b9925bdcb03470603 021ce436ab004cde851055bac66370bc - default default] The 'locations' list of image 2995602a-b5da-4758-a1f9-f6b083815f9b is empty _format_image /openstack/venvs/glance-25.2.0/lib/python3.8/site-packages/glance/api/v2/images.py https://bugs.launchpad.net/glance/+bug/1916052 Do any have the same error and how did you solve it Kind regards

2 1

[osprofiler] Regarding contribution process
by Sahid Orentino Ferdjaoui 23 Jan '23

23 Jan '23

Hello, We would like to make some contributions on OSprofiler but not sure of the path that we are taking. For the first one we would like to make a contribution that is adding an option for Jaeger drivers. The point is to add a prefix for the service name. A bug report has been opened for it [0]. Another contribution would be to introduce a set of tags to jaeger spans, still from an option. And finally we would like to add support of Open Telemetry driver. Any suggestions regarding the process that we should use? Spec, blueprint, bug report. Also any blockers that the community may think about? Thanks, s.

1 0

Pulling plugins from my repository
by vincent lee 23 Jan '23

23 Jan '23

Hi everyone, I would like to know where exactly I can replace the path for the GitHub repository. For example, I want to pull some plugins, such as zun_ui, blazar_dashboard, etc., from my own GitHub repository instead of the default GitHub repository. I am currently using Kolla-ansible for deploying OpenStack in the yoga version. Best, Vincent

1 0

Pulling plugins from my repository
by vincent lee 21 Jan '23

21 Jan '23

Hi all, I would like to ask where exactly I can change the default path in which plugins such as zun_ui, blazar_dashboard, etc... can be pulled from my GitHub instead of the default repository. Best, Vincent

2 1

[all][tc] What's happening in Technical Committee: summary 2023 Jan 20: Reading: 5 min
by Ghanshyam Mann 21 Jan '23

21 Jan '23

Hello Everyone, Here is this week's summary of the Technical Committee activities. 1. TC Meetings: ============ * We had this week's meeting on Jan 18. Most of the meeting discussions are summarized in this email. Meeting logs are available @ https://meetings.opendev.org/meetings/tc/2023/tc.2023-01-18-16.00.log.html * The next TC weekly meeting will be on Jan 25 Wed at 16:00 UTC, Feel free to add the topic to the agenda[1] by Jan 24. 2. What we completed this week: ========================= * Removed Adjutant from inactive project list[2] 3. Activities In progress: ================== TC Tracker for the 2023.1 cycle ------------------------------------- * Current cycle working items and their progress are present in the 2023.1 tracker etherpad[3]. Open Reviews ----------------- * Four open reviews for ongoing activities[4]. Cleanup of PyPI maintainer list for OpenStack Projects ---------------------------------------------------------------- The horizon team discussed the 'xstatic-font-awesome' repo PyPi maintainer topic[5] in their weekly meetings and decided to hand over the maintenance to additional external maintainers. The horizon team will retire the repo from OpenStack. To clean up other OpenStack packages, I have sent a separate email[6] to audit first and then we can cleanup based on the audit results. Requesting every PTL to look and do the required step. Project updates ------------------- * Add Cinder Huawei charm[7] * Add the woodpecker charm to Openstack charms[8] Less Active/Inactive projects: ~~~~~~~~~~~~~~~~~~~~~~ * Zaqar status TC discussed and set a deadline of Jan 25th (next week's TC meeting) to check the status and take a final call on Zaqar to be included in this cycle release or not. Zaqar PTL is trying to fix the gate[9]. * Mistral status: python-mistralclient gate is also green now and their beta releases are in progress[10][11]. 4. How to contact the TC: ==================== If you would like to discuss or give feedback to TC, you can reach out to us in multiple ways: 1. Email: you can send the email with tag [tc] on openstack-discuss ML[12]. 2. Weekly meeting: The Technical Committee conduct a weekly meeting every Thursday 15:00 UTC [13] 3. Ping us using 'tc-members' nickname on #openstack-tc IRC channel. [1] https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Agenda_Suggesti… [2] https://review.opendev.org/c/openstack/governance/+/869665 [3] https://etherpad.opendev.org/p/tc-2023.1-tracker [4] https://review.opendev.org/q/projects:openstack/governance+status:open [5] https://github.com/openstack/xstatic-font-awesome/pull/2 [6] https://lists.openstack.org/pipermail/openstack-discuss/2023-January/031848… [7] https://review.opendev.org/c/openstack/governance/+/867588 [8] https://review.opendev.org/c/openstack/governance/+/869752 [9] https://review.opendev.org/c/openstack/zaqar/+/857924/ [10] https://review.opendev.org/c/openstack/releases/+/869470 [11] https://review.opendev.org/c/openstack/releases/+/869448 [12] hhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss [13] http://eavesdrop.openstack.org/#Technical_Committee_Meeting -gmann

1 0

upgrade from Yoda to Zed according to the documentation
by Kaiser Wassilij 20 Jan '23

20 Jan '23

Hallo, I'm trying the openstack system upgrade from Yoda to Zed according to the documentation https://docs.openstack.org/openstack-ansible/zed/admin/upgrades/major-upgra… But I get the following errors: TASK [Clone git repos (parallel)] *********************************************************************************************************************************************************************** An exception occurred during task execution. To see the full traceback, use -vvv. The error was: TypeError: Value of unknown type: <class 'multiprocessing.managers.ListProxy'>, [["Failed to fetch /etc/ansible/roles/etcd\nCmd('git') failed due to: exit code(128)\n cmdline: git fetch --force --shallow-since=2022-05-27\n stderr: 'fatal: error in object: unshallow 29996b0d15ebfaacb7626ce889e26b209ed53434\nfatal: the remote end hung up unexpectedly'"], ["Failed to fetch /etc/ansible/roles/etcd\nCmd('git') failed due to: exit code(128)\n cmdline: git fetch --force --shallow-since=2022-05-27\n stderr: 'fatal: error in object: unshallow 29996b0d15ebfaacb7626ce889e26b209ed53434\nfatal: the remote end hung up unexpectedly'"], ["Role {'name': 'etcd', 'scm': 'git', 'src': 'https://github.com/noonedeadpunk/ansible-etcd' https://github.com/noonedeadpunk/ansible-etcd' , 'version': 'master', 'trackbranch': 'master', 'shallow_since': '2022-05-27', 'path': '/etc/ansible/roles', 'refspec': None, 'depth': 20, 'dest': '/etc/ansible/roles/etcd'} failed after 2 retries\n"]] fatal: [localhost]: FAILED! => {"changed": false, "module_stderr": "Traceback (most recent call last):\n File \"<stdin>\", line 107, in <module>\n File \"<stdin>\", line 99, in _ansiballz_main\n File \"<stdin>\", line 47, in invoke_module\n File \"/usr/lib/python3.8/runpy.py\", line 207, in run_module\n return _run_module_code(code, init_globals, run_name, mod_spec)\n File \"/usr/lib/python3.8/runpy.py\", line 97, in _run_module_code\n _run_code(code, mod_globals, init_globals,\n File \"/usr/lib/python3.8/runpy.py\", line 87, in _run_code\n exec(code, run_globals)\n File \"/tmp/ansible_openstack.osa.git_requirements_payload_m0tl1pcb/ansible_openstack.osa.git_requirements_payload.zip/ansible/modules/openstack/osa/git_requirements.py\", line 333, in <module>\n File \"/tmp/ansible_openstack.osa.git_requirements_payload_m0tl1pcb/ansible_openstack.osa.git_requirements_payload.zip/ansible/modules/openstack/osa/git_requirements.py\", line 329, in main\n File \"/tmp/ansible_openstack.osa.git_requirements_payload_m0tl1pcb/ansible_openstack.osa.git_requirements_payload.zip/ansible/module_utils/basic.py\", line 1533, in fail_json\n File \"/tmp/ansible_openstack.osa.git_requirements_payload_m0tl1pcb/ansible_openstack.osa.git_requirements_payload.zip/ansible/module_utils/basic.py\", line 1506, in _return_formatted\n File \"/tmp/ansible_openstack.osa.git_requirements_payload_m0tl1pcb/ansible_openstack.osa.git_requirements_payload.zip/ansible/module_utils/common/parameters.py\", line 887, in remove_values\n File \"/tmp/ansible_openstack.osa.git_requirements_payload_m0tl1pcb/ansible_openstack.osa.git_requirements_payload.zip/ansible/module_utils/common/parameters.py\", line 461, in _remove_values_conditions\nTypeError: Value of unknown type: <class 'multiprocessing.managers.ListProxy'>, [[\"Failed to fetch /etc/ansible/roles/etcd\\nCmd('git') failed due to: exit code(128)\\n cmdline: git fetch --force --shallow-since=2022-05-27\\n stderr: 'fatal: error in object: unshallow 29996b0d15ebfaacb7626ce889e26b209ed53434\\nfatal: the remote end hung up unexpectedly'\"], [\"Failed to fetch /etc/ansible/roles/etcd\\nCmd('git') failed due to: exit code(128)\\n cmdline: git fetch --force --shallow-since=2022-05-27\\n stderr: 'fatal: error in object: unshallow 29996b0d15ebfaacb7626ce889e26b209ed53434\\nfatal: the remote end hung up unexpectedly'\"], [\"Role {'name': 'etcd', 'scm': 'git', 'src': 'https://github.com/noonedeadpunk/ansible-etcd' https://github.com/noonedeadpunk/ansible-etcd' , 'version': 'master', 'trackbranch': 'master', 'shallow_since': '2022-05-27', 'path': '/etc/ansible/roles', 'refspec': None, 'depth': 20, 'dest': '/etc/ansible/roles/etcd'} failed after 2 retries\\n\"]]\n", "module_stdout": "", "msg": "MODULE FAILURE\nSee stdout/stderr for the exact error", "rc": 1} TASK [Clone git repos (with git)]******** failed: [localhost] (item={'name': 'etcd', 'scm': 'git', 'src': 'https://github.com/noonedeadpunk/ansible-etcd' https://github.com/noonedeadpunk/ansible-etcd' , 'version': 'master', 'trackbranch': 'master', 'shallow_since': '2022-05-27'}) => {"ansible_loop_var": "item", "attempts": 2, "changed": false, "cmd": ["/usr/bin/git", "fetch", "--depth", "20", "--force", "origin", "+refs/heads/master:refs/remotes/origin/master"], "item": {"name": "etcd", "scm": "git", "shallow_since": "2022-05-27", "src": "https://github.com/noonedeadpunk/ansible-etcd", "trackbranch": "master", "version": "master"}, "msg": "Failed to download remote objects and refs: fatal: error in object: unshallow 29996b0d15ebfaacb7626ce889e26b209ed53434\nfatal: the remote end hung up unexpectedly\n"} Does anyone of you have the idea? What should I do? For this reason, no further playbooks will be released. Kind regards

3 2

[openstack-ansible] Installing OpenStack with Ansible fails during Keystone playbook on TASK openstack.osa.db_setup
by jmarcelo.alencar＠gmail.com 20 Jan '23

20 Jan '23

Hello Community, I am trying to create a two machine deployment following Openstack Ansible Deployment Guide (https://docs.openstack.org/project-deploy-guide/openstack-ansible/latest/) The two machines are named targethost01 and targethost02, and I am running Ansible from deploymenthost. Every machine has 4-Core CPUs, 8 GB of RAM, and 240 GB SSD. I am using Ubuntu 22.04.1 LTS. The machine targethost01 has the following network configuration: network: version: 2 ethernets: enp5s0: dhcp4: true enp6s0: {} enp7s0: {} enp8s0: {} enp9s0: {} vlans: vlan.10: id: 10 link: enp6s0 addresses: [ ] vlan.20: id: 20 link: enp7s0 addresses: [ ] vlan.30: id: 30 link: enp8s0 addresses: [ ] vlan.40: id: 40 link: enp9s0 addresses: [ ] bridges: br-mgmt: addresses: [ 172.29.236.101/22 ] mtu: 1500 interfaces: - vlan.10 br-storage: addresses: [ 172.29.244.101/22 ] mtu: 1500 interfaces: - vlan.20 br-vlan: addresses: [] mtu: 1500 interfaces: - vlan.30 br-vxlan: addresses: [ 172.29.240.101/22 ] mtu: 1500 interfaces: - vlan.40 And targethost02 has the following network configuration: network: version: 2 ethernets: enp5s0: dhcp4: true enp6s0: {} enp7s0: {} enp8s0: {} enp9s0: {} vlans: vlan.10: id: 10 link: enp6s0 addresses: [ ] vlan.20: id: 20 link: enp7s0 addresses: [ ] vlan.30: id: 30 link: enp8s0 addresses: [ ] vlan.40: id: 40 link: enp9s0 addresses: [ ] bridges: br-mgmt: addresses: [ 172.29.236.102/22 ] mtu: 1500 interfaces: - vlan.10 br-storage: addresses: [ 172.29.244.102/22 ] mtu: 1500 interfaces: - vlan.20 br-vlan: addresses: [] mtu: 1500 interfaces: - vlan.30 br-vxlan: addresses: [ 172.29.240.102/22 ] mtu: 1500 interfaces: - vlan.40 On the deploymenthost, /etc/openstack_deploy/openstack_user_config.yml has the following: --- cidr_networks: container: 172.29.236.0/22 tunnel: 172.29.240.0/22 storage: 172.29.244.0/22 used_ips: - 172.29.236.1 - "172.29.236.100,172.29.236.200" - "172.29.240.100,172.29.240.200" - "172.29.244.100,172.29.244.200" global_overrides: internal_lb_vip_address: 172.29.236.101 external_lb_vip_address: "{{ bootstrap_host_public_address | default(ansible_facts['default_ipv4']['address']) }}" management_bridge: "br-mgmt" provider_networks: - network: group_binds: - all_containers - hosts type: "raw" container_bridge: "br-mgmt" container_interface: "eth1" container_type: "veth" ip_from_q: "container" is_container_address: true - network: group_binds: - glance_api - cinder_api - cinder_volume - nova_compute type: "raw" container_bridge: "br-storage" container_type: "veth" container_interface: "eth2" container_mtu: "9000" ip_from_q: "storage" - network: group_binds: - neutron_linuxbridge_agent container_bridge: "br-vxlan" container_type: "veth" container_interface: "eth10" container_mtu: "9000" ip_from_q: "tunnel" type: "vxlan" range: "1:1000" net_name: "vxlan" - network: group_binds: - neutron_linuxbridge_agent container_bridge: "br-vlan" container_type: "veth" container_interface: "eth11" type: "vlan" range: "101:200,301:400" net_name: "vlan" - network: group_binds: - neutron_linuxbridge_agent container_bridge: "br-vlan" container_type: "veth" container_interface: "eth12" host_bind_override: "eth12" type: "flat" net_name: "flat" shared-infra_hosts: targethost01: ip: 172.29.236.101 repo-infra_hosts: targethost01: ip: 172.29.236.101 coordination_hosts: targethost01: ip: 172.29.236.101 os-infra_hosts: targethost01: ip: 172.29.236.101 identity_hosts: targethost01: ip: 172.29.236.101 network_hosts: targethost01: ip: 172.29.236.101 compute_hosts: targethost01: ip: 172.29.236.101 targethost02: ip: 172.29.236.102 storage-infra_hosts: targethost01: ip: 172.29.236.101 storage_hosts: targethost01: ip: 172.29.236.101 Also on the deploymenthost, /etc/openstack_deploy/conf.d/haproxy.yml has the following: haproxy_hosts: targethost01: ip: 172.29.236.101 At the Run Playbooks step of the guide, the following two Ansible commands return with unreachable=0 failed=0: # openstack-ansible setup-hosts.yml # openstack-ansible setup-infrastructure.yml And verifying the database also returns no error: root@deploymenthost:/opt/openstack-ansible/playbooks# ansible galera_container -m shell \ -a "mysql -h localhost -e 'show status like \"%wsrep_cluster_%\";'" Variable files: "-e @/etc/openstack_deploy/user_secrets.yml -e @/etc/openstack_deploy/user_variables.yml " [WARNING]: Unable to parse /etc/openstack_deploy/inventory.ini as an inventory source targethost01_galera_container-5aa8474a | CHANGED | rc=0 >> Variable_name Value wsrep_cluster_weight 1 wsrep_cluster_capabilities wsrep_cluster_conf_id 1 wsrep_cluster_size 1 wsrep_cluster_state_uuid e7a0c332-97fe-11ed-b0d4-26b30049826d wsrep_cluster_status Primary But when I execute openstack-ansible setup-openstack.yml, I get this: TASK [os_keystone : Fact for apache module mod_auth_openidc to be installed] *** ok: [targethost01_keystone_container-76e9b31b] TASK [include_role : openstack.osa.db_setup] *********************************** TASK [openstack.osa.db_setup : Create database for service] ******************** failed: [targethost01_keystone_container-76e9b31b -> targethost01_utility_container-dc05dc90(172.29.238.59)] (item=None) => {"censored": "the output has been hidden due to the fact that 'no_log: true' was specified for this result", "changed": false} fatal: [targethost01_keystone_container-76e9b31b -> {{ _oslodb_setup_host }}]: FAILED! => {"censored": "the output has been hidden due to the fact that 'no_log: true' was specified for this result", "changed": false} PLAY RECAP ********************************************************************* targethost01_keystone_container-76e9b31b : ok=33 changed=0 unreachable=0 failed=1 skipped=8 rescued=0 ignored=0 targethost01_utility_container-dc05dc90 : ok=3 changed=0 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 EXIT NOTICE [Playbook execution failure] ************************************** =============================================================================== First, how can I disable the "censored" warning? I wonder if the uncensored running could give me more clues. Second, it appears to be a problem creating the database (keystone db sync?) How can I test the database execution inside the LXC containers? I tried to log into one of the containers and ping the hosts IP and it works, so they have connectivity. I set up the passwords with: # cd /opt/openstack-ansible # ./scripts/pw-token-gen.py --file /etc/openstack_deploy/user_secrets.yml Any help? Best Regards. -- __________________________________ João Marcelo Uchôa de Alencar jmarcelo.alencar(at)gmail.com __________________________________

2 3

[Kolla-ansible] upgrade from yoga to zed on Rocky Linux
by wodel youchi 20 Jan '23

20 Jan '23

Hi, Reading the kolla documentation, I saw that Yoga is supported on Rocky 8 only and Zed is supported on Rokcy 9 only, how to do the upgrade from Yoga to Zed since we have to do OS upgrade also??? Regards.

3 5

[cinder] [glance] Image certificate validation when booting from volume
by İzzettin Erdem 20 Jan '23

20 Jan '23

Hello everyone, I have a problem about booting signed images from cinder volumes. I am currently working on OpenStack Ussuri and I have Ceph storage as cinder backend. I have completed the necessary steps to enable glance image verification according to this document [1]. Now, I can create VMs from signed images -if I do not choose the *create new volume* option-. If I try to boot from volume, it throws an error message: "Image certificate validation is not supported when booting from volume". According to [2], Cinder already has an option to use signed images and it is enabled by default, but it seems it does not work. As opposed to this, [3] explains that Cinder has no ability to verify trusted images: *"As of the 18.0.0 Rocky release, trusted image certification validation is not supported with volume-backed (boot from volume) instances. The block storage service support may be available in a future release"* Is there any way to use trusted/signed images when booting from volume? Thanks. 1 - https://docs.openstack.org/nova/ussuri/user/certificate-validation.html 2 - https://docs.openstack.org/cinder/latest/configuration/block-storage/sample… 3 - https://docs.openstack.org/nova/ussuri/user/certificate-validation.html

2 1

[cinder] festival of XS reviews 20th January 2023
by Rajat Dhasmana 20 Jan '23

20 Jan '23

Hello Argonauts, We will be having our monthly festival of XS reviews today i.e. 20th January (Friday) from 1400-1600 UTC. Following are some additional details: Date: 20th January, 2023 Time: 1400-1600 UTC Meeting link: https://bluejeans.com/556681290 etherpad: https://etherpad.opendev.org/p/cinder-festival-of-reviews See you there! Thanks Rajat Dhasmana

1 0

[neutron] Neutron drivers meeting
by Rodolfo Alonso Hernandez 19 Jan '23

19 Jan '23

Hello Neutrinos: Due to the lack of agenda [1], the drivers meeting is cancelled tomorrow. See you online. [1]https://wiki.openstack.org/wiki/Meetings/NeutronDrivers

1 0

Proposed 2023.2 "Bobcat" release schedule
by Thierry Carrez 19 Jan '23

19 Jan '23

Hi everyone, Here is the proposed schedule for the 2023.2 "Bobcat" release: https://review.opendev.org/c/openstack/releases/+/869976 For easier review, you can access the HTML rendering at: https://storage.bhs.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/… It's a 28-week-long cycle that places final release on Oct 4, 2023. Please comment on the review if you have objections to this or would like to make a case for targeting another week for the 2023.2 release. Thanks! -- Thierry Carrez (ttx)

1 0

[cinder] Cinder Midcycle - 2 (R-9) Summary
by Rajat Dhasmana 19 Jan '23

19 Jan '23

Hello Argonauts, The summary for midcycle-2 held on 18th January, 2023 between 1400-1600 UTC is available here[1]. Please go through the etherpad and recordings for the discussion. [1] https://wiki.openstack.org/wiki/CinderAntelopeMidCycleSummary#Session_Two:_…

1 0

[neutron][ovn] Metadata service failed after creating k8s cluster with kops
by Gene Kuo 19 Jan '23

19 Jan '23

Hi all, I'm recently trying to create Kubernetes cluster on top of OpenStack with kops. However, I found out that instances created kops are unable to get metadata from ovn-metadata-agent. I've tried creating a private network and creating instances manually and the instances are able to get metadata. After I use the same private network for kops, the whole metadata service seems to fail on that network, and new instances created manually also couldn't get metadata. From ovn-metadata-agent logs I can see that the haproxy for serving metadata is created but didn't see any logs related to instances connecting and getting metadata. Any ideas on what may happened and directions for debugging/solving the issues? Thanks! Background: OpenStack Version: Zed Deployment Method: Kolla-Ansible, Ubuntu source build Regards, Gene Kuo

1 0

OpenInfra Live - Jan. 19 at 9am CT / 15:00 UTC
by Kristin Barrientos 18 Jan '23

18 Jan '23

Hi everyone, This week’s OpenInfra Live episode is brought to you by members of the OpenInfra Triangle user group. Episode: Distributing OpenStack Architecture with BGP and Kubernetes Integration This episode will discuss the shortcomings of layer-2 networks and how layer-3 network protocols help address those. We will take a in depth look at Red Hat OpenStack Platform 17 and its integration with FRRouting (FRR) to implement dynamic routing using BGP protocol as well as use of BFD (Bidirectional Forwarding Detection) protocol which is used for detecting network failures. We will also take a look at how ECMP is used to provide both high availability and load balancing in OpenStack control and dataplane networks. Date and time: Jan. 19 at 9 a.m. CT (15:00 UTC) You can watch us live on: YouTube: https://youtu.be/r8WLM9TM6w4 LinkedIn: https://www.linkedin.com/video/event/urn:li:ugcPost:7004177126690017280/ Facebook: www.facebook.com/events/862505974941677 <http://www.facebook.com/events/862505974941677> WeChat: recording will be posted on OpenStack WeChat after the live stream Speakers: Emilien Macchi, Chris Janiszewski, Maciej Lecki, and Luis Bolivar Have an idea for a future episode? Share it now at ideas.openinfra.live. Thanks, Kristin Barrientos Marketing Coordinator OpenInfra Foundation

1 0

[cinder] Bug Report from 01-18-2023
by Sofia Enriquez 18 Jan '23

18 Jan '23

This is a bug report from 01-11-2022 to 01-18-2023. Agenda: https://etherpad.opendev.org/p/cinder-bug-squad-meeting ----------------------------------------------------------------------------------------- High - https://bugs.launchpad.net/cinder/+bug/2003179 "Dell PowerFlex: password appears in plain text when creating a volume from an image." Unassigned. Medium - https://bugs.launchpad.net/cinder/+bug/2002535 "[NFS] Server resize failed when image volume cache enabled." Assigned to Jean Pierre Roquesalane. - https://bugs.launchpad.net/cinder/+bug/2002996 "storpool driver: drop the image-to-volume-and-back overridden methods." Unassigned. - https://bugs.launchpad.net/cinder/+bug/2002995 "storpool driver: fix the retype volume flow." Fix proposed to master. Cheers, -- Sofía Enriquez she/her Software Engineer Red Hat PnT <https://www.redhat.com> IRC: @enriquetaso @RedHat <https://twitter.com/redhat> Red Hat <https://www.linkedin.com/company/red-hat> Red Hat <https://www.facebook.com/RedHatInc> <https://www.redhat.com>

1 0

[cinder] 2023.1 R-9 virtual mid cycle on 18th January, 2023
by Rajat Dhasmana 18 Jan '23

18 Jan '23

Hello Argonauts, As discussed in yesterday's cinder upstream meeting[1], we will be conducting our second mid cycle on 18th January, 2023 (R-9 week). Following are the details: Date: 18th January 2023 Time: 1400-1600 UTC Meeting link: https://bluejeans.com/556681290 Etherpad: https://etherpad.opendev.org/p/cinder-antelope-midcycles Don't forget to add topics and see you there! [1] https://meetings.opendev.org/meetings/cinder/2023/cinder.2023-01-11-14.00.l… Thanks Rajat Dhasmana

1 1

[neutron] The meetings "ping list"
by Rodolfo Alonso Hernandez 18 Jan '23

18 Jan '23

Hello Neutrinos: As suggested by some community members, we now have a "ping list" for our Neutron meetings. If you want to be pinged just before the meeting starts, you can add your IRC nickname to the meeting agenda, in the "ping list" paragraph. As commented during the Neutron meeting, this is only a courtesy ping. Please check the meeting agendas: * Neutron meeting: https://wiki.openstack.org/wiki/Network/Meetings * CI meeting: https://etherpad.opendev.org/p/neutron-ci-meetings * Drivers meeting: https://wiki.openstack.org/wiki/Meetings/NeutronDrivers If you can't edit the agenda meetings, you can request that to any Neutron core in the #openstack-neutron channel. Regards.

2 1

[all][tc] Technical Committee next weekly meeting on 2023 Jan 18 at 1600 UTC
by Ghanshyam Mann 18 Jan '23

18 Jan '23

Hello Everyone, The technical Committee's next weekly meeting is scheduled for 2023 Jan 18, at 1600 UTC. If you would like to add topics for discussion, please add them to the below wiki page by Tuesday, Jan 17 at 2100 UTC. https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting -gmann

1 1

[DIB][diskimage-builder] Debian Testing boot issues
by Michael Still 17 Jan '23

17 Jan '23

Has anyone else tried building Debian Testing (bookworm) images with DIB? I'm having troubles with getting them to boot, with errors that look like missing components in the initrd to me. The command I am using to build is: export ELEMENTS_PATH=elements:diskimage-builder/diskimage_builder/elements export DIB_CLOUD_INIT_DATASOURCES="ConfigDrive, OpenStack, NoCloud" export DIB_APT_MINIMAL_CREATE_INTERFACES=0 export DIB_PYTHON_VERSION=3 export DIB_RELEASE=bookworm export DIB_SF_AGENT_PACKAGE=shakenfist-agent export build_args="cloud-init cloud-init-datasources sf-agent vm" disk-image-create utilities debian debian-systemd ${build_args} -o temp.qcow2 Where shakenfist-agent / sf-agent are a custom element not really relevant to this query (I've left it for completeness). When I boot the output image, I get this: ... [ 1.906949] virtio_blk virtio2: 2/0/0 default/read/poll queues [ 1.908318] virtio_blk virtio2: [vda] 104857600 512-byte logical blocks (53.7 GB/50.0 GiB) [ 1.916912] vda: vda1 [ 1.917646] virtio_blk virtio3: 2/0/0 default/read/poll queues [ 1.917676] virtio_net virtio1 ens11: renamed from eth0 [ 1.918965] virtio_blk virtio3: [vdb] 184 512-byte logical blocks (94.2 kB/92.0 KiB) Begin: Loading essential drivers ... done. Begin: Running /scripts/init-premount ... done. Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done. Begin: Running /scripts/local-premount ... done. Warning: fsck not present, so skipping root file system [ 2.024351] EXT4-fs (vda1): mounted filesystem with ordered data mode. Quota mode: none. done. Begin: Running /scripts/local-bottom ... [ 2.041352] EXT4-fs (vda1): unmounting filesystem. GROWROOT: WARNING: resize failed: failed [flock:127] flock -x 9 /sbin/growpart: line 714: flock: not found FAILED: Error while obtaining exclusive lock on /dev/vda [ 2.057556] vda: vda1 /scripts/local-bottom/growroot: line 97: wait-for-root: not found done. Begin: Running /scripts/init-bottom ... mount: mounting /dev on /root/dev failed: No such file or directory mount: mounting /dev on /root/dev failed: No such file or directory done. mount: mounting /run on /root/run failed: No such file or directory BusyBox v1.35.0 (Debian 1:1.35.0-4+b1) multi-call binary. Usage: run-init [-d CAP,CAP...] [-n] [-c CONSOLE_DEV] NEW_ROOT NEW_INIT [ARGS] Free initramfs and switch to another root fs: chroot to NEW_ROOT, delete all in /, move NEW_ROOT to /, execute NEW_INIT. PID must be 1. NEW_ROOT must be a mountpoint. -c DEV Reopen stdio to DEV after switch -d CAPS Drop capabilities -n Dry run Target filesystem doesn't have requested /sbin/init. BusyBox v1.35.0 (Debian 1:1.35.0-4+b1) multi-call binary. Usage: run-init [-d CAP,CAP...] [-n] [-c CONSOLE_DEV] NEW_ROOT NEW_INIT [ARGS] Free initramfs and switch to another root fs: chroot to NEW_ROOT, delete all in /, move NEW_ROOT to /, execute NEW_INIT. PID must be 1. NEW_ROOT must be a mountpoint. ... Which looks to me like I am missing fsck, flock and wait-for-root, probably in the initrd? Adding cloud-init-growpart and growroot as elements did not help, neither did ensuring that the image contained cloud-guest-utils or util-linux. I wonder if anyone else has seen this and has some hints? Thanks, Michael

1 0

Difficulties Developing a Horizon Customization Module
by Adam Cooper 17 Jan '23

17 Jan '23

Hello! I sent a message to the #openstack IRC last week, but did not receive any replies. I am attempting to create a customization module for Horizon and having difficulties getting things to function. I'm on a fork of the Xena release, and following these docs: https://docs.openstack.org/horizon/9.1.1/topics/customizing.html. At the present, I'm trying to figure out some weird behavior where having the file `openstack_dashboard/local/local_settings.py` causes Horizon to respond to every request with a 400 error. There is no information regarding this in the logs or the HTTP response as far as I can see. It does this with an empty module, or if it just contains HORIZON_CONFIG = {...}. Is there something I'm missing? I would just like to be able to debug this issue so I can actually develop the module. If this is not the right way to ask for help, I would appreciate a pointer to the correct channels. Thanks! -- Adam Cooper Cloud Computing Engineer, Security Point of Contact Chameleon Cloud University of Chicago, Argonne National Laboratory

1 0

[OSSA-2023-001] Swift: Arbitrary file access through custom S3 XML entities (CVE-2022-47950)
by Jeremy Stanley 17 Jan '23

17 Jan '23

=================================================================== OSSA-2023-001: Arbitrary file access through custom S3 XML entities =================================================================== :Date: January 17, 2023 :CVE: CVE-2022-47950 Affects ~~~~~~~ - Swift: <2.28.1, >=2.29.0 <2.29.2, ==2.30.0 Description ~~~~~~~~~~~ Sébastien Meriot (OVH) reported a vulnerability in Swift's S3 XML parser. By supplying specially crafted XML files an authenticated user may coerce the S3 API into returning arbitrary file contents from the host server resulting in unauthorized read access to potentially sensitive data; this impacts both s3api deployments (Rocky or later), and swift3 deployments (Queens and earlier, no longer actively developed). Only deployments with S3 compatibility enabled are affected. Patches ~~~~~~~ - https://review.opendev.org/870823 (2023.1/antelope) - https://review.opendev.org/870828 (Wallaby) - https://review.opendev.org/870827 (Xena) - https://review.opendev.org/870826 (Yoga) - https://review.opendev.org/870825 (Zed) Credits ~~~~~~~ - Sébastien Meriot from OVH (CVE-2022-47950) References ~~~~~~~~~~ - https://launchpad.net/bugs/1998625 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-47950 Notes ~~~~~ - The stable/wallaby branch is under extended maintenance and will receive no new point releases, but a patch for it is provided as a courtesy. -- Jeremy Stanley OpenStack Vulnerability Management Team

1 0

Re: Experience with VGPUs (Tobias Urdin)
by Karl Kloppenborg 17 Jan '23

17 Jan '23

Hi Tobias, I saw your message, interesting method to get around the transient mdev issue. Have you looked into implementing cyborg as a method to alleviate this? We are currently assessing it for a different project using nvidia A40’s. Would be keen to swap war stories and see if we can make a better solution than the current vGPU mdev support going on. Kind Regards, Karl. You can book a 30-minute meeting with me by clicking this link.<https://calendly.com/karl_rwts/30min> -- Karl Kloppenborg, Systems Engineering (BCompSc, CNCF-[KCNA, CKA, CKAD], LFCE, CompTIA Linux+ XK0-004) Real World Technology Solutions - IT People you can trust Voice | Data | IT Procurement | Managed IT rwts.com.au<http://rwts.com.au> | 1300 798 718 [uc%3fexport=download&id=1M0bR7j1-rXl-e7k5f1Rhwot6K_vfuAvn&revid=0B4fBbZ0cwq-1WFdQSExlR28rOEtUanJjOGcvQnJjMFhEMlEwPQ] Real World is a DellEMC Gold Partner This document should be read only by those persons to whom it is addressed and its content is not intended for use by any other persons. If you have received this message in error, please notify us immediately. Please also destroy and delete the message from your computer. Any unauthorised form of reproduction of this message is strictly prohibited. We are not liable for the proper and complete transmission of the information contained in this communication, nor for any delay in its receipt. Please consider the environment before printing this e-mail. From: openstack-discuss-request(a)lists.openstack.org <openstack-discuss-request(a)lists.openstack.org> Date: Tuesday, 17 January 2023 at 9:06 pm To: openstack-discuss(a)lists.openstack.org <openstack-discuss(a)lists.openstack.org> Subject: openstack-discuss Digest, Vol 51, Issue 51 Send openstack-discuss mailing list submissions to openstack-discuss(a)lists.openstack.org To subscribe or unsubscribe via the World Wide Web, visit https://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss or, via email, send a message with subject or body 'help' to openstack-discuss-request(a)lists.openstack.org You can reach the person managing the list at openstack-discuss-owner(a)lists.openstack.org When replying, please edit your Subject line so it is more specific than "Re: Contents of openstack-discuss digest..." Today's Topics: 1. Re: Enable fstrim automatically on cinder thin lvm provisioning (Rajat Dhasmana) 2. Re: Experience with VGPUs (Tobias Urdin) 3. Re: [designate] Proposal to deprecate the agent framework and agent based backends (Thomas Goirand) 4. Re: Experience with VGPUs (Sylvain Bauza) ---------------------------------------------------------------------- Message: 1 Date: Tue, 17 Jan 2023 10:11:27 +0530 From: Rajat Dhasmana <rdhasman(a)redhat.com> To: A Monster <amonster369(a)gmail.com> Cc: openstack-discuss <openstack-discuss(a)lists.openstack.org> Subject: Re: Enable fstrim automatically on cinder thin lvm provisioning Message-ID: <CAARK8KQ3rM9KSQ9vFP+CAVPL_xAksxfXvFuvZj8gd7FeFT6LTw(a)mail.gmail.com> Content-Type: text/plain; charset="utf-8" Hi, We've a config option 'report_discard_supported'[1] which can be added to cinder.conf that will enable trim/unmap support. Also I would like to suggest not creating new openstack-discuss threads for the same issue and reuse the first one created. As I can see these are the 3 threads for the same issue[2][3][4]. [1] https://docs.openstack.org/cinder/latest/configuration/block-storage/config… [2] https://lists.openstack.org/pipermail/openstack-discuss/2023-January/031789… [3] https://lists.openstack.org/pipermail/openstack-discuss/2023-January/031797… [4] https://lists.openstack.org/pipermail/openstack-discuss/2023-January/031805… Thanks Rajat Dhasmana On Tue, Jan 17, 2023 at 8:57 AM A Monster <amonster369(a)gmail.com> wrote: > I deployed openstack using kolla ansible, and used LVM as storage backend > for my cinder service, however I noticed that the lvm thin pool size keeps > increasing even though the space used by instances volumes is the same, and > after a bit of investigating I found out that I had to enable fstrim > because the data deleted inside the logical volumes was still allocated > from the thin pool perspective and I had to do fstrim on those volumes, > > how can I enable this automatically in openstack? >

1 0

Enable fstrim automatically on cinder thin lvm provisioning
by A Monster 17 Jan '23

17 Jan '23

I deployed openstack using kolla ansible, and used LVM as storage backend for my cinder service, however I noticed that the lvm thin pool size keeps increasing even though the space used by instances volumes is the same, and after a bit of investigating I found out that I had to enable fstrim because the data deleted inside the logical volumes was still allocated from the thin pool perspective and I had to do fstrim on those volumes, how can I enable this automatically in openstack?

2 1

When is client-side modified being added?
by Adisa Nicholson aka Tynamite 17 Jan '23

17 Jan '23

Hello Openstack When is client-side modified being added as a new feature? Right now I'm paying for file hosting and when I upload a file, the "date modified" isn't respected for that file. It always takes the "date modified" for the file as the current date, not the one on the file I was uploading from my computer. I've contacted the company I brought it from, and they said that client-side modified isn't supported in the Openstack API <https://docs.openstack.org/swift/latest/s3_compat.html>. What API method would this be exactly? Would it be the "object tagging" method? Do you lot have any idea when this feature would be added in, so my file uploads will respect the "date modified" metadata?

1 0

[kolla] where to find docker compose files
by garcetto 16 Jan '23

16 Jan '23

good afternoon, where can i find docker compose files for quay,io docker images used in kolla-ansible? need to undestand how are build, thank you.

2 1

Cinder LVM backend shows 100% space usage
by A Monster 16 Jan '23

16 Jan '23

I deployed openstack using kolla ansible using LVM as a backend, but after using it for a while, I ended up creating multiple volume with different sizes, but now I can no longer create new volumes, after checking lvs I found out that the thin pool created by cinder displays a 100% space usage of 20TB , but the size used by the volumes created is less than 1TB. how can I fix this isse?

1 0