January 2024 - openstack-discuss - lists.openstack.org

[openstack][kolla-ansible]about group node config overwrite
by Nguyễn Hữu Khôi 29 Oct '25

29 Oct '25

Hello Koller. I want to ask if we can overwrite config for a group of nodes. For example, compute01 >> compute10 will have the same nova configuration compute11 >> compute20 will have the same nova configuration. It will be very nice if we support this way. Thank you. Regards Nguyen Huu Khoi

4 7

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 23 Dec '24

23 Dec '24

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

4 4

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

26 Nov '24

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

4 3

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

24 Nov '24

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

2 2

[nova][libvirtd] internal error: unable to execute QEMU command 'query-named-block-nodes'
by Satish Patel 22 Oct '24

22 Oct '24

Folks, I have a ceph cluster and recently I configured rbd-mirror to replicate all data to remove ceph cluster for disaster recovery. Yesterday for POC we did a hard cutover on ceph and point openstack to the new cluster. All other vms came back up fine but 2 vms stuck in this error state in libvirt logs 2024-01-31 22:44:37.591+0000: 474597: error : qemuMonitorJSONCheckErrorFull:399 : internal error: unable to execute QEMU command 'query-named-block-nodes': cannot read image start for probe: Permission denied If it's a wider issue than it should impact all the vms but why only two VM stuck and not starting and libvirt giving me this error in logs nova-compute logs also showing same error 2024-01-31 22:44:40.925 7 INFO nova.compute.manager [None req-b33485b5-8740-48ae-8b5b-a440de3f11a4 c48fcfb9347f413f92fcece065644b00 ca5c652478c7429e964257990800e9cb - - default default] [instance: 2de0f880-77c7-4d2c-9e01-898c57ad3693] Successfully reverted task state from powering-on on failure for instance. 2024-01-31 22:44:40.944 7 ERROR oslo_messaging.rpc.server [None req-b33485b5-8740-48ae-8b5b-a440de3f11a4 c48fcfb9347f413f92fcece065644b00 ca5c652478c7429e964257990800e9cb - - default default] Exception during message handling: libvirt.libvirtError: internal error: unable to execute QEMU command 'query-named-block-nodes': cannot read image start for probe: Permission denied

3 8

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

10 Oct '24

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

5 9

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

06 Aug '24

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

5 16

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

16 May '24

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

18 27

[kolla-ansible] support for FWaaS/LBaaS?
by garcetto 15 May '24

15 May '24

good morning, does kolla support fwaas or lbaas? thank you

3 4

[all][packaging][release][qa] pep-517 and pip 23
by smooney＠redhat.com 06 May '24

06 May '24

hi folks, TL;DR ----- this is a long email so the tl;dr is we should add pyproject.toml ``` [build-system] requires = ["pbr>=5.7.0", "setuptools>=36.6.0", "wheel"] build-backend = "pbr.build" ``` to all openstack projects to supprot pip 23.1+ Long version ------------ As some of you may know the ptg happend last week an done of hte topic raised there was a know limitation in devstack where GLOBAL_VENV=True does not work on centos/fedora derived distros. while i generally dont use centos/fedora derived distros for my daily work i have been using devstack for over 10 years at this point so when im told it broken i ocationlly will go fix it. In this case the issue is not with devstack (it often isnt) and is actully in our collective reliance on a deprecated functionality and how we package openstack today. Back story, for better or worse when openstack was created the landscape of python packaging was significantly different then it is today. To help corodinate our dependcies the openstack comunity went all in on requirements.txt and developed upper-constraits to manage our requirements and developed PBR (python build Reasonableness). both of those approches have served us well and likely will continue to do so for some time. Since then pyproject.toml has started to gain popularity and pep-517 (A build-system independent format for source trees) has been adotpted but so far openstack as a comunity has not embraced those changes. (although pbr already supprot pep-517 :) ). Until now this has not been a problem however with recent release of pip things are now breaking. Problem Context: - openstack does not provide pyporject.toml files - openstack project configure setuptools to use pbr via setup.py - setuptools support generating scripts form entry points(console_scripts) which we use for project binaries( nova- compute, neutron-server, ...) - openstack api services use a pbr extension know as wsgi_scripts which adds a similar functionality for generating wsgi application mains file - devstack due to coming changes in distro to block "sudo pip install" now installs openstack in a single by default on debian distros. on centos/fedora distros it currently almost functional (but not). - devstack installs in editable mode because that is how most developers use devstack for developemnt What changed: - pip 20.2 deprecated support for falling back to calling setup.py when pyproject.toml is not present - https://pip.pypa.io/en/stable/news/#v20-2 - https://github.com/pypa/pip/issues/8368 - at this point when pyproject.yaml is not called pip calls setup.py install [-e] <path to repo or package name> - setup.py invokes pbr to generate wsgi_scripts and other files - in pip 23.1 the fallback was removed https://pip.pypa.io/en/stable/news/#v23-1 - pip now builds a temp local wheel instead of calling setup.py install when pyproject.toml is not found - in editable mode (-e) the default way the wheel is built does not invoke pbr properly to generate the wsgi files - as a result the wsgi files are not installed to the venv bin dir and this causes devstack to fail to start keystone (or any other wsgi api) The fix, there are a few ways to approch this: - clamp pip (https://review.opendev.org/c/openstack/devstack/+/898845) this is a terible idea and it breaks debian - clamping pip below 23.1 works on centos for now however OVS on debian already requires pep 517 for installing - as such when that version of ovs (or other projects start enforcing that) hits centos it will break - add a minimal pyproject.toml to all openstack project - example for keystone https://review.opendev.org/c/openstack/keystone/+/899519 - this example jsut adds the minium pyproject.toml to enable pbr to be used as the build system - it does not remove supprot for setup.py but it will not be used by default going forward whit new version of pip - all config is still in setup.cfg - add pyproject.toml support but remove setup.py support https://review.opendev.org/c/opendev/bindep/+/816741 - this goes one step futrue and actuly nulls out setup.py - we could take this approach if we want to but its not required. The reason for this email is to get agreement on how to support pip 23.1+ My proposal would be to add pyproject.toml with the minimal config required to enable pip 23.2 but not drop the setup.py support in this cycle. i would suggest that we can deprecate installing via setup.py in caracal if that is desirable but not make that change until the next slurp to give time to projects and packages to catch up. if there are no objections to that i would like to ask what is the preferd way to create and submit the patches for the minimal pyproject.toml ``` [build-system] requires = ["pbr>=5.7.0", "setuptools>=36.6.0", "wheel"] build-backend = "pbr.build" ``` i can propose patches to the main project deployed by devstack by default. i.e. nova/neutron ectra but it might be better if someone form the core teams of each project could take on that task and chasing the reviews. if someone has a script to generate a patch for a set of repos that just add the above pyporject.toml then we can use that to keep a consistent topic/commit message across all patches. my proposal for testing this is two fold. in ci we can test the patches are functional by using a DNM patch to devstack to force enable the gloal venv on centos and depend on the set of patches, i will modify https://review.opendev.org/c/openstack/devstack/+/898845 to do that locally we can test that the patch is functional by doing the following substituting keystone for the relevant project. ``` git clone https://opendev.org/openstack/keystone cd keystone python3 -m venv .venv . .venv/bin/activate python3 -m pip install -U pip python3 -m pip install -e . ls .venv/bin/keystone* ``` the ls will not contain the wsgi script with the addition of the pyproject.toml it should. on debian sid i can reproduce the same issue the problem we are seeing on centos 9 now will start impacting other distos eventually so its good to fix this now. if i start proposing this to glance/nova/neutron/cinder/swift/horizon/placement (to get a default devstack working) can i get cores to review? can cores form each project nominate peopel to review or volenteer to do this work. i have created https://etherpad.opendev.org/p/pep-517-and-pip-23 to track this work i have some other work that i think we can do in parallel like addign pyporject.toml support to the pti requirements if we go this way but that i think we can discuss on a governacne patch to updated it. anyway this is a lot to digest so feedback is welcome. if someone else would like to drive this that is also welcome (i.e. tc/release team) regards sean.

10 27

Accessing virsh in openstack wallaby | tripleo
by Swogat Pradhan 24 Mar '24

24 Mar '24

Hi, Can someone please tell me how can i access the virsh utility on the compute node on openstack wallaby? Previously we used nova_libvirt but in wallaby there are multiple containers and i am unable to use virsh utility to edit my domain.xml file. List of containers: [root@dcn01-hci-2 ~]# podman ps | grep nova 10d981158842 172.25.201.68:8787/tripleomaster/openstack-nova-libvirt:current-tripleo kolla_start 2 months ago Up 2 months ago nova_virtlogd_wrapper e91667516afc 172.25.201.68:8787/tripleomaster/openstack-nova-libvirt:current-tripleo kolla_start 2 months ago Up 2 months ago nova_virtsecretd a4b07fe0e833 172.25.201.68:8787/tripleomaster/openstack-nova-libvirt:current-tripleo kolla_start 2 months ago Up 2 months ago nova_virtnodedevd d7e1db393e9c 172.25.201.68:8787/tripleomaster/openstack-nova-libvirt:current-tripleo kolla_start 2 months ago Up 2 months ago nova_virtstoraged 5308a171793e 172.25.201.68:8787/tripleomaster/openstack-nova-libvirt:current-tripleo kolla_start 2 months ago Up 2 months ago nova_virtqemud f490a6249ba1 172.25.201.68:8787/tripleomaster/openstack-nova-libvirt:current-tripleo kolla_start 2 months ago Up 6 weeks ago nova_virtproxyd ab0441e56957 172.25.201.68:8787/tripleomaster/openstack-nova-compute:current-tripleo kolla_start 2 months ago Up 2 months ago (healthy) nova_migration_target f35fbba5b690 172.25.201.68:8787/tripleomaster/openstack-nova-compute:current-tripleo kolla_start 2 months ago Up 6 weeks ago (unhealthy) nova_compute 82bc01993106 172.25.201.68:8787/tripleomaster/openstack-nova-libvirt:current-tripleo /usr/sbin/virtlog... 2 months ago Up 2 months ago Can someone please suggest how I can i edit an instance xml file in this setup? With regards, Swogat Pradhan

2 5

[Freezer] Is Freezer dead?
by pi3.14＠tuta.io 18 Mar '24

18 Mar '24

Hi folks, is Freezer still supported? I don't see any real development going on with it. Is it recommended to use in a production Cloud environment? Are there other free and open source alternatives to Freezer? Thanks Roby

8 19

[swift] Increase part power on account/container ring
by Thiago De Moraes Teixeira 13 Mar '24

13 Mar '24

Morning, Here we have a cluster with Accounts/Containers ring with part power 8 and our Objects ring with part power 20 (builted later). Now we want to migrate the 'old' Accounts/Containers ring to a new one, with higher part power, like 20. Is there a better way to do this? I'm doing some crazy tests with SAIO and multiples storage nodes, based in build a new ring with part power 20 and just swap the old files (account/container.ring.gz) with the new ones and let the replicators do their jobs, moving *.db files to their new home partition. Until today these tests worked fine, but I don't know how to do it on a large scale, with some terabytes of data. Just wondering about some ways to do that :) And before/after this change, is there any command in swift that i can audit this entire process, ensuring that cluster data remains the same? Thanks! -- _‘Esta mensagem é direcionada apenas para os endereços constantes no cabeçalho inicial. Se você não está listado nos endereços constantes no cabeçalho, pedimos-lhe que desconsidere completamente o conteúdo dessa mensagem e cuja cópia, encaminhamento e/ou execução das ações citadas estão imediatamente anuladas e proibidas’._ * **‘Apesar do Magazine Luiza tomar todas as precauções razoáveis para assegurar que nenhum vírus esteja presente nesse e-mail, a empresa não poderá aceitar a responsabilidade por quaisquer perdas ou danos causados por esse e-mail ou por seus anexos’.*

3 8

[heat][monasca][sahara][senlin] Features dependent on inactive projects
by Takashi Kajinami 08 Mar '24

08 Mar '24

Hello, As you know, some of the OpenStack projects were marked inactive during this cycle. There are still on-going discussions but from my view these are very likely excluded from the upcoming 2024.1 release and it's unclear yet if any of these projects will be kept. Currently heat provides features integrated with some of the inactive projects (Monasca, Sahara and Senlin), and we have to decide how we deal with these features[1]. The main concern is that we can't maintain the features for the inactive projects, and IMO we should retire these features if these inactive projects are abandoned or are no longer maintained in the consistent way with the other active projects. Based on the current situation, I'd propose the following steps for upcoming cycles. - Deprecate the features dependent on inactive projects in 2023.2 release - Note that we have to remove these features directly during this cycle in case any problems related to these project block the upcoming heat release. - Remove these features in 2024.1 release unless we are sure that these projects are kept maintained as active projects in the openstack namespace, with following the global release cycle. Please let me know if you have any concern about the proposed plan. If I hear no objections then I'll propose patches for deprecation. Thank you, Takashi Kajinami irc: tkajinam [1] I've submitted a series of patches to remove these features and these would give a clear view about the features affected. https://review.opendev.org/q/topic:%22inactive-project-removal%22+project:o…

3 6

[cinder][glance][nova][telemetry][monasca][oslo][vmware] Can we deprecate(and remove) VMWare support ?
by Takashi Kajinami 07 Mar '24

07 Mar '24

Hi all, As you might know, some of the OpenStack projects currently support usage of VMWare component. However recently the VMware virt driver in nova was marked experimental in 2023.2 release [1] and it has been discussed that the driver will be removed in 2023.2 release[2], after deprecation is backported to 2023.1. (Please someone from nova team correct me if I'm wrong) So my current question is; Does it make sense to deprecate all of the features to support VMWare component ? My understanding is that these features were added to be used along with VMWare virt driver in nova, but once the virt driver is removed this use case is voided. I'll list up the features within the discussion scope below. nova: VMWare virt driver (this is already experimental by [1]) cinder: VMware Storage Driver (vmdk) glance: VMWare Datastore (I proposed deprecating this in [3][4]) ceilometer: VMWare virt driver (this was deprecated by [5]) os-brick: VmdkConnector monasca-agent: vcenter collector (*1) oslo.vmware: the whole project NOTE: These features are found based on dependency on oslo.vmware but there can be a few not listed here. Outside of OpenStack's governance, there are two projects dependent on oslo.vmware, networking-vsphere and vmware-nsx but both of these look inactive. Because of SLURP, we have to complete deprecation during in 2024.1 release so that we can drop the feature right after 2024.1. If we fail then we have to maintain these features until 2025.1 (the features already deprecated can be removed earlier, though). So I'd like to get feedback and decision before deadline for 2024.1 Thank you, Takashi (*1) Monasca is now inactive so I doubt anyone would work on this topic before it is retired. [1] https://review.opendev.org/c/openstack/nova/+/863911 [2] https://review.opendev.org/c/openstack/nova/+/897017 [3] https://review.opendev.org/c/openstack/glance_store/+/893696 [4] https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… [5] https://review.opendev.org/c/openstack/ceilometer/+/894540

6 21

[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

[openstack][skyline] Some works with skyline
by Nguyễn Hữu Khôi 25 Feb '24

25 Feb '24

Hello guys. I am working on Skyline. I can integrate my monitor tab on it. I will try to do something about it. If it works properly, I can contribute. It is a very nice project. I hope it will grow and grow in the future. Thanks Skyline Team. [image: image.png] Nguyen Huu Khoi

3 7

[tc][murano] Status of the murano project
by Takashi Kajinami 20 Feb '24

20 Feb '24

Hello, As I brought in another thread about yaql library maintenance[1], It seems murano project is not active now, based on the following points. * The changes merged during recent two years but all of these are gate fix * Its CI is currently broken and no one is trying to fix it * I tried reaching the current PTL by email or gerrit review but didn't get any feedback even after waiting for a few weeks I'm wondering if murano project should be added to the inactive projects, or at least its project health and plan needs to be reviewed by TC, before we include this to Caracal deliverables. # Though it might be too later to drop the deliverables now Thank you Takashi Kajinami irc: tkajinam [1] https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack…

4 15

Encountering a live migration issue on Kolla Ansible Deployment
by khurshidsx＠gmail.com 15 Feb '24

15 Feb '24

Hello all, I recently set up a cluster using Kolla Ansible, but I'm encountering a live migration issue. I would appreciate any advice or insights you can provide. Error Message is rule:create_port_binding is disallowed by policy Neutron server returns request_ids: ['req-dce2d22c-349b-4759-a0f2-8bebbfbb1aee'] Here are some logs: 2024-01-25 04:55:51.599 23 INFO neutron.api.v2.resource [req-a380e1bc-a94b-4935-be0d-76fcc94becc4 req-dce2d22c-349b-4759-a0f2-8bebbfbb1aee 636854b888d7441eafcd21255e1378f1 b07c4b6d7b2241c187ed84f30b163817 - - default default] create failed (client error): Access was denied to this resource. 2024-01-25 04:55:51.601 23 INFO neutron.wsgi [req-a380e1bc-a94b-4935-be0d-76fcc94becc4 req-dce2d22c-349b-4759-a0f2-8bebbfbb1aee 636854b888d7441eafcd21255e1378f1 b07c4b6d7b2241c187ed84f30b163817 - - default default] 192.168.252.254,192.168.252.12 "POST /v2.0/ports/e70fab29-d0cd-4db4-8fbc-a572da1bff64/bindings HTTP/1.1" status: 403 len: 308 time: 0.0207033 Neutron server returns request_ids: ['req-dce2d22c-349b-4759-a0f2-8bebbfbb1aee'] 2024-01-25 04:55:51.815 19 ERROR nova.conductor.manager Neutron server returns request_ids: ['req-dce2d22c-349b-4759-a0f2-8bebbfbb1aee'] 2024-01-25 04:55:51.815 19 ERROR nova.conductor.manager Neutron server returns request_ids: ['req-dce2d22c-349b-4759-a0f2-8bebbfbb1aee'] Neutron server returns request_ids: ['req-dce2d22c-349b-4759-a0f2-8bebbfbb1aee']: nova.exception.Forbidden: rule:create_port_binding is disallowed by policy

3 5

[neutron][vpnaas][ovn] Pushing VPNaaS support through OVN
by Mohammed Naser 12 Feb '24

12 Feb '24

Hi all! One of the biggest show stoppers for us for OVN is VPNaaS but I think it’s time that we’d like to be involved in getting it over the line, I want to thank Bodo who has shown a lot of patience in getting the code necessary, and it seems that the code works for them in production as well. I’d like to ask if possible for folks to review these two outstanding changes: https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/847007 https://review.opendev.org/c/openstack/neutron-vpnaas/+/765353 I know Slawek had some concerns, so hoping that raising via the email list if Bodo can address those and over the next bit of time we can get this landed in, since it even has actual proper testing both in CI and with user feedback. Thanks! Mohammed

6 8

about magnum capi for production
by Nguyễn Hữu Khôi 07 Feb '24

07 Feb '24

Hello guys. Could you share with me some experience about using Magnum CAPI in production? https://github.com/vexxhost/magnum-cluster-api Thank you so much. Nguyen Huu Khoi

6 44

Glance image import to AWS S3 fails for files larger than 5GB
by Shrishail K 05 Feb '24

05 Feb '24

Hi Team, I have a use case where I need to replicate images from file store to S3 store. While image creation directly on S3 works fine with large files over 5G. The same fails when attempted via image-import with copy-image method. The failure is due to AWS rejecting a single object upload operation where the object size is over 5GB. What I see from logs is that direct image creation on S3 uses multipart upload when images are large. However, I fail to see the same happening when image import was used to copy an image from file to s3. Is this a known issue? Or Am I missing some configs related to image-import? Openstack version: Antelope Client version: 6.4.0 Thanks, Shrishail

3 14

[puppet] Retiring puppet-qdr
by Takashi Kajinami 05 Feb '24

05 Feb '24

Hello, Let me restore my old proposal[1] about puppet-qdr. # I lost access to my old emails so I'm starting a new thread. In the previous mail I proposed deprecation instead of retirement, because the module has been used by TripleO. However I noticed that TripleO is now under the process of complete retirement[2]. So, I'd like to revise my proposal, and propose retiring the module completely. Please let me know if you have any concern with this module retired. Unless I hear any objections, I'll start the official retirement process. [1] https://lists.openstack.org/pipermail/openstack-discuss/2023-August/034742.… [2] https://review.opendev.org/c/openstack/governance/+/905145 Thank you, Takashi Kajinami irc: tkajinam

2 2

[fwaas][devstack] help configuring dashboard
by garcetto 05 Feb '24

05 Feb '24

good morning, is there some tutorial on how to configure fwaas web dashboard on devstack? thank you.

2 1

[nova] Help with support to SGX
by Winicius Allan 05 Feb '24

05 Feb '24

Hello o/ Anyone already work with Nova to provide VMs with SGX support?

6 7

[all] SQLAlchemy 2.x support in Bobcat
by Thomas Goirand 02 Feb '24

02 Feb '24

Hi, As you may know, and to my great frustration, I'm not the maintainer of SQLAlchemy in Debian, even though OpenStack is the biggest consumer of it. The current maintainer insists that he wants to upload SQLA 2.x in Unstable, potentially breaking all of OpenStack. At the present moment, if I understand correctly, we're not there yet, and Bobcat doesn't have such a support. It would be ok for me, *IF* there are patches available on master, that I could backport to Bobcat and maintain in the debian/patches folder of each project. However, the biggest current annoyance, is that I have no idea where we are at. Are we close to such a support? Is there a list of patches to apply on top of Bobcat that is maintained somewhere? Please enlighten me... :) Cheers, Thomas Goirand (zigo)

5 10

RE: [cinder] Inactive 3rd party CIs
by Roquesalane, Jean-Pierre 01 Feb '24

01 Feb '24

Thanks Takashi for driving this. As far as Dell is concerned, those CIs should be marked as unsupported as they are now EOL. * DellEMC SC CI * DellEMC VNX CI * DellEMC XtremIO CI I'll have the CI team to take a look at the Dell PowerMax CI which is supposed to be active. 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@01DA545A.5A50B740] Dell SAS, Si?ge Social 1 rond point Benjamin Franklin 34000 Montpellier. Capital 1,946,545.26 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) Internal Use - Confidential

3 7

Re: [kolla-ansible][magnum] question
by Oliver Weinmann 01 Feb '24

01 Feb '24

Hi Franck, glad that I was able to help. Sorry I don't know about this one. But a quick google revealed this: https://docs.fedoraproject.org/en-US/fedora-coreos/sysconfig-configure-swap… Looks as if the FCOS image has this enabled somehow. I have updated my blogpost on CAPI in MAGNUM. It is finally working and its way faster to deploy Kubernetes. This will no longer use FCOS images but Ubuntu or FLATCAR. Maybe you want to give it a try: https://www.roksblog.de/openstack-magnum-cluster-api-driver/ Have a nice weekend. Cheers, Oliver Am 05.01.2024 um 17:07 schrieb Franck VEDEL: > Hi Oliver. > Thanks for you help !! > > I took the time to consult the help concerning > Magnum(https://docs.openstack.org/magnum/2023.1/user/) and this > article > (https://www.roksblog.de/deploy-kubernetes-clusters-in-openstack-within-minu…) > > > > I understood a lot of things, even though I'm not a Kubernetes expert. > Everything works as I wanted, except for one detail. > Do you know why we get this type of message (and quite a few minutes > to wait) when creating a node: > Capture d’écran 2024-01-05 à 15.43.04.png > > zram_generator…………. no configuration found. > > This is the last point that I cannot improve. Maybe there's nothing we > can do. > Thank you once again, that’s really very nice. > > > Franck VEDEL > > > > >> Le 3 janv. 2024 à 12:26, Oliver Weinmann <oliver.weinmann(a)me.com> a >> écrit : >> >> Hi Franck, >> >> Great. Glad it works. That is the k8s version and the url where >> magnum will pull the container from. The official docs are quite >> helpful. In the latest Openstack release bobcat there is already some >> support for CAPI. It is not 100% working out of the Box but it looks >> very promising. I have taken my blog post offline since I didn’t >> manage to get it working. But I will look into it again in the next >> couple of days. >> >> Cheers, >> Oliver >> >> Von meinem iPhone gesendet >> >>> Am 03.01.2024 um 12:21 schrieb Franck VEDEL >>> <franck.vedel(a)univ-grenoble-alpes.fr>: >>> >>> Hi Oliver, >>> and thanks a lot for your help. >>> I followed the instructions on the blog and indeed, with [trust] it >>> works. >>> I'm trying to understand everything. what are the parameters for: >>> >>> |--labels kube_tag=v1.21.11-rancher1,hyperkube_prefix=docker.io/rancher/| >>> >>> Thanks in advance >>> >>> Franck >>> >>> >>> >>>> Le 25 déc. 2023 à 19:26, Franck VEDEL >>>> <franck.vedel(a)univ-grenoble-alpes.fr> a écrit : >>>> >>>> Hi Oliver and thanks you for this help. >>>> >>>> I was wrong in my explications. >>>> I had seen this article (roksblog.de ) and I did what it said: >>>> I first tried: >>>> enable_cluster_user_trust = True in globals.yml >>>> It didn't work. >>>> >>>> I then made the modification in /etc/kolla/config/magnum.conf: >>>> cluster_user_trust = True >>>> >>>> Same problem. >>>> >>>> That's why I asked the question. Is this really the way to do it? >>>> If so, I will have to restart the containers (keystone?) >>>> >>>> Franck >>>> >>>> >>>> >>>>> Le 25 déc. 2023 à 18:40, Oliver Weinmann <oliver.weinmann(a)me.com> >>>>> a écrit : >>>>> >>>>> Hi Frank, >>>>> >>>>> According to the official kolla docs the option needs to be in >>>>> globals.yml >>>>> >>>>> Ensure that you understand the consequences before enabling this >>>>> option. In|globals.yml|: >>>>> >>>>> In case this also doesn’t work, you can try: >>>>> >>>>> yoga) [vagrant@seed ~]$ cat /etc/kolla/config/magnum.conf >>>>> [trust] >>>>> cluster_user_trust = True >>>>> >>>>> *www.roksblog.de >>>>> >>>>> Cheers, >>>>> Oliver >>>>> >>>>> Von meinem iPhone gesendet >>>>> >>>>>> Am 25.12.2023 um 18:10 schrieb Franck VEDEL >>>>>> <franck.vedel(a)univ-grenoble-alpes.fr>: >>>>>> >>>>>> enable_cluster_user_trust = True >>>> >>> >

2 2

Keystone LDAP backend: need to change user_id_attribute from CN to SAMAccountName
by Michel Jouvin 01 Feb '24

01 Feb '24

Hi, For historical (and bad) resons, we decided 10 years ago when we created our cloud that the Keystone LDAP backend will use the CN as the user_id_attribute rather than the usual SAMAccountName. Since then it has been a source of various problems with CN changes, accented characters in CN... We'd like to change it to SAMAccountName but there is clearly no easy/supported way of doing it and we are looking for some information on the best way to do it and the risks if somebody has some clues... It should impact ~30 users so not a huge number... What we have in mind is basically: - Change the backend attribute - Import new accounts - Assign the new accounts to the same projects as the ol accounts, with the same role One of the foreseen problemsis that old and new accounts will share the same user_name_attribute, based on SAMAccountName. It is not allowed by openstack if I'm right so for the scenario to work we need to change the user_name_attribute of old accounts to something different (we don't care that the user cannot use the account during the transition peroid as long as it doesn't impact active resources). Is it enough to update it in the database? We'd prefer to keep the old accounts in OpenStack until the end of the transition... Another minor issue is the reassignment of keypairs to the new account. It is poosble to ask the user to reload its public keys but we were wondering it there was a not too risky way of doing it for him/her by updating the DB (I guess there is no API for this). Thanks in advance if you have any thought/information to share. Best regards. Michel

3 5

sqlite vs NULL
by Pete Zaitcev 31 Jan '24

31 Jan '24

Greetings: In short: Should it be possible to select by key that is NULL in our DBs? This is needed for Cinder, review 657543[1]. Tests run on sqlite. Long explanation: The review tinkers with SQL Alchemy's query, so it may be doing it wrong. However, I looked at the queries and this seems to happen. A query for everything finds the NULL entry. The query looks like this: SELECT backups.created_at AS backups_created_at, (... very many AS ...) FROM backups LEFT OUTER JOIN backup_metadata AS backup_metadata_1 ON backup_metadata_1.backup_id = backups.id AND backup_metadata_1.deleted = false WHERE backups.deleted = false AND backups.host = %(host_1)s So, the entry is in the database. However, this one returns everything that matches the arguments, but not the one with key of NULL: SELECT backups.created_at AS backups_created_at, (... very many AS ...) FROM backups LEFT OUTER JOIN backup_metadata AS backup_metadata_1 ON backup_metadata_1.backup_id = backups.id AND backup_metadata_1.deleted = false WHERE backups.deleted = false AND backups.status IN (%(status_1)s, %(status_2)s, %(status_3)s, %(status_4)s, %(status_5)s, %(status_6)s, NULL) AND backups.host = %(host_1)s ORDER BY backups.created_at DESC, backups.id DESC The backup with a NULL status is in the DB, but I cannot get it with objects.BackupList.get_all(ctxt, filters={'status': (None,)}) One other thing: Is there an easy way to make negative query through SQLalchemy? My real task is to find all the backups that are not stable (complete and error), so that I can restart it. Thanks for any suggestions, -- Pete [1] https://review.opendev.org/c/openstack/cinder/+/657543

3 3

Cinder Bug Report 2024-01-31
by Jon Bernard 31 Jan '24

31 Jan '24

Hello Argonauts, Apologies for the hiatus. Between holidays, snow days, and sick days, January has been quite a month. Here are current bugs for this week, we will resume the bug meetings after the weekly upstream meeting next week. Cinder Bug Meeting Etherpad <https://etherpad.opendev.org/p/cinder-bug-squad-meeting> Undecided - Support for the "bring your own keys" approach for Cinder <https://bugs.launchpad.net/cinder/+bug/2051108> - Status: New - Documentation of Ceph auth caps for RBD clients used by Cinder / Glance / Nova is missing or inconsistent <https://bugs.launchpad.net/cinder/+bug/2051244> - Status: New - Dell PowerMax driver issues restapi version 92 for Unisphere 10.1 <https://bugs.launchpad.net/cinder/+bug/2051828> - Status: In Progress - Dell PowerMax: Add timeout when PowerMax does not return RESTAPI call <https://bugs.launchpad.net/cinder/+bug/2051830> - Status: In Progress - Fibre channel not scanning all targets <https://bugs.launchpad.net/os-brick/+bug/2051237> - Status: In Progress Thanks, -- Jon

1 0

What are the correct auth caps for Ceph RBD clients of Cinder / Glance / Nova
by Christian Rohmann 31 Jan '24

31 Jan '24

Hey openstack-discuss, I am a little confused about correct and required Ceph authx permissions for the RBD clients in Cinder, Glance and also Nova: When Glance is requested to delete an image it will check if this image has depended children, see https://opendev.org/openstack/glance_store/src/commit/6f5011d1f05c99894fb8b…. The children of Glance images usually are (Cinder) volumes, which therefore live in a different RBD pool "volumes". But if such children do exist a 500 error is thrown by Glance API. There also is an bug about this issue on Launchpad [3]. Manually using the RBD client shows the same error: > # rbd -n client.glance -k /etc/ceph/ceph.client.glance.keyring -p > images children $IMAGE_ID > > 2023-12-13T16:51:48.131+0000 7f198cf4e640 -1 > librbd::image::OpenRequest: failed to retrieve name: (1) Operation not > permitted > 2023-12-13T16:51:48.131+0000 7f198d74f640 -1 librbd::ImageState: > 0x5639fdd5af60 failed to open image: (1) Operation not permitted > rbd: listing children failed: (1) Operation not permitted > 2023-12-13T16:51:48.131+0000 7f1990c474c0 -1 librbd::api::Image: > list_descendants: failed to open descendant b7078ed7ace50d from pool > instances:(1) Operation not permitted So it's a permission error. Following either the documentation of Glance [1] or Ceph [2] on configuring the ceph auth caps there is no mention of granting anything towards the volume pool to Glance. So this is what I currently have configured: > client.cinder > key: REACTED > caps: [mgr] profile rbd pool=volumes, profile rbd-read-only > pool=images > caps: [mon] profile rbd > caps: [osd] profile rbd pool=volumes, profile rbd-read-only > pool=images > > client.glance > key: REACTED > caps: [mgr] profile rbd pool=images > caps: [mon] profile rbd > caps: [osd] profile rbd pool=images > > client.nova > key: REACTED > caps: [mgr] profile rbd pool=instances, profile rbd pool=images > caps: [mon] profile rbd > caps: [osd] profile rbd pool=instances, profile rbd pool=images > When granting the glance client e.g. "rbd-read-only" to the volumes pool via: > > # ceph auth caps client.glance mon 'profile rbd' osd 'profile rbd > pool=images, profile rbd-read-only pool=volumes' mgr 'profile rbd > pool=images, profile rbd-read-only pool=volumes' > the error is gone. I am wondering through if this is really just a documentation bug (at OpenStack AND Ceph equally) and if Glance really needs read-only on the whole volumes pool or if there is some other capability that covers asking for child images. All in all I am simply wondering what the correct and least-privilege ceph auth caps for the RBD clients in Cinder, Glance and Nova would look like. Thanks Christian [1] https://docs.openstack.org/glance/latest/configuration/configuring.html#con… [2] https://docs.ceph.com/en/latest/rbd/rbd-openstack/#setup-ceph-client-authen… [3] https://bugs.launchpad.net/glance/+bug/2045158

6 15

[cinder] This week's meeting will be in video+IRC
by Rajat Dhasmana 31 Jan '24

31 Jan '24

Hello Argonauts, As we keep last meeting of the month in video + IRC mode, this week's meeting (today) will be held in video + IRC mode with details as follows: Date: 31st January, 2024 Time: 1400 UTC Meeting link: https://meet.google.com/mmb-fhtd-sjm IRC Channel: #openstack-meeting-alt Make sure you're connected to both the gmeet meeting and IRC. Thanks Rajat Dhasmana

1 0

[all][oslo][ironic][tc] Eventlet version bumps (topic:bump-eventlet in gerrit)
by Jay Faulkner 31 Jan '24

31 Jan '24

Hi all, https://review.opendev.org/q/topic:%22bump-eventlet%22 was pushed recently, to bump eventlet versions to a consistent lower bound across OpenStack projects. I saw some concerns about this across various OpenStack IRC channels, and wanted to start a larger conversation around the changes rather than having what would be my third separate small conversation about it :). I cannot speak to exactly why Herve pushed these changes, but I think they are a good idea and should be merged. If you're unaware or haven't read up on the context; versions of eventlet before 0.34 were released with minimal/failing CI, and done so with known bugs in many cases. A group of developers has taken the last months to improve the state of eventlet considerably, enhancing and improving CI, discovering and fixing known issues and enabling support for Python 3.12. From my perspective; this is a significant enough improvement to warrant our community moving forward generally[0] with setting a new higher low bound for eventlet -- the versions that are maintained. I do think that we can do a better job of advertising the value of this change in gerrit to other OpenStack contributors; simply stating it's for python 3.12 support downplays the significant improvements made across that project and the overall value of landing the version bump. I am unsure if we should advertise the improvements in a user/operator facing manner; I lean towards not doing so. From a single project perspective (with my Ironic PTL hat on): I have no desire to troubleshoot bugs in Ironic, or related projects, that only occur in eventlet versions prior to 0.34. This leads me to believe landing those changes in Ironic are the good path forward, and I'll be advocating for that inside Ironic. Thanks, Jay Faulkner OpenStack TC Chair OpenStack Ironic PTL 0: I'll note this should not be read as a suggestion of a mandate; only that it's a good idea to bump this requirement in OpenStack projects and should be done unless cores for that project see a specific reason why not.

2 6

[cinder] qos don t keep modifications
by garcetto 31 Jan '24

31 Jan '24

good evening, i was trying qos on cinder volumes, and it is working fine, BUT i found that if i modify the qos limits, or update or even remove them the actual vols that already have the previous iops limits do NOT thake new values...the newly created vols yes, the old ones not...is it a bug or is it normal? here i create a 100 iops limit, set on volumes type, THEN modify it, even reboot istance, BUT old value persisist... [image: image.png] thank you.

3 3

Openstack-Ansible External Networking OVN (Br-ex)
by jjjamesg 31 Jan '24

31 Jan '24

I can't for the life of me get external connectivity working, openstack itself works i just cant get external connectivity working, I can see ovs has created br-ex with bond1 attached. ovs-vsctl get open . external_ids:ovn-bridge-mapping shows: "physnst1:br-ex" I have tried creating the network with both: openstack network create --share --external --provider-physical-network physnet1 --provider-network-type vlan --provider-segment 233 public openstack network create --share --external --provider-physical-network physnet1 --provider-network-type flat publicnet-flat Only errors i can see is in the neutron container when i try and either create an instance on said network or attach a fip is is: (similar errors from a vlan type network this is just the error i pulled at the time) ERROR neutron.plugins.ml2.managers [req-de7f1cb8-ac8e-4dd6-ad2a-e14afdb152b5 req-c6a2aaff-ccf9-4ef3-9ef 7-1a8e4c7a1e41 9c27de6bdc4449abbbbcd5e5c4951bb9 2fced1ff77f5428eb2b63879bdd608cc - - default default] Failed to bind port 03cc1708-d4a2-4b11-bca2-40ebe0acff60 on host 02 for vnic_type normal using segments [{'id': '2ef64682-b5ff-472b-935d-a3c2b615d70f', 'network_type': 'flat', 'physical_network': 'physnet1', 'segmentation_id': None, 'network_id': '52b4f4e9-47f3-431b-8c45-ec8cc17f561d'}] WARNING neutron.scheduler.dhcp_agent_scheduler [None req-aafa81d9-479c-4f56-be6f-54d4ab3b42aa 1b29a 2297a224cdcaaba84e0eac30205 bafabcf2414d4adf98cab165c3f3de12 - - default default] No more DHCP agents WARNING neutron.api.rpc.agentnotifiers.dhcp_rpc_agent_api [None req-aafa81d9-479c-4f56-be6f-54d4ab3b42aa 1b29a2297a224cdcaaba84e0eac30205 bafabcf2414d4adf98cab165c3f3de12 - - default default] Unable to schedule network 5fa049f5-0ed4-4287-9c63-dd753c853c35: no agents available; will retry on subsequent port and subnet creation events. I just cant figure out WHY this isn't working.. Below is my config: ############# ### /etc/network/interfaces: ############# auto bond1 iface bond1 inet manual bond-slaves eno2 eno4 bond-mode 802.3ad bond-miimon 100 bond-downdelay 200 bond-updelay 200 bond-lacp-rate 1 mtu 9000 auto bond1.30 iface bond1.30 inet manual vlan-raw-device bond1 ## (br-pubv is for my public vip) auto bond1.232 iface bond1.232 inet manual vlan-raw-device bond1 auto br-overlay iface br-overlay inet static bridge_stp off bridge_waitport 0 bridge_fd 0 bridge_ports bond1.30 address auto br-pubv iface br-pubv inet static address gateway bridge_stp off bridge_waitport 0 bridge_fd 0 bridge_ports bond1.232 ############# ### openstack_user_config.yml: ############# - network: container_bridge: "br-ex" network_interface: "bond1" type: "vlan" range: "232:332" net_name: "physnet1" group_binds: - neutron_ovn_controller ############# ### user_variables.yml ############# neutron_plugin_type: ml2.ovn neutron_plugin_base: - ovn-router - qos - neutron.services.ovn_l3.plugin.OVNL3RouterPlugin - neutron_dynamic_routing.services.bgp.bgp_plugin.BgpPlugin - vpnaas - metering - firewall_v2 neutron_ml2_drivers_type: "vlan,local,geneve,flat" neutron_provider_networks: network_types: "geneve" network_geneve_ranges: "1:1000" network_vlan_ranges: "physnet1" network_mappings: "physnet1:br-ex" network_interface_mappings: "br-ex:bond1" Bond1 is a trunk port (no native vlan), that has access to both overlay vlan and the 232:332 vlan range which both work when setting either network as a bridge on bond1 so connectivity is there. I have network-northd/gateway_hosts defined as well as: neutron_neutron_conf_overrides: ovn: enable_distributed_floating_ip: True openstack_host_specific_kernel_modules: - name: "openvswitch" pattern: "CONFIG_OPENVSWITCH" This should by all accounts just work, but for some reason for me it's not, what steps have i missed?

4 8

Incorrectly implemented service tokens in kolla-ansible
by Franciszek Przewoźny 30 Jan '24

30 Jan '24

Hi all, Can someone from kolla-ansible development have a look into that: https://bugs.launchpad.net/kolla-ansible/+bug/2049762 ? As for now, the provided configuration is totally different to what's described in manual. Thanks! Franciszek Przewoźny

2 2

[masakari][masakari-monitors] Feature to monitor hosts by kubernetes
by dogyun kim 30 Jan '24

30 Jan '24

Hi team masakari! I'm using openstack on kubernetes and also masakari for HA. I have developed a function monitoring by using kubernetes api internally to masakari-monitors for k8s-native openstack and want to contribute. blueprint link : https://blueprints.launchpad.net/masakari/+spec/host-monitors-by-kubernetes

5 5

[cinder] Inactive 3rd party CIs
by Takashi Kajinami 30 Jan '24

30 Jan '24

Hi, While I was trying to get a fresh restult from DellEMC VNX CI in [1], I noticed that some of the 3rd part CIs are inactive and haven't been posted any results for a long period. # See [2] and the list below. Note that the list may contain CIs for retired drivers. I'm wondering if someone from the cinder team can review the status and reach the vendors maintaining these CIs. If any of these are no longer working and there is no plan to recover these then I believe we have to mark the associated volume drivers unsupported and then remove these in a future release. Thank you, Takashi irc: tkajinam [1] https://review.opendev.org/c/openstack/cinder/+/834805 [2] http://cinderstats.ivehearditbothways.com/cireport.txt $ grep -B 2 -E 'last seen: 20(1|2[0123])' cireport.txt Checking name: Brocade Openstack CI - https://wiki.openstack.org/wiki/ThirdPartySystems/Brocade_Openstack_CI first seen: 2019-03-07 02:43:59 (1781 days, 23:21:11 old) https://review.opendev.org/641539 last seen: 2019-06-17 20:36:40 (1679 days, 5:28:30 old) https://review.opendev.org/562053 -- Checking name: Cloudbase Cinder SMB3 CI - https://wiki.openstack.org/wiki/ThirdPartySystems/Cloudbase_Cinder_SMB3_CI first seen: 2022-08-24 06:02:19 (515 days, 20:03:06 old) https://review.opendev.org/854268 last seen: 2022-11-02 13:32:21 (445 days, 12:33:04 old) https://review.opendev.org/863276 -- Checking name: DataCore CI - https://wiki.openstack.org/wiki/ThirdPartySystems/DataCore_CI first seen: 2018-10-11 20:55:57 (1928 days, 5:09:33 old) https://review.opendev.org/593191 last seen: 2020-02-13 14:16:20 (1438 days, 11:49:10 old) https://review.opendev.org/707643 -- Checking name: DellEMC PowerMAX CI - https://wiki.openstack.org/wiki/ThirdPartySystems/DellEMC_PowerMAX_CI first seen: 2022-06-17 12:14:23 (583 days, 13:51:32 old) https://review.opendev.org/821745 last seen: 2023-11-29 12:13:36 (53 days, 13:52:19 old) https://review.opendev.org/902106 -- Checking name: DellEMC SC CI - https://wiki.openstack.org/wiki/ThirdPartySystems/DellEMC_SC_CI first seen: 2022-05-24 00:06:06 (608 days, 2:00:17 old) https://review.opendev.org/839257 last seen: 2023-03-26 19:21:14 (301 days, 6:45:09 old) https://review.opendev.org/877583 -- Checking name: DellEMC VNX CI - https://wiki.openstack.org/wiki/ThirdPartySystems/DellEMC_VNX_CI first seen: 2021-09-11 03:27:04 (862 days, 22:39:38 old) https://review.opendev.org/760199 last seen: 2022-05-26 21:42:33 (605 days, 4:24:09 old) https://review.opendev.org/842131 -- Checking name: DellEMC XtremIO CI - https://wiki.openstack.org/wiki/ThirdPartySystems/DellEMC_XtremIO_CI first seen: 2021-11-17 06:06:53 (795 days, 19:59:58 old) https://review.opendev.org/818037 last seen: 2022-04-11 17:06:22 (650 days, 9:00:29 old) https://review.opendev.org/836211 -- Checking name: Fungible Storage CI - https://wiki.openstack.org/wiki/ThirdPartySystems/Fungible_Storage_CI first seen: 2023-02-21 10:45:34 (334 days, 15:21:31 old) https://review.opendev.org/843493 last seen: 2023-05-25 11:17:36 (241 days, 14:49:29 old) https://review.opendev.org/880275 -- Checking name: Hedvig CI - https://wiki.openstack.org/wiki/ThirdPartySystems/Hedvig_CI first seen: 2020-11-04 02:16:19 (1173 days, 23:50:53 old) https://review.opendev.org/761160 last seen: 2020-11-20 13:10:00 (1157 days, 12:57:12 old) https://review.opendev.org/762884 -- Checking name: HPE Nimble Storage CI - https://wiki.openstack.org/wiki/ThirdPartySystems/HPE_Nimble_Storage_CI first seen: 2023-04-20 19:24:38 (276 days, 6:42:42 old) https://review.opendev.org/877755 last seen: 2023-07-31 10:12:19 (174 days, 15:55:01 old) https://review.opendev.org/886456 -- Checking name: HPE Storage CI - https://wiki.openstack.org/wiki/ThirdPartySystems/HPE_Storage_CI first seen: 2016-07-21 05:02:38 (2740 days, 21:04:54 old) https://review.opendev.org/344766 last seen: 2016-08-09 22:53:51 (2721 days, 3:13:41 old) https://review.opendev.org/318737 -- Checking name: HPMSA CI - https://wiki.openstack.org/wiki/ThirdPartySystems/HPMSA_CI first seen: 2023-06-07 03:02:16 (228 days, 23:05:25 old) https://review.opendev.org/850002 last seen: 2023-12-05 15:15:09 (47 days, 10:52:32 old) https://review.opendev.org/900513 -- Checking name: Huawei FusionStorage CI - https://wiki.openstack.org/wiki/ThirdPartySystems/Huawei_FusionStorage_CI first seen: 2019-02-21 15:07:45 (1795 days, 11:00:03 old) https://review.opendev.org/635203 last seen: 2020-07-23 09:23:28 (1277 days, 16:44:20 old) https://review.opendev.org/742136 -- Checking name: Huawei Volume CI - https://wiki.openstack.org/wiki/ThirdPartySystems/Huawei_Volume_CI first seen: 2018-02-09 08:03:20 (2172 days, 18:04:47 old) https://review.opendev.org/542700 last seen: 2018-06-12 10:12:22 (2049 days, 15:55:45 old) https://review.opendev.org/574508 -- Checking name: IBM GPFS CI - https://wiki.openstack.org/wiki/ThirdPartySystems/IBM_GPFS_CI first seen: 2017-08-30 23:39:19 (2335 days, 2:28:56 old) https://review.opendev.org/499271 last seen: 2022-01-25 14:29:37 (726 days, 11:38:38 old) https://review.opendev.org/819011 -- Checking name: IBM Storage CI - https://wiki.openstack.org/wiki/ThirdPartySystems/IBM_Storage_CI first seen: 2021-10-25 15:30:42 (818 days, 10:37:42 old) https://review.opendev.org/809518 last seen: 2023-07-11 09:37:45 (194 days, 16:30:39 old) https://review.opendev.org/880518 -- Checking name: Infortrend CI - https://wiki.openstack.org/wiki/ThirdPartySystems/Infortrend_CI first seen: 2020-01-10 07:03:58 (1472 days, 19:04:35 old) https://review.opendev.org/694379 last seen: 2020-05-01 16:25:58 (1360 days, 9:42:35 old) https://review.opendev.org/722806 -- Checking name: INSPUR CI - https://wiki.openstack.org/wiki/ThirdPartySystems/INSPUR_CI first seen: 2019-08-13 20:31:35 (1622 days, 5:37:05 old) https://review.opendev.org/676274 last seen: 2020-06-09 02:34:51 (1321 days, 23:33:49 old) https://review.opendev.org/734395 -- Checking name: Intel RSD CI - https://wiki.openstack.org/wiki/ThirdPartySystems/Intel_RSD_CI first seen: 2020-08-22 20:40:00 (1247 days, 5:28:49 old) https://review.opendev.org/747540 last seen: 2020-09-30 20:50:30 (1208 days, 5:18:19 old) https://review.opendev.org/746267 -- Checking name: Kaminario K2 CI - https://wiki.openstack.org/wiki/ThirdPartySystems/Kaminario_K2_CI first seen: 2019-09-03 21:12:51 (1601 days, 4:56:06 old) https://review.opendev.org/679785 last seen: 2020-05-02 20:21:51 (1359 days, 5:47:06 old) https://review.opendev.org/724548 -- Checking name: openstack lightbits - https://wiki.openstack.org/wiki/ThirdPartySystems/openstack_lightbits first seen: 2023-01-18 14:02:54 (368 days, 12:06:19 old) https://review.opendev.org/865429 last seen: 2023-10-30 15:55:42 (83 days, 10:13:31 old) https://review.opendev.org/792209 -- Checking name: LINBIT LINSTOR CI - https://wiki.openstack.org/wiki/ThirdPartySystems/LINBIT_LINSTOR_CI first seen: 2019-12-23 08:12:07 (1490 days, 17:57:14 old) https://review.opendev.org/700296 last seen: 2020-04-04 21:33:05 (1387 days, 4:36:16 old) https://review.opendev.org/717383 -- Checking name: MacroSAN Volume CI - https://wiki.openstack.org/wiki/ThirdPartySystems/MacroSAN_Volume_CI first seen: 2019-06-21 02:47:54 (1675 days, 23:21:27 old) https://review.opendev.org/666477 last seen: 2019-08-21 12:59:52 (1614 days, 13:09:29 old) https://review.opendev.org/674156 -- Checking name: Mellanox CI - https://wiki.openstack.org/wiki/ThirdPartySystems/Mellanox_CI first seen: 2021-12-02 22:17:29 (780 days, 3:51:59 old) https://review.opendev.org/733622 last seen: 2022-01-27 23:20:17 (724 days, 2:49:11 old) https://review.opendev.org/818830 -- Checking name: NetApp SolidFire CI - https://wiki.openstack.org/wiki/ThirdPartySystems/NetApp_SolidFire_CI first seen: 2022-01-07 03:00:03 (744 days, 23:09:43 old) https://review.opendev.org/796114 last seen: 2022-12-27 10:41:51 (390 days, 15:27:54 old) https://review.opendev.org/853126 -- Checking name: Nexenta CI - https://wiki.openstack.org/wiki/ThirdPartySystems/Nexenta_CI first seen: 2023-05-18 19:46:37 (248 days, 6:23:16 old) https://review.opendev.org/881470 last seen: 2023-12-18 12:42:24 (34 days, 13:27:29 old) https://review.opendev.org/903883 -- Checking name: ProphetStor CI - https://wiki.openstack.org/wiki/ThirdPartySystems/ProphetStor_CI first seen: 2018-04-05 22:54:14 (2117 days, 3:15:54 old) https://review.opendev.org/559172 last seen: 2018-11-27 18:08:32 (1881 days, 8:01:36 old) https://review.opendev.org/603283 -- Checking name: qnap-ci - https://wiki.openstack.org/wiki/ThirdPartySystems/qnap-ci first seen: 2016-12-01 08:58:50 (2607 days, 17:11:33 old) https://review.opendev.org/313140 last seen: 2019-03-27 21:38:37 (1761 days, 4:31:46 old) https://review.opendev.org/648174 -- Checking name: Quobyte CI - https://wiki.openstack.org/wiki/ThirdPartySystems/Quobyte_CI first seen: 2020-08-05 14:17:31 (1264 days, 11:53:01 old) https://review.opendev.org/742491 last seen: 2020-10-26 22:12:30 (1182 days, 3:58:02 old) https://review.opendev.org/754728 -- Checking name: SandStone Storage CI - https://wiki.openstack.org/wiki/ThirdPartySystems/SandStone_Storage_CI first seen: 2019-09-04 11:39:43 (1600 days, 14:30:51 old) https://review.opendev.org/679970 last seen: 2020-04-19 05:55:57 (1372 days, 20:14:37 old) https://review.opendev.org/720678 -- Checking name: Seagate CI - https://wiki.openstack.org/wiki/ThirdPartySystems/Seagate_CI first seen: 2023-01-27 08:03:49 (359 days, 18:06:55 old) https://review.opendev.org/851640 last seen: 2023-05-25 22:32:18 (241 days, 3:38:26 old) https://review.opendev.org/884253 -- Checking name: Synology DSM CI - https://wiki.openstack.org/wiki/ThirdPartySystems/Synology_DSM_CI first seen: 2020-09-04 18:45:57 (1234 days, 7:25:05 old) https://review.opendev.org/749996 last seen: 2020-11-20 08:17:25 (1157 days, 17:53:37 old) https://review.opendev.org/757082 -- Checking name: TOYOU TYDS CI - https://wiki.openstack.org/wiki/ThirdPartySystems/TOYOU_TYDS_CI first seen: 2021-11-20 16:22:53 (792 days, 9:48:15 old) https://review.opendev.org/818098 last seen: 2023-10-18 01:25:34 (96 days, 0:45:34 old) https://review.opendev.org/898600 -- Checking name: Veritas Access CI - https://wiki.openstack.org/wiki/ThirdPartySystems/Veritas_Access_CI first seen: 2018-12-11 02:38:26 (1867 days, 23:32:48 old) https://review.opendev.org/624193 last seen: 2019-03-15 10:56:07 (1773 days, 15:15:07 old) https://review.opendev.org/643555 -- Checking name: Virtuozzo Storage CI - https://wiki.openstack.org/wiki/ThirdPartySystems/Virtuozzo_Storage_CI first seen: 2019-08-09 21:32:36 (1626 days, 4:38:47 old) https://review.opendev.org/664860 last seen: 2019-09-25 02:45:11 (1579 days, 23:26:12 old) https://review.opendev.org/639180

4 4

[kolla-ansible] [cinder] how to add 2nd storage?
by garcetto 30 Jan '24

30 Jan '24

good morning, how can i add a second storage (for example another ceph, or nfs...) to my openstack kolla ansible cluster? thank you.

3 5

[cinder][nova] server create boot volume choosing
by garcetto 30 Jan '24

30 Jan '24

good afternoon, i have multiple backend types, so also different volumes types; is there an option on "openstack server create" to also specify the volume type on instance creation time? thank you.

3 4

[kolla-ansible] Static haproxy configuration for manually deployed services
by Jan Wasilewski 29 Jan '24

29 Jan '24

Hi, I wanted to inquire about the possibility of configuring the haproxy service for a non-standard OpenStack service. Specifically, I'm referring to Vault, which I use as a backend for the Barbican service. I would like to configure the haproxy settings somewhat "statically," but I want this configuration to be applied during deployment with kolla-ansible. While inserting non-standard configurations for OpenStack services like Cinder or Barbican in the directory */etc/kolla/config/<openstack_service>/<openstack_service.conf>* works, the same approach doesn't seem to work for haproxy. I have created a configuration for vault.cfg as outlined in [1], but when executing: kolla-ansible -i multinode --tags common,haproxy deploy the configured settings are not being read into the haproxy settings. Am I doing something wrong, or is this functionality not possible in this manner, requiring a different configuration approach? I would appreciate any advice and guidance on this matter. Best regards, /JW References: [1] https://paste.openstack.org/show/bU3ytwRvAopM78S7lg34/

3 3

[kolla-ansible] remove a service and container
by garcetto 29 Jan '24

29 Jan '24

good morning, is it possible to remove a service with kolla-ansible? got the same problems as here ( https://stackoverflow.com/questions/64930136/what-is-the-proper-way-to-remo…) and seems there is no solution ( https://bugs.launchpad.net/kolla-ansible/+bug/1874044) thank you.

2 1

[tc] Technical Committee Meeting Jan 30, 2024 at 1800UTC
by Jay Faulkner 29 Jan '24

29 Jan '24

Hi all, The next meeting of the Technical Committee will be tomorrow, Tuesday January 30 at 1800 UTC in #openstack-tc on OFTC. Please see the proposed agenda below: Agenda - Roll call - Follow up on tracked action items - No action items from Jan 24 meeting. - Gate health check - Implementation of Unmaintained branch statuses - project team guide change: https://review.opendev.org/c/openstack/project-team-guide/+/897505 (in HTML <https://45faea0ad451d95614b7-e39b4e99c90af072f68eb1bcdd078a04.ssl.cf2.rackc…> ) - 2024.1 TC Tracker - https://etherpad.opendev.org/p/tc-2024.1-tracker - Open Discussion and Reviews Thanks, Jay Faulkner OpenStack TC Chair

1 0

Cinder multi availability_zone, nova lookup problems
by Henrik Hansen 29 Jan '24

29 Jan '24

Good evening, we are currently deploying openstack in a two AZ setup, in this setup we have two different SAN FC Boxes which are only reachable via the corresponding zone. Means, we have two cinder instances, each one is configured with a backend service towards the storage. In cinder.conf [storage] we have backend_availability_zone set, towards the correct zone name. If i create two bootable volumes, cinderis selecting the right cinder-schueduler with the right storage: (venv-kolla)# openstack volume create --size 10 --image cirros --availability-zone DUS --bootable DUS_1 +---------------------+--------------------------------------+ | Field | Value | +---------------------+--------------------------------------+ | attachments | [] | | availability_zone | DUS | | bootable | false | | consistencygroup_id | None | | created_at | 2024-01-23T22:22:21.979063 | | description | None | | encrypted | False | | id | 217943c3-44dd-4a8c-aad7-2ab33b17bab3 | | migration_status | None | | multiattach | False | | name | DUS_1 | | properties | | | replication_status | None | | size | 10 | | snapshot_id | None | | source_volid | None | | status | creating | | type | __DEFAULT__ | | updated_at | None | | user_id | 47f5bd8b0f154da69bb2375fcc3a3baf | +---------------------+--------------------------------------+ (venv-kolla)# openstack volume create --size 10 --image cirros --availability-zone LEV --bootable LEV_1 +---------------------+--------------------------------------+ | Field | Value | +---------------------+--------------------------------------+ | attachments | [] | | availability_zone | LEV | | bootable | false | | consistencygroup_id | None | | created_at | 2024-01-23T22:23:12.327244 | | description | None | | encrypted | False | | id | 7850da99-43d0-4b58-9134-a7e7bc930cf0 | | migration_status | None | | multiattach | False | | name | LEV_1 | | properties | | | replication_status | None | | size | 10 | | snapshot_id | None | | source_volid | None | | status | creating | | type | __DEFAULT__ | | updated_at | None | | user_id | 47f5bd8b0f154da69bb2375fcc3a3baf | +---------------------+--------------------------------------+ if i create servers with boot-from-volume and a availability-zone, the job failed. (venv-kolla)# openstack server create --image cirros --boot-from-volume 10 --network fw --flavor m1.tiny --availability-zone DUS DUS1 +-------------------------------------+--------------------------------------+ | Field | Value | +-------------------------------------+--------------------------------------+ | OS-DCF:diskConfig | MANUAL | | OS-EXT-AZ:availability_zone | DUS | | OS-EXT-SRV-ATTR:host | None | | OS-EXT-SRV-ATTR:hypervisor_hostname | None | | OS-EXT-SRV-ATTR:instance_name | | | OS-EXT-STS:power_state | NOSTATE | | OS-EXT-STS:task_state | scheduling | | OS-EXT-STS:vm_state | building | | OS-SRV-USG:launched_at | None | | OS-SRV-USG:terminated_at | None | | accessIPv4 | | | accessIPv6 | | | addresses | | | adminPass | gKsNQTfC6vYe | | config_drive | | | created | 2024-01-23T22:29:47Z | | flavor | m1.tiny (1) | | hostId | | | id | a838b078-cda0-47de-bf5d-0b6cc632425c | | image | N/A (booted from volume) | | key_name | None | | name | DUS1 | | progress | 0 | | project_id | e435c2936cbf4eb9abc38a48181ab9bf | | properties | | | security_groups | name='default' | | status | BUILD | | updated | 2024-01-23T22:29:47Z | | user_id | 47f5bd8b0f154da69bb2375fcc3a3baf | | volumes_attached | | +-------------------------------------+--------------------------------------+ (venv-kolla)# openstack server create --image cirros --boot-from-volume 10 --network fw --flavor m1.tiny --availability-zone LEV LEV1 +-------------------------------------+--------------------------------------+ | Field | Value | +-------------------------------------+--------------------------------------+ | OS-DCF:diskConfig | MANUAL | | OS-EXT-AZ:availability_zone | LEV | | OS-EXT-SRV-ATTR:host | None | | OS-EXT-SRV-ATTR:hypervisor_hostname | None | | OS-EXT-SRV-ATTR:instance_name | | | OS-EXT-STS:power_state | NOSTATE | | OS-EXT-STS:task_state | scheduling | | OS-EXT-STS:vm_state | building | | OS-SRV-USG:launched_at | None | | OS-SRV-USG:terminated_at | None | | accessIPv4 | | | accessIPv6 | | | addresses | | | adminPass | L6vDvCoevTBC | | config_drive | | | created | 2024-01-23T22:30:11Z | | flavor | m1.tiny (1) | | hostId | | | id | 2434f84f-08f3-4e8d-8c8d-67a6b78f2cbe | | image | N/A (booted from volume) | | key_name | None | | name | LEV1 | | progress | 0 | | project_id | e435c2936cbf4eb9abc38a48181ab9bf | | properties | | | security_groups | name='default' | | status | BUILD | | updated | 2024-01-23T22:30:11Z | | user_id | 47f5bd8b0f154da69bb2375fcc3a3baf | | volumes_attached | | +-------------------------------------+--------------------------------------+ in cinder-scheduler.log i see following: Task 'cinder.scheduler.flows.create_volume.ExtractSchedulerSpecTask;volume:create' (93b2aa0f-5cdb-4f13-abdf-416c2b226917) transitioned into state 'SUCCESS' from state 'RUNNING' with result '{'request_spec': RequestSpec(CG_backend=<?>,availability_zones=['nova'] ... The creation of a bootable volume, results in the following log entry: Task 'cinder.scheduler.flows.create_volume.ExtractSchedulerSpecTask;volume:create' (7d6130e8-f9d9-4d3b-bca1-e899690e7855) transitioned into state 'SUCCESS' from state 'RUNNING' with result '{'request_spec': RequestSpec(CG_backend=<?>,availability_zones=['LEV']... So from my understanding, the create request towards nova, results in AvailabilityZone=nova, which the cinder AvailabilityZoneFilter can't handle. Does someone have a idea, how i can fix this behaviour? Thanks in advance! -- Mit freundlichen Grüßen Henrik Hansen

2 1

[devstack] how to change from ovn to ovs?
by garcetto 29 Jan '24

29 Jan '24

good morning, devstack by default install ovn (and in particular l3 ovn agent), BUT i would like to install fwaas v2, that does NOT support ovn, so i would like to set devstack to use plain old ovs, IS IT POSSIBLE? thank you.

3 3

[masakari] How to add blueprint link on masakari meeting agenda?
by 김도균 29 Jan '24

29 Jan '24

3 2

VMs shut themselves down
by Karera Tony 28 Jan '24

28 Jan '24

Hello Team, I have an openstack environment with 4 compute Nodes however yesterday out of the blue, the Instances on one of the compute nodes started shutting themselves down. Then I realized the the compute service was disabled when I checked in Horizon. I enabled it and restarted the instances and all was well but I cant figure out what caused it. I have attached the nova_compute logs here incase someone would like to support https://paste.openstack.org/show/bxqpgjvqT3DlOYWoeejc/ Regards Tony Karera

3 6