May 2023 - openstack-discuss - lists.openstack.org

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

23 Apr '25

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

3 2

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

22 Apr '25

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

2 1

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

24 Dec '24

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

4 4

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

26 Nov '24

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

4 3

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

10 Oct '24

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

5 9

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

07 Aug '24

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

5 16

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

17 May '24

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

18 27

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

06 Mar '24

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

3 5

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

09 Jan '24

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

3 13

[OPENSTACK][rabbitmq] using quorum queues
by Nguyễn Hữu Khôi 17 Oct '23

17 Oct '23

Hello guys. IS there any guy who uses the quorum queue for openstack? Could you give some feedback to compare with classic queue? Thank you. Nguyen Huu Khoi

9 19

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

11 Sep '23

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

5 9

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

05 Sep '23

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

3 7

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

23 Aug '23

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

3 4

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

28 Jul '23

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

3 3

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

27 Jul '23

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

5 7

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

22 Jul '23

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

8 30

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

11 Jul '23

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

3 3

Experience with VGPUs
by Oliver Weinmann 22 Jun '23

22 Jun '23

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

17 36

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

14 Jun '23

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

6 11

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

13 Jun '23

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

1 1

[nova] Nova Spec review day next Tuesday 6 June
by Sylvain Bauza 06 Jun '23

06 Jun '23

Hey Nova community, As a reminder, you can find the Nova agenda for the 2023.2 Bobcat release here https://releases.openstack.org/bobcat/schedule.html As you can see, we plan to do a round of reviews for all the open specifications in the openstack/nova-specs repository by next Tuesday June 6th. If you're a developer wanting to propose a new feature in Nova and you have been said to provide a spec, or if you know that you need to create a spec, or if you already have an open spec, please make sure to upload/update your file before next Tuesday so we'll look at it. Also, if you can look again on your spec during the day, it would be nice as we could try to discuss your spec during this day. Thanks, -Sylvain

2 1

[puppet] puppet module improvements
by Benedikt Trefzer 06 Jun '23

06 Jun '23

Hi all I use the openstack puppet modules to deploy openstack. I'd like to suggest some improvements to the modules and like to know what the community thinks about: 1.) use proper types for parameters Parameter validation is done with 'validate_legacy...' instead of defining the class/resource parameter with a proper type all over the code. I cannot imaging of any advantage not using proper type definitions. Instead using typed parameters would be more efficient an code readability would increase. 2.) params.pp This is the legacy way to define parameter defaults for different OS's. In the modern puppet world a module specific hiera structure is used, which eliminates the need of params.pp class (with inheritance and include). The usage of hiera improves readability and flexibility (every parameter can be overwritten on request, eg. change of packages names etc.) This also eliminate the restriction that the modules can only be used by certain OS'es (osfamily 'RedHat' or 'Debian'). 3.) Eliminate "if OS=='bla' {" statements in code These statements make the code very inflexible. It cannot be overruled if necessary (eg. if I use custom packages to install and do not need the code provided in the if statement). Instead a parameter should be used with a default provided in hiera. Since there is lot of code to change I do not expect this to be done in a single commit (per module) but in steps probably in more than one release cycle. But defining this as best practice for openstack puppet modules and start using above in new commits would bring the code forward. Finally: These are suggestions open for discussion. In no way I like to critic the current state of the puppet modules (which is quite good, but a bit legacy) or the people working on the modules. This is just a feedback/suggestion from an operator using the modules on a daily basis. Regards Benedikt Trefzer

4 4

swift container retention
by Geert Geurts 05 Jun '23

05 Jun '23

Hallo, I've gotten the assignment to implement a backup solution using openstack swift containers. What we want is that the files of customers are kept in the customers own container and for those files to retain their versions on updates of the file. So far so good, this is all possible, and extensively documented online. Now, the second part is more complicated it appears where I thougth this would be a quite common usage example of object storage. I cannot find how I can automagically delete versions of files that are older then X days. There is the X-delete-after header, but this header needs to be added for each transaction. What I want is for all objects in a container to get deleted after X days without having to add a header once the object is uploaded. Does anyone have suggestions on how I could implement this requirement? Please find below a grafical repesentation of what I want Versioning disabled Automated add headers delete-after Versioning enabled Usage on the account of LF Usage on the account of client │ │ │ │ │ │ ▼ ▼ ┌────────────────────────┐ ┌────────────────────────┐ │ │ │ │ │ Versions-container │ │ Current-container │ │ │ │ │ ├────────────────────────┤ ├────────────────────────┤ │ │ │ │ │File1 v123456 │ │ File1 │ │File1 v567899 │ │ File2 │ │ │ │ File3 │ │File3 v234567 │ │ ... │ │ │ │ FileN │ └────────────────────────┘ └─────────────┬──────────┘ ▲ │ │ │ └────────────────────────────────────────┘ Modifications cause current to be moved to Versioned-container Best regards, Geert

2 1

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

05 Jun '23

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

5 10

[nova] hw:numa_nodes question
by hai wu 02 Jun '23

02 Jun '23

Is there any concern to enable 'hw:numa_nodes=1' on all flavors, as long as that flavor can fit into one numa node?

4 18

[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

Add netapp storage in edge site | Wallaby | DCN
by Swogat Pradhan 01 Jun '23

01 Jun '23

Hi, I have a DCN setup and there is a requirement to use a netapp storage device in one of the edge sites. Can someone please confirm if it is possible? And if so then should i add the parameters in the edge deployment script or the central deployment script. Any suggestions? With regards, Swogat Pradhan

2 10

CRITICAL! RabbitMQ PackageCloud repos will be not more available from today - affected Openstack-ansible
by Maroš Varchola 01 Jun '23

01 Jun '23

From today, the PackageCloud repos will be not more available from today. Official information: https://github.com/rabbitmq/rabbitmq-server/discussions/8386 BUG on launchpad: https://bugs.launchpad.net/openstack-ansible/+bug/2021410 -- S pozdravom/Yours Sincerely, Maroš Varchola +421 950 401 060 Astrová 6116/2, 071 01 Michalovce, Slovakia marosvarchola(a)sunray.sk ---- Táto správa bola digitálne podpísaná PGP certifikátom/ This message was digitally signed by PGP certificate

5 7

[ironic] retirement of old bugfix branches
by Riccardo Pittau 31 May '23

31 May '23

Hello everyone! We're going to remove old bugfix branches in the next few weeks, all bugfix branches that are older than 6 months are officially EoL. This includes: - for ironic bugfix/18.0 bugfix/18.1 bugfix/19.0 bugfix/20.2 bugfix/21.0 bugfix/21.2 - for ironic-inspector bugfix/10.7 bugfix/10.9 bugfix/10.12 bugfix/11.0 bugfix/11.2 -for ironic-python-agent bugfix/8.0 bugfix/8.1 bugfix/8.3 bugfix/8.6 bugfix/9.0 bugfix/9.2 Thanks! Ciao Riccardo

1 0

openstack backup volume - error with rootwrap
by garcetto 31 May '23

31 May '23

goodmorning, using kolla-openstack zed cluster, cinder backend is nfs, cinder-backup is another nfs too. when i try to do backup: #openstack volume backup create 43e97a6d-c965-4127-8334-df5b5e8e8a05 (on cinder-backup container) (/var/log/cinder-backup.log) " ERROR oslo_messaging.rpc.server Command: sudo cinder-rootwrap /etc/cinder/rootwrap.conf chown 42407 /var/lib/cinder/mnt/6c827b655049ba4f069fd5f103620555/volume-20f3c72c-0b57-4500-b552-5056d12fd9c7 2023-05-31 12:37:37.551 7 ERROR oslo_messaging.rpc.server Exit code: 1 2023-05-31 12:37:37.551 7 ERROR oslo_messaging.rpc.server Stdout: '' 2023-05-31 12:37:37.551 7 ERROR oslo_messaging.rpc.server Stderr: "/bin/chown: changing ownership of '/var/lib/cinder/mnt/6c827b655049ba4f069fd5f103620555/volume-20f3c72c-0b57-4500-b552-5056d12fd9c7': Invalid argument\n" 2023-05-31 12:37:37.551 7 ERROR oslo_messaging.rpc.server " could anyone give me advice how to proceed? thank you for your time.

3 3

[kolla-ansible][zed] nfs as backend for nova
by garcetto 31 May '23

31 May '23

good afternoon, it is a clear doc or tutorial on how to configure an nfs share as backend storage for nova root vm volumes? (find for ceph but not for nfs) thank you

1 0

Affinity Group in Open Stack
by Adivya Singh 31 May '23

31 May '23

Hi Guys, Anything i can check on this , more from the server logs and the switch logs Packet drops when using trex traffic generator when device under test and traffic generator are not in same compute node But if we launch the instance using affinity and traffic generator and client on the same node , it works fine Regards Adivya Singh

1 0

[openstack-helm] Storyboard cleanup
by Vladimir Kozhukalov 31 May '23

31 May '23

Dear Openstack-helmers, Minor announcement about OSH Storyboard. During May/2023 I have been putting some effort into cleaning up the Storyboard. More than 50 stories have been reviewed, verified and updated as merged or invalid. Now we still have 44 active stories in the OSH project group and I am going to clean them up even more. Also the infra team helped us to unlink 3 retired OSH projects from the OSH Storyboard project group. So now only active projects openstack-helm, openstack-helm-infra and openstack-helm-images are in the project group. -- Best regards, Kozhukalov Vladimir

1 0

Cinder Bug Report 2023-05-31
by Sofia Enriquez 31 May '23

31 May '23

Hello Argonauts, Cinder Bug Meeting Etherpad <https://etherpad.opendev.org/p/cinder-bug-squad-meeting> *Medium* - Creating a snapshot failed by schema validation when its description contains a new line control character <https://bugs.launchpad.net/cinder/+bug/2021909>. - *Status:* Unassigned. I'm kind of lost on this one if any Argonaut would like to give it a look. - Cached images duplicated per host. <https://bugs.launchpad.net/cinder/+bug/2020733> - *Status:* Unassigned. - HPE 3par: Unable to create clones of replicated vol. <https://bugs.launchpad.net/cinder/+bug/2021941> - *Status*: Fix proposed to master. <https://review.opendev.org/c/openstack/cinder/+/884594> - NetApp ONTAP enhanced instance creation using file copy API should allow use of DNS name for NFS share <https://bugs.launchpad.net/cinder/+bug/2021741>. - *Status*: Unassigned. Is this related to https://bugs.launchpad.net/cinder/+bug/2020733? - NetApp ONTAP driver does not include snapshot-<uuid> files for capacity calculations of provisioned_capacity_gb <https://bugs.launchpad.net/cinder/+bug/2021746>. - *Status*: Unassigned. - *Low* - Using NetApp ONTAP file copy for copy offload needs volume provider_location set. <https://bugs.launchpad.net/cinder/+bug/2021739> - *Status:* Unassigned. 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] Midcycle-1 Status (31st May)
by Rajat Dhasmana 31 May '23

31 May '23

Hello Argonauts, As you know we had planned our first midcycle of 2023.2 Bobcat cycle on 31st May, 2023. I created an etherpad[1] around a month ago and have been providing constant reminders in every cinder meeting about adding topics. At this point, no topic has been added which makes me believe that we don't require a midcycle discussion. I will wait till today EOD to see if any new topics are added, and if not, we will continue with our usual video+IRC (end of the month) meeting[2]. [1] https://etherpad.opendev.org/p/cinder-bobcat-midcycles [2] https://etherpad.opendev.org/p/cinder-bobcat-meetings Thanks Rajat Dhasmana

1 1

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

31 May '23

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

3 2

[largescale-sig] Next meeting: May 31, 8utc
by Thierry Carrez 31 May '23

31 May '23

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

1 1

[kolla][cinder] cinder containers api, volume, backup unhealthy
by Oliver Weinmann 31 May '23

31 May '23

Hi, after replacing my control nodes with new nodes (all bare-metal) somehow the cinder containers are no longer starting. I checked the logs on one of the control nodes and I see this in the api-eror.log: 2023-05-30 21:31:36.350636 Timeout when reading response headers from daemon process 'cinder-api': /var/www/cgi-bin/cinder/cinder-wsgi 2023-05-30 21:31:37.827101 mod_wsgi (pid=22): Failed to exec Python script file '/var/www/cgi-bin/cinder/cinder-wsgi'. 2023-05-30 21:31:37.827168 mod_wsgi (pid=22): Exception occurred processing WSGI script '/var/www/cgi-bin/cinder/cinder-wsgi'. 2023-05-30 21:31:37.828005 Traceback (most recent call last): 2023-05-30 21:31:37.828046 File "/var/www/cgi-bin/cinder/cinder-wsgi", line 52, in <module> 2023-05-30 21:31:37.828053 application = initialize_application() 2023-05-30 21:31:37.828058 File "/var/lib/kolla/venv/lib/python3.6/site-packages/cinder/wsgi/wsgi.py", line 44, in initialize_application 2023-05-30 21:31:37.828063 coordination.COORDINATOR.start() 2023-05-30 21:31:37.828068 File "/var/lib/kolla/venv/lib/python3.6/site-packages/cinder/coordination.py", line 86, in start 2023-05-30 21:31:37.828071 self.coordinator.start(start_heart=True) 2023-05-30 21:31:37.828075 File "/var/lib/kolla/venv/lib/python3.6/site-packages/tooz/coordination.py", line 689, in start 2023-05-30 21:31:37.828078 super(CoordinationDriverWithExecutor, self).start(start_heart) 2023-05-30 21:31:37.828083 File "/var/lib/kolla/venv/lib/python3.6/site-packages/tooz/coordination.py", line 426, in start 2023-05-30 21:31:37.828086 self._start() 2023-05-30 21:31:37.828090 File "/var/lib/kolla/venv/lib/python3.6/site-packages/tooz/drivers/etcd3gw.py", line 224, in _start 2023-05-30 21:31:37.828093 self._membership_lease = self.client.lease(self.membership_timeout) 2023-05-30 21:31:37.828098 File "/var/lib/kolla/venv/lib/python3.6/site-packages/etcd3gw/client.py", line 122, in lease 2023-05-30 21:31:37.828111 json={"TTL": ttl, "ID": 0}) 2023-05-30 21:31:37.828116 File "/var/lib/kolla/venv/lib/python3.6/site-packages/etcd3gw/client.py", line 88, in post 2023-05-30 21:31:37.828123 resp.reason 2023-05-30 21:31:37.828154 etcd3gw.exceptions.ConnectionTimeoutError: Gateway Time-out All other containers are working just fine. Even the cinder_scheduler container works fine. So far I have tried the following: remove the cinder containers including its volume from one control node mariadb_recovery Reboot all control nodes. kolla-ansible reconfigure --tags cinder,nova Any help is highly appreciated. Cheers, Oliver

2 1

Invitation to further discuss the notion of a 'domain manager' role
by Felix Kronlage-Dammers 31 May '23

31 May '23

Hi, We (SCS Project) are looking for CSPs / Operators who would like to join a discussion on the notion of a ‘domain manager role’. To a lot of you this topic is far from new and has been brought up just recently on this list as well[1]. On the upcoming Monday (June 5th) at 15:05 CEST we would like to have a kickstarting discussion of CSPs who currently solve the hurdle of not having such a role in their environments and/or their custom frontends. We will meet here: <url: https://conf.scs.koeln:8443/SCS-Tech> Through the Public Cloud SIG I’ve reached out to Cleura, OTC as well as Catalyst Cloud. From the german scene PlusServer will join the discussion. As part of the discussion on monday we want to see, where we can move towards a joint-effort to maybe see that such a role can be introduced earlier than anticipated. For that it sure is good to understand wether any of the participating CSPs do have “stuff in their drawer” (code, knowledge, experience, …) that they could bring to the table. regards, felix [1] <url: https://lists.openstack.org/pipermail/openstack-discuss/2023-May/033803.html> -- Felix Kronlage-Dammers Product Owner IaaS & Operations Sovereign Cloud Stack Sovereign Cloud Stack — standardized, built and operated by many Ein Projekt der Open Source Business Alliance - Bundesverband für digitale Souveränität e.V. Tel.: +49-30-206539-205 | Matrix: @fkronlage:matrix.org | fkr(a)osb-alliance.com

2 2

[ironic] OpenInfra Summit planning/attendance
by Jay Faulkner 30 May '23

30 May '23

Hi all, We're doing some light coordination of Ironic-interested operators and contributors at the OpenInfra Summit. If you're a part of the larger Ironic community and you're interested in meeting up with the team, seeing talks about Ironic specifically, or attending the team dinner please go to https://etherpad.opendev.org/p/ironic-openinfra-2023 and comment accordingly. Thanks! See many of you in two short weeks! - Jay Faulkner Ironic PTL

1 0

[ironic] Retirement of ironic-prometheus-exporter bugfix/2.1 branch
by Jay Faulkner 30 May '23

30 May '23

Hi all, The ironic-prometheus-exporter bugfix/2.1 branch is currently broken in CI, and unused based on a poll of known-downstream users of bugfix branches. It's my intention to retire this branch in the same manner for other Ironic bugfix branches -- by tagging it EOL. If you have an objection, please bring it up soon. Thank you, Jay Faulkner Ironic PTL

1 0

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

30 May '23

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

2 1

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

30 May '23

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

3 3

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

30 May '23

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

4 11

Re: [Port Creation failed] - openstack Wallaby
by Lokendra Rathour 30 May '23

30 May '23

Hi Swogat, Thanks for the inputs, it was showing a similar issue but somehow the issue is not getting resolved. we are trying to explore more around it. getting the error in ovn-metadata-agent.log Cannot find Chassis_Private with name=f80799b9-0cf4-4413-bb4b-e36278c73f6c detailed: 2023-05-17 19:26:31.984 45317 INFO oslo.privsep.daemon [-] privsep daemon running as pid 45317 2023-05-17 19:26:32.712 44735 ERROR ovsdbapp.backend.ovs_idl.transaction [-] Traceback (most recent call last): File "/usr/lib/python3.6/site-packages/ovsdbapp/backend/ovs_idl/connection.py", line 131, in run txn.results.put(txn.do_commit()) File "/usr/lib/python3.6/site-packages/ovsdbapp/backend/ovs_idl/transaction.py", line 93, in do_commit command.run_idl(txn) File "/usr/lib/python3.6/site-packages/ovsdbapp/backend/ovs_idl/command.py", line 172, in run_idl record = self.api.lookup(self.table, self.record) File "/usr/lib/python3.6/site-packages/ovsdbapp/backend/ovs_idl/__init__.py", line 208, in lookup return self._lookup(table, record) File "/usr/lib/python3.6/site-packages/ovsdbapp/backend/ovs_idl/__init__.py", line 268, in _lookup row = idlutils.row_by_value(self, rl.table, rl.column, record) File "/usr/lib/python3.6/site-packages/ovsdbapp/backend/ovs_idl/idlutils.py", line 114, in row_by_value raise RowNotFound(table=table, col=column, match=match) ovsdbapp.backend.ovs_idl.idlutils.RowNotFound: Cannot find Chassis_Private with name=f80799b9-0cf4-4413-bb4b-e36278c73f6c 2023-05-17 19:26:32.713 44735 ERROR ovsdbapp.backend.ovs_idl.command [-] Error executing command (DbAddCommand): ovsdbapp.backend.ovs_idl.idlutils.RowNotFound: Cannot find Chassis_Private with name=f80799b9-0cf4-4413-bb4b-e36278c73f6c 2023-05-17 19:26:32.713 44735 ERROR ovsdbapp.backend.ovs_idl.command Traceback (most recent call last): 2023-05-17 19:26:32.713 44735 ERROR ovsdbapp.backend.ovs_idl.command File "/usr/lib/python3.6/site-packages/ovsdbapp/backend/ovs_idl/command.py", line 42, in execute waiting for your always helpful inputs. On Tue, May 16, 2023 at 10:47 PM Swogat Pradhan <swogatpradhan22(a)gmail.com> wrote: > Hi > I am not sure if this will help, but i faced something similar. > You might need to check the ovn database entries. > http://www.jimmdenton.com/neutron-ovn-private-chassis/ > > Or maybe try restarting the ovn service from pcs, sometimes issue comes up > when ovn doesn't sync up. > > Again m not sure if this will be of any help to you. > > With regards, > Swogat Pradhan > > On Tue, 16 May 2023, 10:41 pm Lokendra Rathour, <lokendrarathour(a)gmail.com> > wrote: > >> Hi All, >> Was trying to create OpenStack VM in OpenStack wallaby release, not able >> to create VM, it is failing because of Port not getting created. >> >> The error that we are getting: >> nova-compute.log: >> >> 2023-05-16 18:15:35.495 7 INFO nova.compute.provider_config >> [req-faaf38e7-b5ee-43d1-9303-d508285f5ab7 - - - - -] No provider configs >> found in /etc/nova/provider_config. If files are present, ensure the Nova >> process has access. >> 2023-05-16 18:15:35.549 7 ERROR nova.cmd.common >> [req-8842f11c-fe5a-4ad3-92ea-a6898f482bf0 - - - - -] No db access allowed >> in nova-compute: File "/usr/bin/nova-compute", line 10, in <module> >> sys.exit(main()) >> File "/usr/lib/python3.6/site-packages/nova/cmd/compute.py", line 59, >> in main >> topic=compute_rpcapi.RPC_TOPIC) >> File "/usr/lib/python3.6/site-packages/nova/service.py", line 264, in >> create >> utils.raise_if_old_compute() >> File "/usr/lib/python3.6/site-packages/nova/utils.py", line 1068, in >> raise_if_old_compute >> ctxt, ['nova-compute']) >> File "/usr/lib/python3.6/site-packages/nova/objects/service.py", line >> 563, in get_minimum_version_all_cells >> binaries) >> File "/usr/lib/python3.6/site-packages/nova/context.py", line 544, in >> scatter_gather_all_cells >> fn, *args, **kwargs) >> File "/usr/lib/python3.6/site-packages/nova/context.py", line 432, in >> scatter_gather_cells >> with target_cell(context, cell_mapping) as cctxt: >> File "/usr/lib64/python3.6/contextlib.py", line 81, in __enter__ >> return next(self.gen) >> >> >> neutron/ovn-metadata-agent.log >> >> 2023-05-16 22:33:41.871 45204 ERROR ovsdbapp.backend.ovs_idl.command >> ovsdbapp.backend.ovs_idl.idlutils.RowNotFound: Cannot find Chassis_Private >> with name=b6e6f0d3-40c6-4d4e-8ef6-c935fa027bd2 >> 2023-05-16 22:33:41.871 45204 ERROR ovsdbapp.backend.ovs_idl.command >> 2023-05-16 22:36:41.876 45204 ERROR ovsdbapp.backend.ovs_idl.transaction >> [-] Traceback (most recent call last): >> File >> "/usr/lib/python3.6/site-packages/ovsdbapp/backend/ovs_idl/connection.py", >> line 131, in run >> txn.results.put(txn.do_commit()) >> File >> "/usr/lib/python3.6/site-packages/ovsdbapp/backend/ovs_idl/transaction.py", >> line 93, in do_commit >> command.run_idl(txn) >> File >> "/usr/lib/python3.6/site-packages/ovsdbapp/backend/ovs_idl/command.py", >> line 172, in run_idl >> record = self.api.lookup(self.table, self.record) >> File >> "/usr/lib/python3.6/site-packages/ovsdbapp/backend/ovs_idl/__init__.py", >> line 208, in lookup >> return self._lookup(table, record) >> File >> "/usr/lib/python3.6/site-packages/ovsdbapp/backend/ovs_idl/__init__.py", >> line 268, in _lookup >> row = idlutils.row_by_value(self, rl.table, rl.column, record) >> File >> "/usr/lib/python3.6/site-packages/ovsdbapp/backend/ovs_idl/idlutils.py", >> line 114, in row_by_value >> raise RowNotFound(table=table, col=column, match=match) >> ovsdbapp.backend.ovs_idl.idlutils.RowNotFound: Cannot find >> Chassis_Private with name=b6e6f0d3-40c6-4d4e-8ef6-c935fa027bd2 >> >> any input to help get this issue fixed would be of great help. >> thanks >> -- >> ~ Lokendra >> skype: lokendrarathour >> >> >> -- ~ Lokendra skype: lokendrarathour

2 3

[tc] Technical Committee next weekly meeting on May 30, 2023
by Nikolla, Kristi 29 May '23

29 May '23

Hi all, This is a reminder that the next weekly Technical Committee meeting is to be held on Tuesday, May 30, 2023 at 1800 UTC on #openstack-tc on OFTC IRC. The up-to-date agenda for the meeting can be found at https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting Thank you, Kristi Nikolla

1 0

[neutron] Bug Deputy Report May 22 - 28
by Yatin Karel 29 May '23

29 May '23

Hello Neutron Team !! Please find bug report from May 22nd to 28th, Undecided bugs needs further triage:- *Critical:-* - https://bugs.launchpad.net/neutron/+bug/2020363 - [stable/train/] openstacksdk-functional-devstack fails with POST_FAILURE Fixed with https://review.opendev.org/c/openstack/neutron/+/883890 Assigned to ykarel *High:-* - https://bugs.launchpad.net/neutron/+bug/2020698 - neutron-tempest-plugin-bgpvpn-bagpipe job unstable Job made non voting temporary with https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/884270 Assigned to bhaley - https://bugs.launchpad.net/neutron/+bug/2021457 - [fwaas]The firewall group without any port in active status Fix proposed https://review.opendev.org/c/openstack/neutron-fwaas/+/884335 Assigned to ZhouHeng *Medium:-* - https://bugs.launchpad.net/neutron/+bug/2020802 - Make DB migration "Add indexes to RBACs" conditional Unassigned *Low:-* - https://bugs.launchpad.net/neutron/+bug/2020552 - trunk_details missing sub port MAC addresses for LIST Requested more info Unassigned *Wishlist:-* - https://bugs.launchpad.net/neutron/+bug/2020358 - [RFE] Allow to limit conntrack entries per tenant to avoid "nf_conntrack: table full, dropping packet" Unassigned - https://bugs.launchpad.net/neutron/+bug/2020823 - [RFE] Add flavor/service provider support to routers in the L3 OVN plugin Assigned to Miguel Lavalle *Undecided:-* - https://bugs.launchpad.net/neutron/+bug/2020771 - [ml2/ovn] Binding_host_id shouldn't be set when a port is down Requested more info - https://bugs.launchpad.net/neutron/+bug/2020349 - Neutron Dynamic Routing : Connection to peers lost Discussion ongoing, possible misconfiguration - https://bugs.launchpad.net/neutron/+bug/2020328 - Concurrent create VM failed because of vif plug timeout Requested more info Thanks and Regards Yatin Karel

1 0

[nova][ops] EOL'ing stable/train ?
by Sylvain Bauza 26 May '23

26 May '23

Hi folks, in particular operators... We discussed yesterday during the nova meeting [1] about our stable branches and eventually, we were wondering whether we should EOL [2] the stable/train branch for Nova. Why so ? Two points : 1/ The gate is failing at the moment for the branch. 2/ Two CVEs (CVE-2022-47951 [3] and CVE-2023-2088 [4]) aren't fixed in this branch. It would be difficult to fix the CVEs in the upstream branch but hopefully AFAIK all the OpenStack distros already fixed them for their related releases that use Train. So, any concerns ? TBH, I'm not really happy with EOL, but it would be bizarre if we say "oh yeah we support Train backports" but we don't really fix the most important issues... -Sylvain (who will propose the train-eol tag change next week if he doesn't see any concern before) [1] https://meetings.opendev.org/meetings/nova/2023/nova.2023-05-23-16.01.log.h… [2] https://docs.openstack.org/project-team-guide/stable-branches.html#end-of-l… [3] https://security.openstack.org/ossa/OSSA-2023-002.html [4] https://security.openstack.org/ossa/OSSA-2023-003.html

4 3

[nova]vnc and spice used together in openstack
by 啧啧啧 26 May '23

26 May '23

Hi, When using the console, we enabled both nova spicehtml5proxy and nova novancproxy on the controller node, and enabled vnc and spice on compute1 and compute2, respectively. We found that there was a problem with the coexistence of the two, The log is as follows.  ERROR oslo_messaging.rpc.server [req-28674cdd-f06e-466f-8611-516efc8fbe3c 069c1371a95e4ebaa59eea6ee70362bc dd4e9ff713be4311978334ae0d0c0a5e - default default] Exception during message handling: ValueError: Field `port' cannot be None 2023-05-25 10:58:05.851 7 ERROR oslo_messaging.rpc.server Traceback (most recent call last): 2023-05-25 10:58:05.851 7 ERROR oslo_messaging.rpc.server   File "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_messaging/rpc/server.py", line 165, in _process_incoming 2023-05-25 10:58:05.851 7 ERROR oslo_messaging.rpc.server     res = self.dispatcher.dispatch(message) 2023-05-25 10:58:05.851 7 ERROR oslo_messaging.rpc.server   File "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_messaging/rpc/dispatcher.py", line 274, in dispatch 2023-05-25 10:58:05.851 7 ERROR oslo_messaging.rpc.server     return self._do_dispatch(endpoint, method, ctxt, args) 2023-05-25 10:58:05.851 7 ERROR oslo_messaging.rpc.server   File "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_messaging/rpc/dispatcher.py", line 194, in _do_dispatch 2023-05-25 10:58:05.851 7 ERROR oslo_messaging.rpc.server     result = func(ctxt, **new_args) 2023-05-25 10:58:05.851 7 ERROR oslo_messaging.rpc.server   File "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_messaging/rpc/server.py", line 235, in inner 2023-05-25 10:58:05.851 7 ERROR oslo_messaging.rpc.server     return func(*args, **kwargs) 2023-05-25 10:58:05.851 7 ERROR oslo_messaging.rpc.server   File "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/exception_wrapper.py", line 79, in wrapped 2023-05-25 10:58:05.851 7 ERROR oslo_messaging.rpc.server     function_name, call_dict, binary, tb) 2023-05-25 10:58:05.851 7 ERROR oslo_messaging.rpc.server   File "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py", line 220, in __exit__ 2023-05-25 10:58:05.851 7 ERROR oslo_messaging.rpc.server     self.force_reraise() 2023-05-25 10:58:05.851 7 ERROR oslo_messaging.rpc.server   File "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py", line 196, in force_reraise 2023-05-25 10:58:05.851 7 ERROR oslo_messaging.rpc.server     six.reraise(self.type_, self.value, self.tb) 2023-05-25 10:58:05.851 7 ERROR oslo_messaging.rpc.server   File "/usr/lib/python3.6/site-packages/six.py", line 693, in reraise 2023-05-25 10:58:05.851 7 ERROR oslo_messaging.rpc.server     raise value 2023-05-25 10:58:05.851 7 ERROR oslo_messaging.rpc.server   File "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/exception_wrapper.py", line 69, in wrapped 2023-05-25 10:58:05.851 7 ERROR oslo_messaging.rpc.server     return f(self, context, *args, **kw) 2023-05-25 10:58:05.851 7 ERROR oslo_messaging.rpc.server   File "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/manager.py", line 219, in decorated_function 2023-05-25 10:58:05.851 7 ERROR oslo_messaging.rpc.server     kwargs['instance'], e, sys.exc_info()) 2023-05-25 10:58:05.851 7 ERROR oslo_messaging.rpc.server   File "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py", line 220, in __exit__ 2023-05-25 10:58:05.851 7 ERROR oslo_messaging.rpc.server     self.force_reraise() 2023-05-25 10:58:05.851 7 ERROR oslo_messaging.rpc.server   File "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py", line 196, in force_reraise 2023-05-25 10:58:05.851 7 ERROR oslo_messaging.rpc.server     six.reraise(self.type_, self.value, self.tb) 2023-05-25 10:58:05.851 7 ERROR oslo_messaging.rpc.server   File "/usr/lib/python3.6/site-packages/six.py", line 693, in reraise 2023-05-25 10:58:05.851 7 ERROR oslo_messaging.rpc.server     raise value 2023-05-25 10:58:05.851 7 ERROR oslo_messaging.rpc.server   File "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/manager.py", line 207, in decorated_function 2023-05-25 10:58:05.851 7 ERROR oslo_messaging.rpc.server     return function(self, context, *args, **kwargs) 2023-05-25 10:58:05.851 7 ERROR oslo_messaging.rpc.server   File "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/manager.py", line 5906, in get_spice_console 2023-05-25 10:58:05.851 7 ERROR oslo_messaging.rpc.server     access_url_base=CONF.spice.html5proxy_base_url, 2023-05-25 10:58:05.851 7 ERROR oslo_messaging.rpc.server   File "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_versionedobjects/base.py", line 307, in __init__ 2023-05-25 10:58:05.851 7 ERROR oslo_messaging.rpc.server     setattr(self, key, kwargs[key]) 2023-05-25 10:58:05.851 7 ERROR oslo_messaging.rpc.server   File "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_versionedobjects/base.py", line 72, in setter 2023-05-25 10:58:05.851 7 ERROR oslo_messaging.rpc.server     field_value = field.coerce(self, name, value) 2023-05-25 10:58:05.851 7 ERROR oslo_messaging.rpc.server   File "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_versionedobjects/fields.py", line 207, in coerce 2023-05-25 10:58:05.851 7 ERROR oslo_messaging.rpc.server     return self._null(obj, attr) 2023-05-25 10:58:05.851 7 ERROR oslo_messaging.rpc.server   File "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_versionedobjects/fields.py", line 185, in _null 2023-05-25 10:58:05.851 7 ERROR oslo_messaging.rpc.server     raise ValueError(_("Field `%s' cannot be None") % attr) 2023-05-25 10:58:05.851 7 ERROR oslo_messaging.rpc.server ValueError: Field `port' cannot be None I don't know why there is an appeal issue or what special mechanism OpenStack has for the console. I can only choose one. I hope you can help us. Thank you very much.

2 1

[neutron] Neutron drivers meeting cancelled
by Rodolfo Alonso Hernandez 26 May '23

26 May '23

Hello Neutrinos: Due to the lack of agenda [1], today's meeting is cancelled. Have a nice weekend! [1]https://wiki.openstack.org/wiki/Meetings/NeutronDrivers

1 0