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

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

[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

[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

[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

[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

[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

[TC][Monasca] Proposal to mark Monasca as an inactive project
by Sławek Kapłoński 04 Jan '24

04 Jan '24

Hi, I just proposed patch [1] to mark Monasca as inactive project. It was discussed during last TC meeting on 03.10.2023. Reasons for that are described in the commit message of the [1] but I will also put all of it here: previous cycle there wasn't almost any contributions to that project and most active contributors in last 180 days were Elod Illes and Dr. Jens Harbott who were fixing some Zuul configuration issues only. Here are detailed statistics about Monasca projects: Validating Gerrit... * There are 7 ready for review patches generated within 180 days * There are 2 not reviewed patches generated within 180 days * There are 5 merged patches generated within 180 days * Unreviewed patch rate for patches generated within 180 days is 28.0 % * Merged patch rate for patches generated within 180 days is 71.0 % * Here's top 10 owner for patches generated within 180 days (Name/Account_ID: Percentage): - Dr. Jens Harbott : 42.86% - Joel Capitao : 28.57% - Elod Illes : 28.57% Validate Zuul... Set buildsets fetch size to 500 * Repo: openstack/monasca-log-api gate job builds success rate: 82% * Repo: openstack/monasca-statsd gate job builds success rate: 95% * Repo: openstack/monasca-tempest-plugin gate job builds success rate: 81% * Repo: openstack/monasca-common gate job builds success rate: 84% * Repo: openstack/monasca-kibana-plugin gate job builds success rate: 83% * Repo: openstack/monasca-ceilometer gate job builds success rate: 100% * Repo: openstack/monasca-events-api gate job builds success rate: 83% * Repo: openstack/monasca-ui gate job builds success rate: 88% * Repo: openstack/monasca-specs gate job builds success rate: 100% * Repo: openstack/monasca-grafana-datasource gate job builds success rate: 100% * Repo: openstack/monasca-persister gate job builds success rate: 98% * Repo: openstack/monasca-notification gate job builds success rate: 93% * Repo: openstack/monasca-thresh gate job builds success rate: 100% * Repo: openstack/monasca-api gate job builds success rate: 76% * Repo: openstack/monasca-agent gate job builds success rate: 98% * Repo: openstack/python-monascaclient gate job builds success rate: 100% * Repo: openstack/monasca-transform gate job builds success rate: 100% What's next? According to the "Emerging and inactive projects" document [2] if there will be no volunteers who will step up and want to maintain this project before Milestone-2 of the 2024.1 cycle (week of Jan 08 2024) there will be no new release of Monasca in the 2024.1 cycle and TC will discuss if project should be retired. So if You are interested in keeping Monasca alive and active, please reach out to the TC to discuss that ASAP. Thx in advance. [1] https://review.opendev.org/c/openstack/governance/+/897520 [2] https://governance.openstack.org/tc/reference/emerging-technology-and-inact… -- Slawek Kaplonski Principal Software Engineer Red Hat

8 14

[kolla-ansible][zun] Intention to drop support for Zun for the 2023.1 and path forward
by Jan Gutter 21 Dec '23

21 Dec '23

Hi folks, In yesterday's Kolla IRC meeting we discussed the path forward for Zun [1] and came to the conclusion that it might be better for all involved to drop support for Zun for the 2023.1 release until it can be updated to support the necessary dependencies. More specific details at the end of the message. With this in mind, the plan is to start this process in a week from now, unless a better solution is presented. There is still some time for discussion, please don't hesitate! There are two paths forward after this: If Zun can be updated to support the dependencies during the maintenance timeframe of 2023.1, then support would be restored. If no support is available at the time Caracal releases, however, it will be considered for removal in kolla and kolla-ansible. What this means: Kolla-ansible operators currently running Zun should hold off migration to 2023.1. Any development help would of course be appreciated. Please coordinate with the Zun project to help with development. Details on the dependency problems: * Currently, Zun has an external dependency on Docker 20.x, and uses a feature that has been removed in later versions of Docker. * This Docker feature also relies on an older version of etcd (3.3) * The mitigation [2] is to pin to the old versions of Docker and etcd, but this is not possible with Debian Bookworm hosts. Why this is a problem in Kolla-ansible (and Kolla): * This can't easily be solved by vendoring in an older version of etcd: the migration path it introduces to operators would incur a significant amount of risk. * Host level involvement is also particularly painful, the host version of Docker needs to connect to the etcd service running in the containers. * Even though the containers can be kept buildable and the configuration and inventory settings could be maintained, a working setup is not testable in CI. Thanks very much for everyone's patience, contributions and time! [1]: https://meetings.opendev.org/meetings/kolla/2023/kolla.2023-09-13-13.00.log… [2]: https://bugs.launchpad.net/zun/+bug/2007142

2 2

Cyborg nova reports mdev-capable resource is not available
by Karl Kloppenborg 07 Dec '23

07 Dec '23

Hi Cyborg Team! Karl from Helm Team. When creating a VM with the correct flavor, the mdev gets created by cyborg agent and I can see it in the nodedev-list --cap mdev. However Nova then fails with: nova.virt.libvirt.driver [<removed>- - default default] Searching for available mdevs... _get_existing_mdevs_not_assigned /var/lib/openstack/lib/python3.10/site-packages/nova/virt/libvirt/driver.py :8357 2023-09-21 14:34:47.808 1901814 INFO nova.virt.libvirt.driver [<removed> - - default default] Available mdevs at: set(). 2023-09-21 14:34:47.809 1901814 DEBUG nova.virt.libvirt.driver [<removed> - - default default] No available mdevs where found. Creating an new one... _allocate_mdevs /var/lib/openstack/lib/python3.10/site-packages/nova/virt/libvirt/driv er.py:8496 2023-09-21 14:34:47.809 1901814 DEBUG nova.virt.libvirt.driver [<removed> - - default default] Attempting to create new mdev... _create_new_mediated_device /var/lib/openstack/lib/python3.10/site-packages/nova/virt/libvirt/driver.py:8385 2023-09-21 14:34:48.455 1901814 INFO nova.virt.libvirt.driver [<removed> - - default default] Failed to create mdev. No free space found among the following devices: ['pci_0000_4b_03_1', … <truncated list>]. 2023-09-21 14:34:48.456 1901814 ERROR nova.compute.manager [<removed> - - default default] [instance: 2026e2a2-b17a-43ab-adcb-62a907f58b51] Instance failed to spawn: nova.exception.ComputeResourcesUnavailable: Insufficient compute resources: mdev-capable resource is not available. Once this happened, ARQ removes the mdev and cleans up. I’ve got Cyborg 2023.2 running and have a device profile like so: karl@Karls-Air ~ % openstack accelerator device profile show e2b07e11-fe69-4f33-83fc-0f9e38adb7ae +-------------+---------------------------------------------------------------------------+ | Field | Value | +-------------+---------------------------------------------------------------------------+ | created_at | 2023-09-21 13:30:05+00:00 | | updated_at | None | | uuid | e2b07e11-fe69-4f33-83fc-0f9e38adb7ae | | name | VGPU_A40-Q48 | | groups | [{'resources:VGPU': '1', 'trait:CUSTOM_NVIDIA_2235_A40_48Q': 'required'}] | | description | None | +-------------+---------------------------------------------------------------------------+ karl@Karls-Air ~ % I can see the allocation candidate: karl@Karls-Air ~ % openstack allocation candidate list --resource VGPU=1 | grep A40 | 41 | VGPU=1 | 229bf15f-5689-3d2c-b37b-5c8439ea6a71 | VGPU=0/1 | OWNER_CYBORG,CUSTOM_NVIDIA_2235_A40_48Q | karl@Karls-Air ~ % Am I missing something critical here? Because I cannot seem to figure this out… have I got a PCI address wrong, or something? Any help from the Cyborg or Nova teams would be fantastic. Thanks, Karl.

4 9

openstack Vm shutoff by itself
by AJ_ sunny 30 Nov '23

30 Nov '23

Hi team, I am using openstack kolla ansible on wallaby version and currently I am facing issue with virtual machine, vm is shutoff by itself and and from log it seems libvirt lifecycle stop event triggering again and again Logs:- 2023-10-16 08:48:10.971 7 WARNING nova.compute.manager [req-c7b731db-2b61-400e-917f-8645c9984696 f226d81a45dd46488fb2e19515 848 316d215042914de190f5f9e1c8466bf0 default default] [instance: 4b04d3f1-1fbd-4b63-b693-a0ef316ecff3] Received unexpected - vent network-vif-plugged-f191f6c8-dff5-4c1b-94b3-8d91aa6ff5ac for instance with vm_state active and task_state None. 2023-10-21 22:42:44.589 7 INFO nova.compute.manager [-] [instance: 4b04d3f1-1fbd-4b63-b693-a0ef316ecff3] VM Stopped (Lifecyc Event) 2023-10-21 22:42:44.683 7 INFO nova.compute.manager [req-1d99b87b-7ff7-462d-ab18-fbdec6bda71d -] [instance: 4b04d3f1- fbd-4b63-b693-a0ef316ecff3] During _sync_instance_power_state the DB power_state (1) does not match the vm_power_state from ti e hypervisor (4). Updating power_state in the DB to match the hypervisor. 2023-10-21 22:42:44.811 7 WARNING nova.compute.manager [req-1d99b87b-7ff7-462d-ab18-fbdec6bda71d ----] [instance: 4b04d3f 1-1fbd-4b63-b693-a0ef316ecff3] Instance shutdown by itself. Calling the stop API. Current vm_state: active, current task_state : None, original DB power_state: 1, current VM power_state: 4 2023-10-21 22:42:44.977 7 INFO nova.compute.manager [req-1d99b87b-7ff7-462d-ab18-fbdec6bda71d -] [instance: 4b04d3f1-1 fbd-4b63-b693-a0ef316ecff3] Instance is already powered off in the hypervisor when stop is called. Thanks & Regards Arihant Jain +91 8299719369

5 15

[swift][OpenStackSDK][keystone] Warnings about (my) swift endpoint URL by keystoneauth1 discovery
by Christian Rohmann 13 Nov '23

13 Nov '23

Hey openstack-discuss, we use Ceph RadosGW (Quincy release) to provide Swift as part of an OpenStack cloud. The endpoints are configured as such: > # openstack endpoint list > +----------------------------------+--------+--------------+----------------+---------+-----------+----------------------------------------------------------------------+ > | ID | Region | Service Name | Service > Type | Enabled | Interface | URL | > +----------------------------------+--------+--------------+----------------+---------+-----------+----------------------------------------------------------------------+ > | 1234567890 | region | swift | object-store | True | > public | > https://object-store.region.cloud.example.com/swift/v1/AUTH_%(tenant_id)s > | > | 2345678901 | region | swift | object-store | True | > internal | > https://object-store.region.cloud.example.com/swift/v1/AUTH_%(tenant_id)s > | > | 3456789012 | region | swift | object-store | True | > admin | > https://object-store.region.cloud.example.com/swift/v1/AUTH_%(tenant_id)s > | > so according to https://docs.ceph.com/en/latest/radosgw/keystone/#cross-project-tenant-acce…, if I am not mistaken. I can also use the openstack client to access containers: > # openstack container list > +---------------+ > | Name | > +---------------+ > | containera | > | containerb | > +---------------+ and there is no warnings or other apparent issues. But when using "project cleanup" via e.g. "openstack project cleanup --dry-run --project $PROJECT" I see multiple warnings like > Failed to contact the endpoint at > https://object-store.region.cloud.example.com/swift/v1/AUTH_f2bc4bd34567ddc… > for discovery. Fallback to using that endpoint as the base url. > but only mentioning the swift endpoint. Following the warning string this originates from the discovery method of keystoneauth1, see https://github.com/openstack/keystoneauth/blob/28048af9593740315df8d9027c3b…. Could anybody help me understand what is issue might be? Why does this warning not appear for every use of object storage / swift via openstackclient? Is there any way for me to "fix" this? Could this even be a bug? Thanks and with kind regards Christian

4 10

[ptls] [tc] 2023 OpenStack Deployment Data
by Allison Price 09 Nov '23

09 Nov '23

Hi everyone, Apologies for sending this during the PTG as I intended to send this prior, but below is a link to the anonymized data including responses to many project or TC contributed questions. I have removed a significant number of fields to preserve the anonymity of the organizations, but if there is a particular data point that would help your team, please let me know. Cheers, Allison https://docs.google.com/spreadsheets/d/1ehlabuqOnNK4M7xtN1GXvhLoeHn4JBaISih…

2 1

[nova] Nov 7 is a spec review day and Nov 14 is implementation review day
by Sylvain Bauza 06 Nov '23

06 Nov '23

Hey folks, I feel a bit sad to had no time yet to provide you a summary for our PTG, but please wait a bit more :-) That said, something you should already know, we will have two spec review days this cycle and two implementation review days as well, so please mark your calendars for the first to come : - Nov 7 will be a spec review day. Please ensure your specs are ready for reviews - Nov 14 will be an implementation review day. Mark your patches up ! As a reminder, the idea behind those review days is to synchronize our efforts between owners and reviewers so people can discuss at the same time. Thanks, -Sylvain

1 1

[charms] Nominating Utkarsh Bhatt for charms-ceph-core
by Peter Sabaini 03 Nov '23

03 Nov '23

Hello all, I would like to nominate Utkarsh Bhatt for charms-ceph-core. Utkarsh has worked for the Ceph charms team for 1.5 years now and has provided many contributions to the charms, especially to the Ceph charms[0]. I know him as a diligent and enthusiastic contributor and hope you will support his nomination. Thanks, peter. [0] https://review.opendev.org/q/owner:utkarsh.bhatt%2540canonical.com

4 3

[ops] Seeking Advice on Service Deployment and Layout for an 8-Node Cluster
by Forrest Fuqua 02 Nov '23

02 Nov '23

Hi there, I'm currently exploring some strategies and seeking advice on the deployment and layout of services on an 8-node cluster. Each node is equipped with dual AMD EYPC 7702s, two 100G Links, and 2TB of RAM. Additionally, I've set up two 13TB NVME drives in a Ceph configuration for each node. At present, the setup involves one management node, while the others are dedicated to running Nova, Neutron, Glance, and Cinder. The workload, while fairly basic, involves handling substantial numbers. It's primarily used for one-off research projects and a few classes, serving around 60 end users. The most demanding scenario occurs during cybersecurity competitions when we need to deploy 3100 VMs at once. When this is spread out over a few days, it's manageable. However, there's a risk of overloading the system, leading to DiskIO issues and Database inconsistencies. Currently, I'm utilizing Kolla for deployment, and I've shared my configurations on this GitHub repository: Link to Configs<https://github.com/RIT-GCI-CyberRange/openstack-configs>. I'd greatly appreciate any insights or advice on optimizing this setup to handle the peak workload more efficiently and prevent potential performance issues. Thanks in advance for your help!

3 7

[ironic] Announcement: Future of Metalsmith
by Jay Faulkner 01 Nov '23

01 Nov '23

Hi all, Just announcing that at the vPTG, the Ironic core team came to a consensus about the future of the metalsmith project. It was originally created to improve the user experience around provisioning Ironic nodes when using Ironic's API directly. At this, it was mostly successful and has completed this task. It's our intention to work on the Ironic API and python-ironicclient to provide a similarly simple deployment user experience, even for users without nova, integrating lessons learned from the metalsmith project. To this end; we are letting the overall community know we no longer expect to add additional functionality to metalsmith. We will ensure it remains maintained and well-tested until it's functionality has been duplicated, but all new work in this area will be directed at the primary Ironic API and Ironic client projects. To this end, and as discussed at the PTG, I've proposed a change to the Metalsmith readme, notifying users of this state. https://review.opendev.org/c/openstack/metalsmith/+/899761 This change, or this mailing list post, is a great place to comment if you have any comments on this decision. Thanks, Jay Faulkner Ironic PTL

3 3

Openstack volume deletion
by Vijay Thilak S 01 Nov '23

01 Nov '23

Hi, OpenStack Kolla Ansible has been installed on Ubuntu 20 and integrated with Ceph storage. The volume associated with the instance is not being deleted by Cinder when I terminate the instance with this option (Delete Volume on Instance Delete), which is causing me problems. I need to log in to the server and run the cinder commands to manually delete the volume that is not associated with instances. I would appreciate it if you could provide a solution. Thanks, Vijay

4 10

OpenInfra Live: Meet the Computing Force Network Working Group Nov 2 at 9 AM (CST) / 14:00 UTC
by Kristin Barrientos 31 Oct '23

31 Oct '23

Hi everyone, This week’s OpenInfra Live episode is brought to you by the open source community. Episode: China Mobile and other 10+ organizations are driving the effort of Computing Force Network in open source. In July of 2022, organizations like, China Mobile launched the Computing Force Network (CFN) Working Group within the OpenInfra Foundation. You may be wondering, what is Computing Force Network? What open source software is CFN working group going to deliver and how are CFN and related technology going to help the infrastructure? Join us to find out. Date and time: Nov 2, 2023 at 9:00 AM CST (14:00 UTC) You can watch us live on: YouTube: https://www.youtube.com/watch?v=Slc-kOao3BY LinkedIn: https://www.linkedin.com/events/meetthecomputingforcenetworkwor711866369563… WeChat: The recording will be posted on OpenInfra Foundation WeChat after the live stream Speakers: Qihui Zhao, Jie Niu, Xiaoqiao Geng, Changjin Wang, Jintao Wang, Lei Huang and Ildiko Vancsa Thanks, Kristin Barrientos Marketing Coordinator OpenInfra Foundation

1 0

[ironic] IntelIPMIManagement driver: Anyone using it?
by Jay Faulkner 31 Oct '23

31 Oct '23

Hi all, Ironic currently has an Intel IPMI Management driver ( https://docs.openstack.org/ironic/latest/admin/drivers/intel-ipmi.html ), a mild enhancement over our generic IPMI driver, which adds the ability to select an Intel Speed Select Performance Profile via an Ironic automation step. Ironic cores have no knowledge of this driver being used by any deployers of Ironic. We are evaluating it for deprecation and eventual removal. If you are interested in this driver remaining in the Ironic codebase, please let us know. Please note: this is not the same as our generic IPMI driver, which supports power control, boot device management, and is not being considered anytime soon for deprecation :). If we decide to mark the driver for removal, it'll obviously remain in the codebase for a long deprecation period as is our norm. Thanks, Jay Faulkner Ironic PTL

1 0

[largescale-sig] Next meeting: Nov 1, 15utc
by Kristin Barrientos 31 Oct '23

31 Oct '23

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

1 0

[blazar] Cancelling the next IRC meeting
by Pierre Riteau 31 Oct '23

31 Oct '23

Hello, I am cancelling the next Blazar IRC meeting due to being out of the office. The next meeting will be on November 16. Best wishes, Pierre Riteau (priteau)

1 0

[horizon] Cancelling Tomorrow Weekly meeting (1st Nov 2023)
by vishal manchanda 31 Oct '23

31 Oct '23

Hello Team, I won't be able to chair tomorrow's Horizon weekly meeting due to some urgent work at that time. If anything urgent, please reach out to me and the Horizon core team on IRC. Thanks & regards, Vishal Manchanda

1 0

[cinder] 2024.1 (Caracal) PTG Summary
by Rajat Dhasmana 31 Oct '23

31 Oct '23

Hello, Please find the summary of 2024.1 (Caracal) PTG in the wiki page[1]. It includes summary and action items for each topic. More details can be found in the PTG etherpad[2]. I would recommend everyone to please look for the action items assigned to you to plan it according to the cycle deadlines. [1] https://wiki.openstack.org/wiki/CinderCaracalPTGSummary [2] https://etherpad.opendev.org/p/caracal-ptg-cinder Thanks Rajat Dhasmana

1 0

Green threads
by Gk Gk 31 Oct '23

31 Oct '23

Hi All, This may be out of place for this question, but I was reading about this bug https://bugs.launchpad.net/oslo.messaging/+bug/2009138, which led to this query. Do green threads in python need GIL ( global interpreter lock) for execution ? Also, can green threads take advantage of multiple processors ? If yes/no, why ?

1 0

[qa] Office hour day and time change
by Martin Kopec 31 Oct '23

31 Oct '23

Hi everyone, as discussed during the PTG [1] we are changing the date and time of our office hours. The office hour will be taking place on *Wednesdays at 17:00 UTC* [2]. The change is effective *from November 8th*. The meeting agenda is available here [3]. I'm cancelling office hours on Tuesday October 31st and November 7th. [1] https://etherpad.opendev.org/p/oct2023-ptg-qa [2] https://review.opendev.org/c/opendev/irc-meetings/+/899457 [3] https://wiki.openstack.org/wiki/Meetings/QATeamMeeting Thanks, -- Martin Kopec Principal Software Quality Engineer Red Hat EMEA IM: kopecmartin

1 1

capacity planning question.
by KK CHN 30 Oct '23

30 Oct '23

Hi list, I am in need of an infrastructure set up for data analytics / live video stream analytics application using big data and analytics technology.. The data is basically right now stored as structured data(no video streaming) in PostgresDatabase. ( Its an emergency call handling solution, In database which stores, caller info (address, mobile number, locations co-ordinates, emergency category metadata and dispatch information regarding rescue vehicles., Rescue vehicle location update (lat, long)every 30 seconds all are stored in the Postgres Database .. Input1 : I have to do an analytics on these data( say 600 GB for the last 2 years its the size grown from initial setup).To perform an analytical application development( using python and data analytics libraries, and displaying the results and analytical predication through a dashboard application.) Query 1. How much resource in terms of compute(GPU?(CPU) cores required for this analytical application? and memory ? And any specific type of storage(in memory like redis required ? ) etc, which I have to provision for these kind of application processing. ?? any hints most welcome.. Any more input required let me know I can provide if available. Input 2 In addition to the above I have to do video analytics from bodyworn cameras by police personnel, drone surveillance Videos from any emergency sites, patrol vehicle (from a mobile tablet device over 5G )live streaming of indent locations for few minutes ( say 3 to 5 minutes live streaming for each incident. ) There are 50 drones, 500 Emergency rescue service vehicles, 300 body worn camera personnels.. and roughly 5000 incidents / emergency incidents per day happening, which needs video streaming for at least 1000 incidents for a time duration of 4 to 5 minutes live streaming. Query2. What/(how many) kind of computing resources GPUs(CPUs)? RAM, Storage solutions I have to deploy in numbers( or cores of GPUs/how many/(CPUs)? RAM ? In Memory (Redis or similar ) or any other specific data storage mechanisms ? Any hints much appreciated.. Thank in advance, Krishane

1 0

[tacker][ptg] Caracal vPTG Summary
by Yasufumi Ogawa 30 Oct '23

30 Oct '23

Hi all, We had two days session for discussing new proposals for Caracal and reamined items couldn't fixed in the previous release [1]. Here is a summary of the discussion in Tacker team. # Revise FTs Gate tests, especially for functional tests, have been getting mess because of increasing amount of codes without active maintenance. For the issue, we have focused on reducing useless logs. And also re-design directory structure and testcase scenarios. We're going to continue the tasks and will fix it in this release. # Legacy API deprecating/obsoleting It was proposed to drop Tacker's legacy implementation in antelope, and will be completed in this release as planed. # Introducing Cilium CNI for high-performance network connectivity for VNF/CNF This proposal is for a new example app using Cilium CNI as a vRAN usecase in which VNF/CNF requires performance for network connectivity between VMs or containers. The first target is to confirm it's available to deploy with Tacker in a manner of VNF package. # Update requirements for monitoring We have introduced Prometheus for implementing FM/PM interfaces defined in ETSI-NFV standards from Yoga. This proposal is for more advanced feature than monitoring, called as observability, by using OpenTelemetry for considering future requirements. We agreed to implement an additional plugin dedicating to interwork between Otel collector and Tacker. # NFV Orchestration API v2.0 in Tacker Horizon Although many of v2 APIs in ETSI specifications have been implemented, tacker-horizon is not ready for the features. We'll update NFVO interfaces in Horizon to provide v2 features. Current legacy features are going to be dropped instead. # Improving Tacker Document As legacy implementations have been deprecated, documents are also removed. In addition, there are some other sections should be updated such as incorrect usecase guides don'twork, unmaintained operator's guides or so. # Tacker Tempest Plugin Tacker doesn't support tempest, but it's not good for considering if it leads to OpenStack vendors not including Tacker in their products, and also makes Tacker look unhealthy project. So, implement Tacker's tempest plugin and update our zuul jobs to use the plugin for. # Fix vimConnectionID in ResouceHandle In the current implementation, vimConnectionID differs from ETSI specs mistakenly. So, it's should be fixed soon and expected to be small changes. # Secure RBAC This item has been led by NEC team and development of UTs and FTs are under implemention as noted on the vPTG etherpad. However, we need to update ownership of the item for manpreetk moved to another organization. Confirm if NTT or NEC team own the item in caracal and share the result in IRC meeting. # Fix issues which were encounter in compliance test execution In next release of tacker (2024.1), NEC team proposing to make 'tacker-compliance-devstack-multinode-sol' job testing mandatory and voting after some issues occured in the test are fixed. # Maintain tosca-parser and heat-translator Assign team leaders for each projs temporarily for governance, Toshiaki Takahashi for tosca-parser and Ayumu Ueha heat-translator. Ask TC memebers anything requried to change the ownership. [1] https://etherpad.opendev.org/p/oct2023-ptg-tacker Thanks, Yasufumi

1 0

[tc] Weekly Meeting Tomorrow, Oct 31 1800 UTC in OFTC
by Jay Faulkner 30 Oct '23

30 Oct '23

Hi all, The OpenStackTechnical Committee will have our weekly meeting tomorrow, October 31, at 1800 UTC in #openstack-tc on OFTC. All are welcome to attend. The proposed agenda is below. Agenda Suggestions - Roll call - Follow up on tracked action items: https://meetings.opendev.org/meetings/tc/2023/tc.2023-10-17-18.00.html - JayF: Before next video meeting, write up a short document on pros/cons of moving TC video meetings to jitsi-meet. - Gate health check - Leaderless projects (gmann) - PTG follow-ups? - https://etherpad.opendev.org/p/tc-ptg-october-2023 - https://etherpad.opendev.org/p/tc-leaders-interaction-2024-1 - https://etherpad.opendev.org/p/oct2023-ptg-os-dbperf-crossproject - Open Discussion and Reviews Thank you, Jay Faulkner OpenStack TC Chair

1 0

[barbican] Weekly Meeting 31-10-2023 Canceled
by Grzegorz Grasza 30 Oct '23

30 Oct '23

Hi all, I'm canceling the meeting this Tuesday. I'm on a business trip this week. Thanks! / Greg

1 0

Re: Regarding Nova's inability to delete the Cinder volume for creating virtual machines (version Y)
by 无数的星球 30 Oct '23

30 Oct '23

Thank you for Gorka's reply! I have seen this document multiple times and it has not been taken seriously. Next, I will try.

1 0

Regarding Nova's inability to delete the Cinder volume for creating virtual machines (version Y)
by 无数的星球 30 Oct '23

30 Oct '23

When creating a virtual machine in the dashboard, create a volume and choose to delete the virtual machine while also deleting the volume. When deleting the virtual machine, there is no normal uninstallation of the volume and the volume is not deleted. The relevant error logs are shown in the image, but the openstack CLI can delete its volume. The specific commands are as follows. CLI： source /etc/keystone/admin-openrc.sh (Verify password file) openstack volume set --detached　191e555c-3947-4928-be46-9f09e2190877（volumeID） openstack volume delete 191e555c-3947-4928-be46-9f09e2190877（volumeID） It seems that Nova is unable to interact with the Cinder API to delete(or detached) commands, but I am not very professional. I don't know if it's a bug? Note that I have seen similar bug patch files, but they are invalid. URL:   BUG page   https://bugs.launchpad.net/nova/+bug/2016173   Page for patching files   https://review.opendev.org/c/openstack/nova/+/880399 Is not working!!!

2 1

[openstack-ansible][ptg] OpenStack-Ansible 2024.1 (Caracal) vPTG Summary
by Dmitriy Rabotyagov 30 Oct '23

30 Oct '23

Hey everyone, We had quite a productive discussion on the PTG and I will provide a summary of them below. It was divided into multiple sections, like things we need to finish for 2023.2 (Bobcat) - since OpenStack-Ansible has trailing release model we have some time to wrap things up; plans for 2024.1 (Caracal) and some things that moved out of scope until better times. You can also find original PTG with discussions here [1] Finalizing 2023.1 (Bobcat): * Documentation on using pretty endpoint names (ie identity.cloud.org instead of cloud.org:5000). For 2024.1 we will try to simplify the way of using such naming to make it more convenient for end-users. * Finalize support of RabbitMQ Quorum queues for all services [2]. With that they will be disabled by default at least for 2023.2 release and we will revise the defaults for 2024.1 * Implement openstack_resources common rolem that will handle different resources creation, like OpenStack users, projects, networks, images, aggregates, etc. It will be also used in roles like Tempest, Octavia, Trove and Magnum to create such resources, instead of each role implementing its own flow of doing that. We agreed to add a separate playbook that will allow deployers to leverage the role and run it after setup-openstack. * Debian 12 support. Most patches have landed, but we also need to reflect it's support in documentation * Review and release Skyline role. Tough discussion was about defaults and how Skyline should co-exist with Horizon. As a result we decided to deploy both options, when both are defined in the inventory (as usual), but the playbook that is run last will basically configure HAProxy backends to itself, fully neglecting other available services. So if you want to have both Skyline and Horizon running and functional - you will need to apply some overrides for that. There are also no guarantees that we will be able to merge and release the role in time, so we may end up with making it as part of OSA only for 2024.1. Scoped improvements for 2024.1 (Caracal): * Adoption of PKI role to be used with PIPE modules, that will allow the role to be pointed to any file (like encrypted with ansible-vault) or external storage that supports lookup, instead of plain text files on a deploy host. With that we will also take a look at using Hishcorp Vault as a PKI source and adding it as another driver in addition to the "standalone" one. * Natively supporting multi-AZ deployments for Neutron. At the moment for OVS/LXB you need to define some overrides to make that working, while for OVN you would need to manually execute a bunch of commands. POC patch has been already proposed [3], but it still needs some love. * Finalize support of OVN driver for Octavia. Initial patch has been proposed, but it also needs some love, despite it works in general [4] * Resume work on ProxySQL implementation as a replacement for HAProxy balancing for MariaDB deployment. That should improve load distribution between MariaDB backends. * Allow to select OS for LXC containers. At the moment we're forcing to use the host OS, while in some cases it might be preferred to use a different one, like during OS upgrades or switching the OpenStack deployment from one distro to another. * With that we are excited about incus (LXD fork) having the first release and it being packaged with traditional packages (only .deb at the moment). This opens the door for implementation of incus as a manager for LXC containers, that may simplify our flows and day2 operations significantly. * Invest some time into decreasing the runtime, both for CI/CD and for end-user deployments. * In case improvements for Quorum Queues will land to the oslo.messaging [5] - add a set of variables to roles for nicely controlling the behaviour. [1] https://etherpad.opendev.org/p/osa-caracal-ptg [2] https://review.opendev.org/q/topic:osa%252Fquorum_queues [3] https://review.opendev.org/c/openstack/openstack-ansible-os_neutron/+/858271 [4] https://review.opendev.org/c/openstack/openstack-ansible-os_octavia/+/868462 [5] https://review.opendev.org/q/topic:bug-2031497

1 0

[Glance] Caracal PTG Summary
by Pranali Deore 30 Oct '23

30 Oct '23

Hello Everyone, We had our eighth virtual PTG between 23rd OCt to 26th OCT 2023. Thanks to everyone who joined the virtual PTG sessions. Using Opendev Meetpad we had all the discussion around different topics for glance. I have created etherpad[1] with notes from the session and also included the recordings of each session. Here is the short summary of the discussions. *Tuesday , OCT 24th 2023* # Bobcat Retrospective On a positive note we have completed few important things like adding support for weighting mechanism to store, support for RBD driver to move images to the trash if they cannot be deleted immediately due to having snapshots, putting efforts in bridging the gap between glanceclient and openstackclient and started new location API work which will replace the image-update mechanism for consumers like cinder and nova for OSSN-0090 and OSSN-0065. On the other side we decided to speedup the work we've had in flight and we decided to have recent patches reviews meeting once in a month and backlogs review parties before each milestone to speedup the reviews. Recording: https://drive.google.com/drive/u/0/folders/1oYrgVLV5L89keDZLx7r1JWcG8pk65918 - Bobcat Retrospective # Common Tempest Failures for Glance Glance has faced so many random CI failure and timeouts since bobcat mid cycle, though progress has been made on general issues and few of the project-specific issue also been addressed like post failures causing by image conversion failure, tried reducing concurrency but still we see some random timeouts, one of the common tempest failure has been observed that some glance related jobs like glance-multistore-cinder-import, nova-ceph-multistore are failing with race condition while saving image data, there is a short term solution proposed by sending image_id while creating the image to ensure that each test can utilize own image and race condition could be avoided. https://docs.google.com/document/d/1S41X3FSjqGF87ehTvqLEC9QsDIkULjS1NiqCagZ… Decided to reproduce 1st failure from the gdoc and debug more on failures Recording: https://drive.google.com/drive/u/0/folders/1oYrgVLV5L89keDZLx7r1JWcG8pk65918 - Common tempest failures # Add missing CLI support for some Glance API in Openstack Client The migration work for adding missing CLI was initiated in the antelope cycle. We have added the SDK support for cache API , images API and metadef API(in progress). On the client side support for cache API and images API has been added and for metadef is in progress. This cycle we have decided to cover the remaining client and sdk support for APIs by distributing the work among the team. Recordings: https://drive.google.com/drive/u/0/folders/1oYrgVLV5L89keDZLx7r1JWcG8pk65918 - Adding missing OSC support # Default Glance to configure multiple stores Glance has deprecated single stores configuration since Stein cycle and will remove the support of same in upcoming cycle by dividing the wrok in small parts like remove/migrate single store unit/functional tests. Goal for this cycle: list down the work we have to do with regards to tests. and migrate unit/functional test from "single-store only" to "multistore-only" and send email to the mailing list to urge users to migrate to multi-store. Recording: https://drive.google.com/drive/u/0/folders/1oYrgVLV5L89keDZLx7r1JWcG8pk65918 - Default glane to multistore support.webm *Wednesday, OCT 25th 2023* # Remove Location Strategy In Bobcat we added support for the weighing mechanism to store. So we can safely remove the location strategy and by default use the latest weighing mechanism which will be very easy and efficient. Decided to deprecate location strategy in C and remove it in D, notify operators and users on ML and have a spec for the same in Caracal Cycle. Recording: https://drive.google.com/drive/u/0/folders/1oYrgVLV5L89keDZLx7r1JWcG8pk65918 - Remove Location Strategy # Improve process of restoring image to active state which is set as 'pending_delete' At the moment glance supports delaying of image-data from the store by setting delayed_delete to True and when image gets deleted it actually keeps image data in the backend and then Scrubber daemon deletes it permanently later. To restore the image, the deployer needs to set the UUID of that image in glance-api.conf to the 'restore' option under the Default section. If there are multiple images that need to be restored then this process will be kind of time consuming as each time a new Id will be needed to set in the configuration file and rerun the scrubber if it is not running as Daemon. Decided to introduce admin only API to restore the image and restrict Scrubber daemon to delete the images which are in pending_delete state. The restore part from the scrubber for a couple of cycles until the new API is stable.The restore option from the scrubber will be deprecated in this cycle and then will be removed in the following cycle. Recording: https://drive.google.com/drive/u/0/folders/1oYrgVLV5L89keDZLx7r1JWcG8pk65918 - Restore Image # Deprecate cachemanage middleware Cache operations (CR(u)D) is now part of glance API. Even though we need to depend on cache/cachemanage middleware to enable it. There are two middlewares related to caching, one is `cache` and other is `cachemanage` and we can now get rid of `cachemanage` middleware and glance-cache-manage command line utility. Agreed on deprecating cachmanage middleware in C & remove in D cycle. Decided to have a spec lite for the same after verifying how the cache APIs will respond if cache middleware is not enabled. Recording: https://drive.google.com/drive/u/0/folders/1oYrgVLV5L89keDZLx7r1JWcG8pk65918 - Deprecate Cachemanage Middleware # Use mysql database for caching instead of sqlite There are two different database(s) used for glance, MySql for regular operations and sqlite for caching related operations. We have decided to use single database i.e. MySql for all glance related operations so that it will reduce the efforts to maintain both databases. The Spec is up for review now: https://review.opendev.org/c/openstack/glance-specs/+/899367/4 Recording: https://drive.google.com/drive/u/0/folders/1oYrgVLV5L89keDZLx7r1JWcG8pk65918 - Centralize DB for Caching *Thursday, OCT 26th 2023* # Unified limits Topic was discussed and decided to postpone it to the next cycle since no one volunteered to work on it. # New Location APIs We have decided to have support of new location api which will replace the image-update mechanism for consumers like cinder and nova for OSSN-0090 and OSSN-0065. The implementation patches are up for review along with the unit/functional tests, documentation, api version bump, client side support and tempest coverage[2] The Poc patches of nova and cinder are also there to test this new location api functionality. In this cycle we are going to work on some missing test scenarios & verify PoC patches of consumers like nova and cinder are working with new location api functionality. Recording: https://drive.google.com/drive/u/0/folders/1oYrgVLV5L89keDZLx7r1JWcG8pk65918 - New Location API Apart from above topics you can find other miscellaneous topics discussed in PTG etherpad [1] along with the recordings of the sessions and milestone wise priorities at the end. If you have any questions/suggestions then please join us in our weekly meeting(each Thursday on #openstack-meeting irc channel at 1400 UTC) [1]: https://etherpad.opendev.org/p/oct2023-ptg-glance#L10 [2]: https://review.opendev.org/q/topic:New-Location-Apis Thanks & Regards, Pranali Deore

1 0

[qa][ptg] QA Caracal vPTG Summary
by Martin Kopec 30 Oct '23

30 Oct '23

Hi everyone, here is a summary of the discussions. The full agenda can be found here [1]. == Bobcat Retrospective == Considering the still shrinking number of active contributors, we still manage making releases and doing code reviews. However, less contributors make it hard to react to sudden failures or provide as stable jobs as possible - that's e.g. the case of the Centos 9 topic. == Stop supporting Centos 9 Stream? == No, Centos 9 stays. As concluded during the session, Centos 9 is required for FIPS as other distros (their latest versions) are far behind with supporting FIPS. Apart from that, CS9 is required for Manila, Cinder integration with Ceph as Ceph is tested on Centos 9 too. The biggest pain point is that Centos9 Stream is not versioned and thus it's hard to build a reliable gate. One of the goals for the cycle is improving the connection between Centos and OpenStack community - it's beneficial for both sides. One of the ways might be a 3rd party CI or simply a solution that would provide a quick feedback to the Centos group, e.g. by running Devstack with the default configuration, but at the same time wouldn't affect all the jobs on the OpenStack side that run the distro. This way we could at least avoid simple issues found right away (e.g. some deps issues). The QA team is happy to assist. == Triage previous and write new priority items == The list of the priority items planned for this cycle as well as the ones which were carried over from the previous cycles, can be found here [2]. [1] https://etherpad.opendev.org/p/oct2023-ptg-qa [2] https://etherpad.opendev.org/p/qa-caracal-priority Thank you all for attending the PTG and contributing to the discussion, -- Martin Kopec Principal Software Quality Engineer Red Hat EMEA IM: kopecmartin

1 0

[interop][ptg] Interop Caracal vPTG Summary
by Martin Kopec 30 Oct '23

30 Oct '23

Hi everyone, here is a summary of the discussions. The full agenda can be found here [1]. We had only one topic on the agenda - a new view on interoperability testing - don't confuse it with interop which is a certification program. The program just uses the interop tests for the certification purposes. The tests that are part of interop were long ago considered as enough for testing interoperability. However, as it's been pointed out as well as discussed many times already [2][3], the tests don't guarantee interoperability of tested clouds - they test only basic API thus they can be used for the certification program (related to OpenStack brand) at most. Interoperability is subjective, every user may be looking for a different level of interoperability. Read the ending of the article [2]. If there is someone who is interested in interoperability testing in OpenStack or even someone who requires that for various reasons, we could do something like this [4] - we could gather various tests from various testing platforms that test specific functionalities. It would provide anyone with metrics and thus allow them to compare clouds. It would be like when we're shopping, e.g. for a new computer - we have various metrics that help us decide which one suits us better like dimensions, weight, RAM, CPU, storage space etc. From the last PTG (and several one before) it, however, doesn't look like the community is interested in running actual interoperability testing. Let us know if you disagree, we don't want to develop something that is not needed by anyone. [1] https://etherpad.opendev.org/p/oct2023-ptg-interop [2] https://superuser.openinfra.dev/articles/new-view-on-interoperability-in-op… [3] https://etherpad.opendev.org/p/bobcat-ptg-interop [4] https://etherpad.opendev.org/p/openstack-interop-2.0 Thank you all for attending the PTG and contributing to the discussion, -- Martin Kopec Principal Software Quality Engineer Red Hat EMEA IM: kopecmartin

1 0

[neutron] Bugs deputy report October 23rd - 29th
by Miguel Lavalle 29 Oct '23

29 Oct '23

Hi Neutrinos, Here's this week's bugs deputy report: Critical ====== High ==== https://bugs.launchpad.net/neutron/+bug/2040166 [OVN] The neutron_sync_mode conf is ignored for SB DB sync. Assignee: Lucas Gomes. https://bugs.launchpad.net/neutron/+bug/2040172 [OVN] OvnSbSynchronizer - clean/delete segmenthostmappings for unrelated hosts. Assignee: Harald Jensas. Proposed fix: https://review.opendev.org/c/openstack/neutron/+/899077 https://bugs.launchpad.net/neutron/+bug/2041609 FIP update removes QoS policy. Assignee Lajos Katona. Proposed fix: https://review.opendev.org/c/openstack/neutron/+/899469 Medium ====== https://bugs.launchpad.net/neutron/+bug/2040517 host not removed from table ml2_vxlan_endpoints with the agent delete. Needs and owner https://bugs.launchpad.net/neutron/+bug/2041612 [n-d-r] DRAgent removed from bgp speaker automatically. Needs verification and owner Low === RFEs ==== https://bugs.launchpad.net/neutron/+bug/2040001 [N-D-R] Change neighbor connect mode when the BGP peer does not support passive mode. Assignee: Tiago Pires. This RFE was initially discussed during this week's vPTG. Proposed spec: https://review.opendev.org/c/openstack/neutron-specs/+/899210 Undecided ======== Invalid ======== https://bugs.launchpad.net/neutron/+bug/2040242 [ipam] Why prevent first ip < (subnet.first + 1) if version of subnet is ipv6. Assignee Liu Xie. Proposed fix: https://review.opendev.org/c/openstack/neutron/+/899374 https://bugs.launchpad.net/neutron/+bug/2040457 [allocation_pools] Need re-generation new pools from cidr and gateway-ip after update one subnet with empty 'allocation_pools'. Assignee: Liu Xie. Proposed fix: https://review.opendev.org/c/openstack/neutron/+/899373

1 0

Regarding Nova's inability to delete the Cinder volume for creating virtual machines (version Y)
by 无数的星球 27 Oct '23

27 Oct '23

When creating a virtual machine in the dashboard, create a volume and choose to delete the virtual machine while also deleting the volume. When deleting the virtual machine, there is no normal uninstallation of the volume and the volume is not deleted. The relevant error logs are shown in the image, but the openstack CLI can delete its volume. The specific commands are as follows. CLI： source /etc/keystone/admin-openrc.sh (Verify password file) openstack volume set --detached　191e555c-3947-4928-be46-9f09e2190877（volumeID） openstack volume delete 191e555c-3947-4928-be46-9f09e2190877（volumeID） It seems that Nova is unable to interact with the Cinder API to delete(or detached) commands, but I am not very professional. I don't know if it's a bug?

1 0

horizon - dashboard behavior - shows elements from previous project
by Miguel Casique Meneses 27 Oct '23

27 Oct '23

There is a horizon chart behaving quite strangely version: horizon-0.3.2 To recreate the issue: login to openstack >> change project (using dropdown) >> show containers (odd behaviour, such as change to old project, or lists containers from previous project) >> show instances (odd behaviour, changes projects, or at least shows the wrong project in dropdown) Basically, it sometimes shows the elements from the previous browsed project and not the current one that has been selected. If we reload the page, it goes back to project that has been selected, but sometimes it does not The logs are not showing nothing relevant, but we can see when project has been swapped

3 2

[Glance] Caracal PTG Updates
by Pranali Deore 27 Oct '23

27 Oct '23

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

1 0

[keystone] Weekly Meeting 11/1 Canceled
by Dave Wilde 27 Oct '23

27 Oct '23

Hello all, I'm on PTO the week of 11/1 so I'm canceling the Weekly meeting as well as the reviewathon on 11/3. Thanks! /Dave

1 0

[vPTG][Security SIG] Agenda / Planning etherpad
by Tony Breeds 26 Oct '23

26 Oct '23

Hello All, I'ms sorry for getting this out with so little notice. I've pulled together an agenda for the os-security SIG meeting at the vPTG When: https://www.timeanddate.com/worldclock/fixedtime.html?iso=2023-10-27T16:00:… Where: https://meetpad.opendev.org/oct2023-ptg-os-security Planning Etherpad: https://etherpad.opendev.org/p/oct2023-ptg-os-security Agenda: * Previous PTGs carryover ** https://etherpad.opendev.org/p/vancouver-june2023-os-security-sig *** Xstatic --https://review.opendev.org/c/openstack/xstatic-jquery-migrate/+/878923 ** https://etherpad.opendev.org/p/march2023-ptg-os-security *** image encryption pop-up team (Luzi) **** castellan consumers api is in place now, unblocking significant parts of the implementation * Should we meet outside of the PTG events [10 mins] * https://security.openstack.org/ Updates ** Sorting of OSSNs -- Something along the lines of -- https://review.opendev.org/c/openstack/releases/+/887691 ** Remove references to storyboard? * Other business? * VMT Business * Open public security bug triage/processing -- http://tiny.cc/public-ossn Yours Tony.

1 0

[glance][ops] FEEDBACK REQUEST: Deprecating VMWare Datastore store driver
by Takashi Kajinami 26 Oct '23

26 Oct '23

Hello, In glance_store we have maintained the VMWare Datastore store driver which stores image data in ESX/ESXi or vCenter Server. This store driver was added 9 years ago[1] to be used in the VMware environment with OpenStack. However now the vmwarapi virt driver was marked experimental and is being removed from nova[2], so it seems the original use case is no longer valid. I proposed deprecating this store driver during this cycle[3], so that we can remove it during D (or E) cycle, but I'm sending this email to gather early feedback before we merge the deprecation. In case if you are using the driver or have any concern, please reply to me (publicly or privately) or leave your comments in the review. [1] https://review.opendev.org/c/openstack/glance/+/58883 [2] https://review.opendev.org/c/openstack/nova/+/897017 [3] https://review.opendev.org/c/openstack/glance_store/+/893696 Thank you, Takashi

1 0

[neutron][openvswitch][antelope] Bridge eth1 for physical network provider does not exist
by ddorra＠t-online.de 26 Oct '23

26 Oct '23

Hello, I'm installing Openstack Antelope with network option 2 ( following https://docs.openstack.org/neutron/2023.2/install/compute-install-option2-u…) The interface name of the provider network is eth1, so I put this to bridge_mappings. The local IP is from the management network. #------------------------------------------------------ # /etc/neutron/plugins/ml2/openvswitch_agent.ini # [DEFAULT] [agent] [dhcp] [network_log] [ovs] bridge_mappings = provider:eth1 [securitygroup] enable_security_group = true firewall_driver = openvswitch [vxlan] local_ip = 192.168.2.71 l2_population = true #-------------------------------------------------------- However, the neutron log complains that bridger eth1 does not exist. Launching of instances fails neutron-openvswitch-agent.log: 2023-10-23 19:26:00.062 17604 INFO os_ken.base.app_manager [-] instantiating app os_ken.app.ofctl.service of OfctlService 2023-10-23 19:26:00.062 17604 INFO neutron.agent.agent_extensions_manager [-] Loaded agent extensions: [] 2023-10-23 19:26:00.108 17604 INFO neutron.plugins.ml2.drivers.openvswitch.agent.openflow.native.ovs_bridge [-] Bridge br-int has datapath-ID 00005e65b1943a49 2023-10-23 19:26:02.438 17604 INFO neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent [-] Mapping physical network provider to bridge eth1 vvvvvvv 2023-10-23 19:26:02.438 17604 ERROR neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent [-] Bridge eth1 for physical network provider does not exist. Agent terminated! ^^^^^^^ 2023-10-23 19:26:03.914 17619 INFO neutron.common.config [-] Logging enabled! 2023-10-23 19:26:03.914 17619 INFO neutron.common.config [-] /usr/bin/neutron-openvswitch-agent version 20.4.0 2023-10-23 19:26:03.914 17619 INFO os_ken.base.app_manager [-] loading app neutron.plugins.ml2.drivers.openvswitch.agent.openflow.native.ovs_oskenapp ----------------------------------------- Additional information root@control:/var/log/neutron# openstack network list +--------------------------------------+----------+--------------------------------------+ | ID | Name | Subnets | +--------------------------------------+----------+--------------------------------------+ | 32f53edc-a394-419f-a438-a664183ee618 | doznet | e38e25c2-4683-48fb-a7a0-7cbd7d276ee1 | | 74e3ee6a-1116-4ff6-9e99-530c3cbaef28 | provider | 2d3c3de4-9a0d-4a21-9af1-8ecb9f6f16d5 | +--------------------------------------+----------+--------------------------------------+ root@control:/var/log/neutron# root@compute1:/etc/neutron/plugins/ml2# ip a 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether 08:00:27:9f:c7:89 brd ff:ff:ff:ff:ff:ff inet 192.168.2.71/24 brd 192.168.2.255 scope global eth0 valid_lft forever preferred_lft forever inet6 fe80::a00:27ff:fe9f:c789/64 scope link valid_lft forever preferred_lft forever 3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether 08:00:27:91:60:58 brd ff:ff:ff:ff:ff:ff inet 10.0.0.71/24 brd 10.0.0.255 scope global eth1 valid_lft forever preferred_lft forever inet6 fe80::a00:27ff:fe91:6058/64 scope link valid_lft forever preferred_lft forever 4: ovs-system: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether da:3b:3a:a0:59:97 brd ff:ff:ff:ff:ff:ff 5: br-int: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 5e:65:b1:94:3a:49 brd ff:ff:ff:ff:ff:ff 6: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000 link/ether 52:54:00:53:87:59 brd ff:ff:ff:ff:ff:ff inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0 valid_lft forever preferred_lft forever What are the proper settings? Any help appreciated Dieter

4 5

[oslo] oslo-rootwrap daemon test failures
by Chuck Tuffli 26 Oct '23

26 Oct '23

There are a handful of failures when running the oslo-rootwrap test suite on FreeBSD. Most I have been able to fix, but I'm looking for some help understanding what is going wrong with the daemon tests. One example of a failing test is test_daemon_cleanup_client. The test reports: AssertionError: -9 == -9 : Server haven't stopped in one second which I _think_ occurs because of an exception while closing the connection (see below). Any suggestions as to what I might check (and where) to understand why this is happening? Thanks! Running the latest from git on FreeBSD 13.2 with Python 3.9 {2} oslo_rootwrap.tests.test_functional.RootwrapDaemonTest.test_daemon_cleanup_client [1.455829s] ... FAILED Captured traceback: ~~~~~~~~~~~~~~~~~~~ Traceback (most recent call last): File "/usr/home/tuffli/dev/openstack/oslo.rootwrap.git/oslo_rootwrap/tests/test_functional.py", line 299, in test_daemon_cleanup_client self.client._finalize() File "/usr/local/lib/python3.9/contextlib.py", line 126, in __exit__ next(self.gen) File "/usr/home/tuffli/dev/openstack/oslo.rootwrap.git/oslo_rootwrap/tests/test_functional.py", line 289, in _test_daemon_cleanup self.assertNotEqual(-signal.SIGKILL, process.returncode, File "/usr/local/lib/python3.9/unittest/case.py", line 846, in assertNotEqual raise self.failureException(msg) AssertionError: -9 == -9 : Server haven't stopped in one second Captured daemon_log: ~~~~~~~~~~~~~~~~~~~~ 2023-10-19 18:33:10,718 | [ 1664]+DEBUG | Created temporary directory /tmp/rootwrap-snf7oiau 2023-10-19 18:33:10,718 | [ 1664]+DEBUG | Will listen on socket /tmp/rootwrap-snf7oiau/rootwrap.sock 2023-10-19 18:33:10,719 | [ 1664]+ INFO | Starting rootwrap daemon main loop 2023-10-19 18:33:11,719 | [ 1664]+ INFO | Got signal 2. Shutting down server 2023-10-19 18:33:11,719 | [ 1664]+DEBUG | Removing temporary directory /tmp/rootwrap-snf7oiau Traceback (most recent call last): File "/usr/home/tuffli/dev/openstack/oslo.rootwrap.git/.tox/py3/lib/python3.9/site-packages/oslo_rootwrap/daemon.py", line 166, in daemon_start server.serve_forever() File "/usr/local/lib/python3.9/multiprocessing/managers.py", line 184, in serve_forever sys.exit(0) SystemExit: 0 During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/usr/home/tuffli/dev/openstack/oslo.rootwrap.git/oslo_rootwrap/tests/run_daemon.py", line 58, in <module> cmd.daemon() File "/usr/home/tuffli/dev/openstack/oslo.rootwrap.git/.tox/py3/lib/python3.9/site-packages/oslo_rootwrap/cmd.py", line 62, in daemon return main(run_daemon=True) File "/usr/home/tuffli/dev/openstack/oslo.rootwrap.git/.tox/py3/lib/python3.9/site-packages/oslo_rootwrap/cmd.py", line 133, in main daemon_mod.daemon_start(config, filters) File "/usr/home/tuffli/dev/openstack/oslo.rootwrap.git/.tox/py3/lib/python3.9/site-packages/oslo_rootwrap/daemon.py", line 171, in daemon_start conn.close() File "/usr/home/tuffli/dev/openstack/oslo.rootwrap.git/.tox/py3/lib/python3.9/site-packages/oslo_rootwrap/jsonrpc.py", line 92, in close self._socket.shutdown(socket.SHUT_RDWR) OSError: [Errno 57] Socket is not connected Captured client_log: ~~~~~~~~~~~~~~~~~~~~ 2023-10-19 18:33:10,290 | [ 1610] DEBUG | Popen for ['/usr/home/tuffli/dev/openstack/oslo.rootwrap.git/.tox/py3/bin/python', '/usr/home/tuffli/dev/openstack/oslo.rootwrap.git/oslo_rootwrap/tests/run_daemon.py', '/tmp/tmpjri8_7we/rootwrap.conf'] command has been instantiated 2023-10-19 18:33:10,719 | [ 1610] INFO | Spawned new rootwrap daemon process with pid=1664 2023-10-19 18:33:10,728 | [ 1610] INFO | Stopping rootwrap daemon process with pid=1664 2023-10-19 18:33:11,733 | [ 1610] INFO | Rootwrap daemon process exit with status: -9

3 4

[CloudKitty] Cancelling weekly meeting 30 of October
by Rafael Weingärtner 25 Oct '23

25 Oct '23

Hello guys, As we discussed in the vPTG, we will be cancelling the next CloudKitty bi-weekly meeting that would take place on October the 30. If you need any assistance until the next meeting, you can reach me via e-mail. Best regards, -- Rafael Weingärtner

1 0

[manila] Oct 26th upstream meeting is cancelled
by Carlos Silva 25 Oct '23

25 Oct '23

Hello everyone! Cancelling this week's upstream meeting as we will be focused on the OpenStack Manila PTG [1]. Next meeting will take place on Nov 2nd. [1] https://etherpad.opendev.org/p/caracal-ptg-manila Thanks, carloss

1 0

[cinder] Cancelling this week's meeting (25 Oct)
by Rajat Dhasmana 25 Oct '23

25 Oct '23

Hello Argonauts, We have the 2024.1 Caracal PTG this week so cancelling the upstream meeting. See you at the PTG! Dates: 24 October (Tuesday) - 27 October (Friday), 2023 Time: 1300 - 1700 UTC Room: Cactus Meeting Link: https://www.openstack.org/ptg/rooms/cactus Thanks Rajat Dhasmana

1 0

[neutron][octavia] New deployment / suggestions for network
by Eric K. Miller 24 Oct '23

24 Oct '23

Hi, We have been deploying OpenStack for quite some time, using Kolla-Ansible, and typically choose DVR and OVS with Amphorae deployed by Octavia for load balancing. With the issues that DVR has with Octavia's Amphorae and Virtual IPs, with essentially non-functional automated fail-over, we have always wanted to move to OVN since it appears to be the popular approach now. I have also read that OVN appears to work properly with allowed-address-pairs correctly, whereas with DVR, OVS does not, and thus some of the issues with Amphorae Virtual IPs. However, OVN, from what I understand, has issues with, or doesn't support, VPNaaS, which we use extensively. Plus, it only supports Layer 4 load balancing, whereas with Amphorae, we get Layer 7 load balancing - also used extensively. I'm not sure, though - maybe OVN with Octavia still supports Amphorae if we need Layer 7 load balancing? Am I wrong regarding any of the comments above? What is the best back-end networking architecture that provides scalability (so, not VLANs), Layer 7 load balancing with Octavia, along with VPNaaS, in a brand new install with the latest version of OpenStack? Note that we used Midonet long long ago, and it seemed to have everything we wanted, but shortly after purchasing it, Midokura immediately decided to abandon support for OpenStack and went the Kubernetes route. Not sure if they still do this, but needless to say, Midonet isn't a valid solution unfortunately. Tungsten Fabric appears like an alternate solution to Midonet, but that project is sunsetting in 2024, so that's dead too. :( Thank you for any suggestions! Eric

4 6

[kolla] Cancelling weekly meeting tomorrow (25th Oct 2023)
by Michał Nasiadka 24 Oct '23

24 Oct '23

Hello, Cancelling tomorrows weekly meeting since we’re already meeting at vPTG sessions. Thanks, Michal

1 0

RDO Bobcat 2023.2 Released
by Amy Marrich 24 Oct '23

24 Oct '23

RDO Bobcat Released The RDO community is pleased to announce the general availability of the RDO build for OpenStack 2023.2 Bobcat for RPM-based distributions, CentOS Stream and Red Hat Enterprise Linux. RDO is suitable for building private, public, and hybrid clouds. Bobcat is the 28th release from the OpenStack project, which is the work of more than 1,000 contributors from around the world. The release is already available for CentOS Stream 9 on the CentOS mirror network in: http://mirror.stream.centos.org/SIGs/9-stream/cloud/x86_64/openstack-bobcat/ The RDO community project curates, packages, builds, tests and maintains a complete OpenStack component set for RHEL and CentOS Stream and is a member of the CentOS Cloud Infrastructure SIG. The Cloud Infrastructure SIG focuses on delivering a great user experience for CentOS users looking to build and maintain their own on-premise, public or hybrid clouds. All work on RDO and on the downstream release, Red Hat OpenStack Platform, is 100% open source, with all code changes going upstream first. The highlights of the broader upstream OpenStack project may be read via https://releases.openstack.org/bobcat/highlights.html but here are some highlights: - New Cinder driver features were added, notably, QoS support for Fujitsu ETERNUS DX driver, replication-enabled consistency groups support for Pure Storage driver, and Active/Active support for NetApp NFS driver. - Glance added support for RBD driver to move images to the trash if they cannot be deleted immediately due to having snapshots. - The Neutron service has enabled the new API policies (RBAC) with system scope and default roles by default. - The Nova legacy quota driver is now deprecated and a nova-manage limits command is provided in order to migrate the orginal limits into Keystone. We plan to change the default quota driver to the unified limits driver in an upcoming release. It is recommended that you begin planning and executing a migration to unified limits as soon as possible. OpenStack Bobcat is not marked as Skip Level Upgrade Release Process or SLURP. According to this model ( https://governance.openstack.org/tc/resolutions/20220210-release-cadence-ad…) this means that upgrades will only be supported from the Antelope 2023.1 release. RDO Bobcat 2023.2 has been built and tested with the recently released Ceph 18.2.0 Reef version (https://docs.ceph.com/en/latest/releases/reef/) which has been published by the CentOS Storage SIG in the official CentOS repositories. *Note:* Follow the instructions in [RDO documentation]( https://www.rdoproject.org/install/install-with-ceph/) to install OpenStack and Ceph services in the same host. During the Bobcat 2023.2 development cycle, the RDO community has implemented automatic dependency detection at run and build time. We expect that these changes will lead to more accurate dependency chains in OpenStack packages and less manual maintenance tasks for community maintainers. Following upstream retirement, some packages are not present in RDO Bobcat 2023.2 release: - python-networking-odl - python-networking-omnipath - python-networking-vmware-nsx - python-oswin-tests-tempest - python-os-xenapi - python-patrole - python-stackviz - python-vmware-nsxlib - python-vmware-nsx-tests-tempest Contributors - During the Bobcat cycle, we saw the following new RDO contributors: - Arkady Shtempler - Dariusz Smigiel - Dave Wilde - Fabricio Aguiar - Jakub Skunda - Joan Francesc Gilabert - Maor Blaustein - Mohammad Abunemeh - Szymon Datko - Yadnesh Kulkarni Welcome to all of you and Thank You So Much for participating! But we wouldn’t want to overlook anyone. A super massive Thank You to all 47 contributors who participated in producing this release. This list includes commits to rdo-packages, rdo-infra, and rdo-website repositories: - Alfredo Moralejo Alonso - Amy Marrich - Ananya Banerjee - Arkady Shtempler - Artom Lifshitz - Arx Cruz - Bhagyashri Shewale - Bohdan Dobrelia - Chandan Kumar - Daniel Pawlik - Dariusz Smigiel - Dave Wilde - Douglas Viroel - Enrique Vallespi Gil - Fabricio Aguiar - Giulio Fidente - Goutham Pacha Ravi - Gregory Thiemonge - Grzegorz Grasza - Ihar Hrachyshka - Jakub Skunda - Jiří Podivín - Jiří Stránský - Joan Francesc Gilabert - Joel Capitao - Karolina Kula - Karthik Sundaravel - Luca Miccini - Lucas Alvares Gomes - Luigi Toscano - Luis Tomas Bolivar - Maor Blaustein - Marios Andreou - Mathieu Bultel - Matthias Runge - Mohammad Abunemeh - Rodolfo Alonso Hernandez - Ronelle Landy - Sandeep Yadav - Slawomir Kaplonski - Soniya29 vyas - Szymon Datko - Takashi Kajinami - Tobias Urdin - Tom Weininger - Yadnesh Kulkarni - Yatin Karel The Next Release Cycle At the end of one release, focus shifts immediately to the next release i.e Caracal. Get Started To spin up a proof of concept cloud, quickly, and on limited hardware, try an All-In-One Packstack installation. You can run RDO on a single node to get a feel for how it works. Finally, for those that don’t have any hardware or physical resources, there’s the OpenStack Global Passport Program. This is a collaborative effort between OpenStack public cloud providers to let you experience the freedom, performance and interoperability of open source infrastructure. You can quickly and easily gain access to OpenStack infrastructure via trial programs from participating OpenStack public cloud providers around the world. Get Help The RDO Project has our users(a)lists.rdoproject.org for RDO-specific users and operators. For more developer-oriented content we recommend joining the dev(a)lists.rdoproject.org mailing list. Remember to post a brief introduction about yourself and your RDO story. The mailing lists archives are all available at https://mail.rdoproject.org. You can also find extensive documentation on RDOproject.org. The #rdo channel on OFTC IRC is also an excellent place to find and give help. We also welcome comments and requests on the CentOS devel mailing list and the CentOS IRC channels (#centos, #centos-cloud, #centos-devel in Libera.Chat network), however we have a more focused audience within the RDO venues. Get Involved To get involved in the OpenStack RPM packaging effort, check out the RDO contribute pages, peruse the CentOS Cloud SIG page, and inhale the RDO packaging documentation. Join us in #rdo and on the OFTC IRC network and follow us on Twitter @RDOCommunity. You can also find us on Facebook and YouTube.

1 0

Re: [kolla-ansible][yoga] Cannot authenticate to openstack after deploying self-signed cert
by wodel youchi 24 Oct '23

24 Oct '23

Hi, From the beginning I had kolla_verify_tls_backend: "no" in globals.yml The weird thing is that the openstack cli works fine. I even created a new user with admin role, I get the same behavior. Horizon does not connect, the cli works. I activated the debug mode on keystone [root@rscdeployer ~]# cat /etc/yogakolla/config/keystone.conf [DEFAULT] debug = True insecure_debug= True But nothing in the log file, when I try to login via horizon, I don't get anything on keystone.log. I tested with a wrong password to see the behavior of the platform, and this is what I got on keystone.log : - Openstack CLI with wrong pass, I got : 2023-10-22 13:51:02.344 43 WARNING keystone.server.flask.application [req-73100d88-8357-42ce-8865-e36c34a9bfa9 - - - - -] Authorization failed. The request you have made requires authentication. from 10.10.3.16: keystone.exception.Unauthorized: The request you have made requires authentication. - Openstack Horizon with wrong pass, I got : Nothing How can I follow up this, how can I be sure that it's not a horizon problem or something else? Regards. <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> Virus-free.www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> Le mer. 18 oct. 2023 à 13:17, Kaster, Jörn <Joern.Kaster(a)epg.com> a écrit : > Hi wodel, > nice to hear that the patch helps you. > > With the keystone problem i can't help, but i think the certs are correct. > Two thoughts about that. > > - If you have in the respective configurations of the OpenStack > Services the IP address instead of any DNS Name configured (here is this > the case) then the certificates don't need the dns name in it. > - Could you please look for any error Messages in the keystone logs > and also check if you can establish a connection to the keystone on the > mentioned port with openssl s_client. If so, it could be possible that you > have to disable the certificate verification in the deployment. > > > ------------------------------ > *Von:* wodel youchi <wodel.youchi(a)gmail.com> > *Gesendet:* Mittwoch, 18. Oktober 2023 11:55 > *An:* Kaster, Jörn <Joern.Kaster(a)epg.com> > *Cc:* OpenStack Discuss <openstack-discuss(a)lists.openstack.org> > *Betreff:* Re: [kolla-ansible][yoga] Cannot authenticate to openstack > after deploying self-signed cert > > > OUTSIDE-EPG! > > Thanks Jörn, it worked for cloudkitty, after applying the patch the > deployment went well. But : > > - I still can't access the web console : An error occurred authenticating. > Please try again later. > > - in cloudkitty-processor.log I am still having : > 2023-10-18 10:46:25.271 8106 WARNING keystoneauth.identity.generic.base > [-] Failed to discover available identity versions when contacting > https://dinternal.cloud.domain.tld:35357. Attempting to parse version > from URL.: keystoneauth1.exceptions.connection.SSLError: SSL exception > connecting to https:// dinternal.cloud.domain.tld :35357: > HTTPSConnectionPool(host=' dinternal.cloud.domain.tld ', port=35357): Max > retries exceeded with url: / (Caused by SSLError(SSLError(1, '[SSL: > CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:897)'),)) > > > When generating the self-signed certificate, I noticed that the process > had generated : > - two haproxy certificates, one for the internet with the external FQDN > and the second for internal communication with the local internal FQDN. > > - It also generated a backend certificate, that contains only the IP > addresses of the 03 controllers as Subject Alternate Names without any > mention of the domain I am using, is this correct? > > [root@rscdeployer ~]# openssl x509 -noout -text -in > /etc/yogakolla/certificates/backend-cert.pem > Certificate: > Data: > Version: 3 (0x2) > Serial Number: > 1c:66:7e:37:85:cf:ca:1c:da:42:f6:f1:1f:dc:1e:97..... > Signature Algorithm: sha256WithRSAEncryption > Issuer: CN = KollaTestCA > Validity > Not Before: Oct 17 15:04:26 2023 GMT > Not After : Oct 15 15:04:26 2025 GMT > Subject: C = US, ST = NC, L = RTP, OU = kolla > Subject Public Key Info: > Public Key Algorithm: rsaEncryption > RSA Public-Key: (2048 bit) > Modulus: > ..... > ..... > e6:23:a4:7f:30:74:ac:0c:2d:22:00:95:b6:ab:20: > 98:6b > Exponent: 65537 (0x10001) > X509v3 extensions: > > *X509v3 Subject Alternative Name: IP Address:10.10.3.5, IP > Address:10.10.3.9, IP Address:10.10.3.13* > Signature Algorithm: sha256WithRSAEncryption > 36:86:cb:b4:9a:fe:33:0d:ff:af:87:5e:00:9d:69:4e:32:21: > > > > Regards. > > > <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> > Virus-free.www.avast.com > <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> > <#m_-6993449584919071302_x_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> > > Le mer. 18 oct. 2023 à 07:12, Kaster, Jörn <Joern.Kaster(a)epg.com> a > écrit : > > Hello wodel, > the problem with cloudkitty deployment with self signed certs could > resolve to the following bugreport [1]. > > [1] https://bugs.launchpad.net/kolla-ansible/+bug/1998831 > Bug #1998831 “CloudKitty bootstrap fails when using internal TLS...” : > Bugs : kolla-ansible > <https://bugs.launchpad.net/kolla-ansible/+bug/1998831> > When InfluxDB is behind HAProxy's internal TLS, CloudKitty fails to > bootstrap its InfluxDB database with the following error: TASK [cloudkitty > : Creating Cloudkitty influxdb database] > *************************************************************************************************************************** > fatal: [controller01 -> controller01]: FAILED! => changed=false action: > influxdb_database msg: ('Connection aborted.', RemoteDisconnected('Remote > end closed connection without response... > bugs.launchpad.net > > > ------------------------------ > *Von:* wodel youchi <wodel.youchi(a)gmail.com> > *Gesendet:* Mittwoch, 18. Oktober 2023 01:33 > *An:* OpenStack Discuss <openstack-discuss(a)lists.openstack.org> > *Betreff:* [kolla-ansible][yoga] Cannot authenticate to openstack after > deploying self-signed cert > > > OUTSIDE-EPG! > > Hi, > > Our ssl certificate expired a couple of days ago, and we started > experiencing failed login, to workaround the problem rapidly we decided to > deploy the self-signed certificates generated by kolla. > > We generated the certificates then we did a reconfigure, but still the > problem remains : An error occurred authenticating. Please try again later. > > on horizon.log we have : > [Wed Oct 18 00:25:55.379383 2023] [wsgi:error] [pid 103:tid > 140182314505984] [remote 10.10.3.5:40848] Login failed for user "admin" > using domain "default", remote address 10.10.3.5 > > The openstack command line works fine. > > How can we debug this? > > The second problem we have is with cloudkitty that refuses to reconfigure > with the generated self-signed certificate, we had to ignore it from the > reconfiguration process by putting the cloudkitty variable to no before > restarting the reconfigure process. > > How can we debug this? > > > > > Regards. > > > <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> > Virus-free.www.avast.com > <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> > <#m_-6993449584919071302_x_m_9147058937014271290_x_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> > >

2 4

[ironic] [baremetal-sig] Feedback on ironic "ilo" or "ilo5" driver features
by Nisha Agarwal 24 Oct '23

24 Oct '23

Hello, We had a discussion with baremetal-sig in PTG yesterday(23rd Oct 2023). Below are some of the ironic ilo driver features discussed and the summary of our understanding: - In-band and OOB RAID configuration and disk erase : · Cleaning steps are invoked via operator-written scripts for RAID, disk erase etc. The OS commands are directly invoked in the scripts for these tasks. · We are not clear if iLO driver inband RAID feature is used or not. · OOB RAID configuration and disk-erase is not used. - Out-of-Band Inspection: · We are not clear if OOB inspection is used or not. · LLDP data based inventory is most desired. Not all BMCs provide this data today. · Inspection is also used for getting the DHCP information especially, hostname. - UEFI HTTPS boot: · UEFI HTTPS boot feature of ilo driver is not used. · vMedia is the preferred way of deploy in the field. · UEFI HTTP deploy is proposed this cycle in redfish driver. · Some customers use PXE boot. - Smart Update Manager (SUM)-based firmware update: · Firmware update feature of ilo drivers is not used, rather redfish driver is used. Above is our understanding from the discussion in the baremetal-sig operator in PTG. Please correct/clarify our understanding. Basically, we are trying to figure out if any of the following ilo driver features are used : In-band and out-of-band RAID configuration In-band and out-of-band diskerase UEFI-HTTPS boot One button secure erase Smart Update Manager (SUM)-based firmware update Updating security parameters as manual cleaning step GPU hardware inspection We like to also know if proliantutils is used separately as a hardware manager or independently for any of the OOB/Inband features. Regards Nisha

1 0

[Octavia] cancelling meeting Oct 25
by Gregory Thiemonge 24 Oct '23

24 Oct '23

Hi Folks, As discussed in the previous meeting, tomorrow's meeting is cancelled. See you at the vPTG! Gregory

1 0

[cinder][PTG] Cinder 2024.1 Caracal PTG
by Rajat Dhasmana 23 Oct '23

23 Oct '23

Hi All, We will be conducting the Cinder 2024.1 (Caracal) PTG next week. I've finalized the schedule for Cinder PTG here[1]. Also I've booked slots from Tuesday to Friday 1300-1700 UTC[2]. Following are the details of the event: Dates: 24 October (Tuesday) - 27 October (Friday), 2023 Time: 1300 - 1700 UTC Room: Cactus Video conference Tool: Zoom (Link can be found on the PTG page[2] by clicking on Cinder slot) Following are some of the interesting sessions to attend: *Operator Hour:* Wednesday, 1400-1500 UTC *Nova-Cinder Cross Project: *Wednesday, 1600-1700 UTC *Manila-Cinder Cross Project: *Thursday, 1600-1700 UTC *Team Photo: *Wednesday, 1345-1400 UTC We have the Friday slot vacant so if you feel like adding a topic, add it to the planning etherpad[3] and we can adjust it on Friday's schedule. See you at the PTG next week! [1] https://etherpad.opendev.org/p/caracal-ptg-cinder [2] https://ptg.opendev.org/ptg.html [3] https://etherpad.opendev.org/p/caracal-ptg-cinder-planning Thanks Rajat Dhasmana

1 1

RE: openstack-discuss Digest, Vol 60, Issue 51 Multinode Cluster setup
by Asma Naz Shariq 23 Oct '23

23 Oct '23

Dear all, I want to deployed Openstack through kolla-ansible release zed. The cluster architecture is as follows: 1- Controller Node same as Network Node. 2- Compute Node same as Storage Node. On Controller Node, I have followed all the steps mentioned at https://docs.openstack.org/project-deploy-guide/kolla-ansible/zed/quickstar… and set the hosts name with ip at /etc/hosts on controller node to resolve the compute node. When I tried to check the connectivity of controller-node with compute node, it encountered an error with: Controller Node IP | FAILED! => { "msg": "Missing sudo password" } localhost | SUCCESS => { "ansible_facts": { "discovered_interpreter_python": "/usr/bin/python3" }, "changed": false, "ping": "pong" } Compute Node IP | FAILED! => { "msg": "Missing sudo password Can anyone guide me how to resolve this error, and setup multi node environment to which steps should I follow to make baseline cluster of one controller node and one compute node. Thanks, -----Original Message----- From: openstack-discuss-request(a)lists.openstack.org <openstack-discuss-request(a)lists.openstack.org> Sent: Tuesday, October 24, 2023 9:42 AM To: openstack-discuss(a)lists.openstack.org Subject: openstack-discuss Digest, Vol 60, Issue 51 Send openstack-discuss mailing list submissions to openstack-discuss(a)lists.openstack.org To subscribe or unsubscribe via email, send a message with subject or body 'help' to openstack-discuss-request(a)lists.openstack.org You can reach the person managing the list at openstack-discuss-owner(a)lists.openstack.org When replying, please edit your Subject line so it is more specific than "Re: Contents of openstack-discuss digest..." Today's Topics: 1. [ptls] [tc] 2023 OpenStack Deployment Data (Allison Price) 2. Re: [neutron][openvswitch][antelope] Bridge eth1 for physical network provider does not exist (Sławek Kapłoński) 3. Environmental Sustainability WG goes to the PTG! (Kendall Nelson) 4. [tacker] Cancelling IRC meetings (Yasufumi Ogawa) 5. Re: openstack Vm shutoff by itself (AJ_ sunny) ---------------------------------------------------------------------- Message: 1 Date: Mon, 23 Oct 2023 15:16:05 -0500 From: Allison Price <allison(a)openinfra.dev> Subject: [ptls] [tc] 2023 OpenStack Deployment Data To: openstack-discuss <openstack-discuss(a)lists.openstack.org> Message-ID: <AB576C9A-95CB-4BCD-9215-0AC1D3E64A25(a)openinfra.dev> Content-Type: text/plain; charset=us-ascii Hi everyone, Apologies for sending this during the PTG as I intended to send this prior, but below is a link to the anonymized data including responses to many project or TC contributed questions. I have removed a significant number of fields to preserve the anonymity of the organizations, but if there is a particular data point that would help your team, please let me know. Cheers, Allison https://docs.google.com/spreadsheets/d/1ehlabuqOnNK4M7xtN1GXvhLoeHn4JBaISih… ------------------------------ Message: 2 Date: Mon, 23 Oct 2023 22:46:23 +0200 From: Sławek Kapłoński <skaplons(a)redhat.com> Subject: Re: [neutron][openvswitch][antelope] Bridge eth1 for physical network provider does not exist To: "openstack-discuss(a)lists.openstack.org" <openstack-discuss(a)lists.openstack.org> Cc: "ddorra(a)t-online.de" <ddorra(a)t-online.de> Message-ID: <5895770.MhkbZ0Pkbq@p1gen4> Content-Type: multipart/signed; boundary="nextPart1790705.VLH7GnMWUR"; micalg="pgp-sha256"; protocol="application/pgp-signature" Hi, You need to create bridge (e.g. br-ex), add your eth1 to that bridge and put name of the bridge in the bridge_mapping. Dnia poniedziałek, 23 października 2023 21:44:43 CEST ddorra(a)t-online.de pisze: > > Hello, > > I'm installing Openstack Antelope with network option 2 ( following > https://docs.openstack.org/neutron/2023.2/install/compute-install-opti > on2-ubuntu.html) The interface name of the provider network is eth1, > so I put this to bridge_mappings. > The local IP is from the management network. > > #------------------------------------------------------ > # /etc/neutron/plugins/ml2/openvswitch_agent.ini > # > [DEFAULT] > [agent] > [dhcp] > [network_log] > [ovs] > bridge_mappings = provider:eth1 > [securitygroup] > enable_security_group = true > firewall_driver = openvswitch > [vxlan] > local_ip = 192.168.2.71 > l2_population = true > #-------------------------------------------------------- > > However, the neutron log complains that bridger eth1 does not exist. > Launching of instances fails > neutron-openvswitch-agent.log: > 2023-10-23 19:26:00.062 17604 INFO os_ken.base.app_manager [-] > instantiating app os_ken.app.ofctl.service of OfctlService > 2023-10-23 19:26:00.062 17604 INFO > neutron.agent.agent_extensions_manager > [-] Loaded agent extensions: [] > 2023-10-23 19:26:00.108 17604 INFO > neutron.plugins.ml2.drivers.openvswitch.agent.openflow.native.ovs_brid > ge [-] Bridge br-int has datapath-ID 00005e65b1943a49 > 2023-10-23 19:26:02.438 17604 INFO > neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent [-] > Mapping physical network provider to bridge eth1 vvvvvvv > 2023-10-23 19:26:02.438 17604 ERROR > neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent [-] > Bridge > eth1 for physical network provider does not exist. Agent terminated! > ^^^^^^^ > 2023-10-23 19:26:03.914 17619 INFO neutron.common.config [-] Logging > enabled! > 2023-10-23 19:26:03.914 17619 INFO neutron.common.config [-] > /usr/bin/neutron-openvswitch-agent version 20.4.0 > 2023-10-23 19:26:03.914 17619 INFO os_ken.base.app_manager [-] loading > app > neutron.plugins.ml2.drivers.openvswitch.agent.openflow.native.ovs_oske > napp > > ----------------------------------------- > Additional information > root@control:/var/log/neutron# openstack network list > +--------------------------------------+----------+--------------------------------------+ > | ID | Name | Subnets | > +--------------------------------------+----------+--------------------------------------+ > | 32f53edc-a394-419f-a438-a664183ee618 | doznet | > e38e25c2-4683-48fb-a7a0-7cbd7d276ee1 | > | 74e3ee6a-1116-4ff6-9e99-530c3cbaef28 | provider | > 2d3c3de4-9a0d-4a21-9af1-8ecb9f6f16d5 | > +--------------------------------------+----------+--------------------------------------+ > root@control:/var/log/neutron# > > root@compute1:/etc/neutron/plugins/ml2# ip a > 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel > state UP group default qlen 1000 link/ether 08:00:27:9f:c7:89 brd > ff:ff:ff:ff:ff:ff inet 192.168.2.71/24 brd 192.168.2.255 scope global > eth0 valid_lft forever preferred_lft forever > inet6 fe80::a00:27ff:fe9f:c789/64 scope link valid_lft forever > preferred_lft forever > 3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel > state UP group default qlen 1000 link/ether 08:00:27:91:60:58 brd > ff:ff:ff:ff:ff:ff inet 10.0.0.71/24 brd 10.0.0.255 scope global eth1 > valid_lft forever preferred_lft forever > inet6 fe80::a00:27ff:fe91:6058/64 scope link valid_lft forever > preferred_lft forever > 4: ovs-system: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN > group default qlen 1000 link/ether da:3b:3a:a0:59:97 brd > ff:ff:ff:ff:ff:ff > 5: br-int: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group > default qlen 1000 link/ether 5e:65:b1:94:3a:49 brd ff:ff:ff:ff:ff:ff > 6: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue > state DOWN group default qlen 1000 link/ether 52:54:00:53:87:59 brd > ff:ff:ff:ff:ff:ff inet 192.168.122.1/24 brd 192.168.122.255 scope > global virbr0 valid_lft forever preferred_lft forever > > > What are the proper settings? > Any help appreciated > Dieter > > > -- Slawek Kaplonski Principal Software Engineer Red Hat-------------- next part -------------- A message part incompatible with plain text digests has been removed ... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: This is a digitally signed message part. ------------------------------ Message: 3 Date: Mon, 23 Oct 2023 16:36:20 -0500 From: Kendall Nelson <kennelson11(a)gmail.com> Subject: Environmental Sustainability WG goes to the PTG! To: OpenStack Discuss <openstack-discuss(a)lists.openstack.org> Message-ID: <CAJ6yrQgbdvFW7NcUGJ5zLyXagx=hMt6R7ib0tk=1Y+sm06MY=w(a)mail.gmail.com> Content-Type: multipart/alternative; boundary="000000000000e3ee26060869044d" Hello Everyone! Last minute, but I wanted to make sure you saw that we are planning to meet at the PTG, tomorrow (Tuesday Oct 24th) from 13:00 UTC. I have the room booked for two hours, but I don't think we will need all of that time. If there are topics you would like to discuss, please add them to the agenda[1]. Hope to see you there! -Kendall Nelson [1] https://etherpad.opendev.org/p/oct2023-ptg-env-sus

1 0

[swift][ptg] Ops Feedback Session - 25th October at 1300 UTC
by Matthew Oliver 23 Oct '23

23 Oct '23

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

1 0

[tacker] Cancelling IRC meetings
by Yasufumi Ogawa 23 Oct '23

23 Oct '23

Hi team, I'd like to skip today's IRC meeting since we are going to have the vPTG. Thanks, Yasufumi

1 0

Environmental Sustainability WG goes to the PTG!
by Kendall Nelson 23 Oct '23

23 Oct '23

Hello Everyone! Last minute, but I wanted to make sure you saw that we are planning to meet at the PTG, tomorrow (Tuesday Oct 24th) from 13:00 UTC. I have the room booked for two hours, but I don't think we will need all of that time. If there are topics you would like to discuss, please add them to the agenda[1]. Hope to see you there! -Kendall Nelson [1] https://etherpad.opendev.org/p/oct2023-ptg-env-sus

1 0

[neutron] Meetings cancelled this week
by Brian Haley 23 Oct '23

23 Oct '23

Hi Neutrinos, I am cancelling the Neutron and Neutron Drivers meetings this week as we have the vPTG meetings. Please add any topics you would like to discuss to the etherpad, https://etherpad.opendev.org/p/oct2023-ptg-neutron Sorry I forgot to send this sooner. -Brian

1 0

[openstack-ansible] vPTG and Operator hours
by Dmitriy Rabotyagov 23 Oct '23

23 Oct '23

Hi folks, I am glad to announce the upcoming vPTG for OpenStack-Ansible team that will happen on Tuesday, October 24 from 14:00 till 17:00 UTC. Our team will also have an operator hours on Monday, October 23 from 17:00 till 18:00 UTC. All virtual events will take place in the Grizzly room [1]. Please, also check the vPTG agenda in the etherpad [2] and feel free to add topics for the discussion. [1] https://www.openstack.org/ptg/rooms/grizzly [2] https://etherpad.opendev.org/p/osa-caracal-ptg

2 1

[neutron] Bug deputy report for week of October 16th
by Brian Haley 23 Oct '23

23 Oct '23

Hi, I was Neutron bug deputy last week. Below is a short summary about the reported bugs. -Brian Critical bugs ------------- * None High bugs --------- * https://bugs.launchpad.net/neutron/+bug/2039417 - [master][stable/2023.2][functional] test_maintenance.TestMaintenance tests fails randomly - Needs owner Medium bugs ----------- * https://bugs.launchpad.net/neutron/+bug/2039550 - [IPAM] During port bulk creation, if a "fixed_ip" request is incorrect, the previous IPAM allocations generated are not deleted - https://review.opendev.org/c/openstack/neutron/+/898549 * https://bugs.launchpad.net/neutron/+bug/2039586 - [CI] Update the cirros image versions - Many patches opened * https://bugs.launchpad.net/neutron/+bug/2039940 - test_resize_volume_backed_server_confirm which fails randomly with Kernel panic - Similar to https://bugs.launchpad.net/tempest/+bug/1888224 - Not sure what neutron can do Low bugs -------- * None Misc bugs --------- * https://bugs.launchpad.net/neutron/+bug/2039553 - dhcp-agent can not interact with neutron-server after neutron-server restarted - Asked for more information * https://bugs.launchpad.net/neutron/+bug/2039812 - [N-D-R] The dynamic routing service is not resilient to infrastructure outage - Duplicate of https://bugs.launchpad.net/neutron/+bug/2006145 Wishlist bugs ------------- * None

1 0

[sunbeam][ptg] Caracal vPTG
by James Page 23 Oct '23

23 Oct '23

Hi Sunbeamers! We were a little late to sign up but we are participating in the vPTG for Caracal this week. I've booked us 3 hours on Wednesday from 1300-1700 UTC [0]; please add topics for discussion to the etherpad [1]. I've ensured we don't overlap with the OpenStack Charms sessions as I suspect we may have quite a bit of crossover between participants. Thanks James -- [0] https://ptg.opendev.org/ptg.html [1] https://etherpad.opendev.org/p/oct2023-ptg-sunbeam

1 0

[nova][ptg][ops] Nova at the vPTG + our etherpad is broken \o/
by Sylvain Bauza 23 Oct '23

23 Oct '23

Hey folks, tl;dr: as a reminder, all nova sessions are marked in https://ptg.opendev.org/ptg.html I was about to remind you of the schedule for all our nova PTG sessions when I just figured that our etherpad got trashed. Until some admin is able to restore it, please find the agenda in some stored revision https://etherpad.opendev.org/p/nova-caracal-ptg/timeslider#13560 Operators, please gently note that we'll have a nova-operator-hour on Tuesday 1500UTC. As a reminder, this timeslot is dedicated to listening to your experiences and pain points so if you really would like to contribute to the Nova community by providing your insights, this is the right time ! This time, we'll be using the OIF Meetpad instance instead of Zoom. The URL is https://meetpad.opendev.org/nova-caracal-ptg The other Nova sessions will be Tuesday to Friday, 1pm to 5pm UTC. Should you want to attend, feel free to ping me (bauzas) on IRC #openstack-nova or drop me an email (to this address) until our etherpad becomes unstuck in order to let me know your availabilities and I'll try to sort our topics so that you could attend. Later, I'll add, like previously done, a courtesy ping list for every topic in the etherpad so you could register by writing your IRC nick. As a reminder, I'll also try hard to provide the status of the topics we're currently discussing and the next ones in https://ptg.opendev.org/ptg.html. Thanks, -Sylvain (who hopes the etherpad issue got fixed soon)

1 1

[kolla] Upgrading across supported OS's
by Aidan Collins 23 Oct '23

23 Oct '23

Hello! I have a question about the kola upgrade process. Thanks in advance. I am attempting to upgrade our kola version (Victoria to wallaby). The docs suggest it should entail getting the new version of the kolla-ansible pkg & deps, updating the config files & then running "kolla-ansible upgrade". However, what do we do if version N & version N+1 of kolla-ansible don't support the same host OS version? Thanks again -aidan

3 2

[kolla] Operator Hour on Caracal vPTG
by Michał Nasiadka 23 Oct '23

23 Oct '23

Hello, A small reminder - we’ll be hosting an operator hour on Kolla vPTG tomorrow, i.e. 24th Oct 14:00 UTC - please see [1]. If you’re using Kolla and/or Kolla-Ansible and/or Kayobe - please come - we’d like to hear your stories. [1]: https://etherpad.opendev.org/p/kolla-caracal-ptg

1 0

[magnum][PTG] Magnum Caracal vPTG
by Jake Yip 22 Oct '23

22 Oct '23

Hi all, Magnum will have a vPTG at Tuesday, 24 October 2023 at 18:00:00 https://www.timeanddate.com/worldclock/meetingdetails.html?year=2023&month=… Apologies for this being outside of vPTG hours; unfortunately we are a small distributed team and only certain timing works for us. (We have discussed with the OpenInfra support team and will attempt to do better next year) Please plant your ideas in the Etherpad. https://etherpad.opendev.org/p/oct2023-ptg-magnum Hope to see you there! Regards, Jake Yip

1 0

[neutron][ptg] Caracal PTG schedule
by Brian Haley 21 Oct '23

21 Oct '23

Hi Neutrinos, I have booked the Grizzly room from 13:00-17:00 UTC on Wednesday and Thursday [0] for our vPTG meetings and organized the etherpad [1] into time slots based on the topics people added. We do not have a cross-project with the Nova team as there were no current topics for discussion. Feel free to propose additional topics if I missed something, or ping me on irc if there is a conflict. Thanks, -Brian [0] https://ptg.opendev.org/ptg.html [1] https://etherpad.opendev.org/p/oct2023-ptg-neutron

1 0

[tacker][ptg] Caracal PTG schedule
by Yasufumi Ogawa 21 Oct '23

21 Oct '23

Hi team, I've booked rooms 6:00-8:00 UTC from Tuesday to Thursday [1], and setup etherpad for our vPTG [2]. Please add your proposals for Caracal or give any feedback on the topics. [1] https://ptg.opendev.org/ptg.html [2] https://etherpad.opendev.org/p/oct2023-ptg-tacker Thanks, Yasufumi

1 0

"Juju-db.service" failed after restart
by sami sameni 21 Oct '23

21 Oct '23

Hello, We are currently facing an issue with our OpenStack deployment via JUJU (version 3.1.6). This problem emerged after a hardware maintenance project in which we increased the disk capacity. The primary symptom is that JUJU commands are no longer functioning as expected. Upon investigating, we’ve identified that the issue seems to be linked to a specific service, “juju.db.service,” which is failing to operate correctly. When we attempt to execute any JUJU command, it continually tries to connect to this service. Here’s an example using the juju status --debug command: 09:49:50 INFO juju.cmd supercommand.go:56 running juju [3.1.6 f6a66aa91eec620f5ac04a19d8c06bef03ae6228 gc go1.20.8] 09:49:50 DEBUG juju.cmd supercommand.go:57 args: []string{"/snap/juju/24626/bin/juju", "status", "--debug"} 09:49:50 INFO juju.juju api.go:86 connecting to API addresses: [10.20.0.167:17070] We strongly suspect that this issue is related to the Juju MongoDB service. However, our attempts to repair the MongoDB data have been unsuccessful, and it appears that the data may be corrupted. Our primary question at this point is whether it’s possible to deploy a new Juju-db service to resolve this problem and regain the full operational status of the JUJU commands. Regards,

1 0

[i18n][PTG] PTG Meeting schedule discussion
by Seongsoo Cho 20 Oct '23

20 Oct '23

Hi i18n Team It is time to set up a schedule for this PTG. Please let me know the all options that are available for you. Poll: https://framadate.org/adR5s5MsFytUWXiG Best Regards Seongsoo -- Seongsoo Cho OpenStack Korea User Group / Community Leader IRC #seongsoocho

2 2

[openstack-helm] Caracal PTG
by Vladimir Kozhukalov 20 Oct '23

20 Oct '23

Hi Openstack-helmers, As you all know the PTG is coming and is going to happen next week. I booked two hours from 14:00 UTC till 16:00 UTC on Tuesday Oct/24 in Newton virtual room. Please take a look at the schedule [1]. At this point it is not clear how many people are interested to join our sessions. If we need more time we can book a room later. Probably not on Tuesday, but Thursday and Friday look not too busy. If you would like to discuss a particular topic please put it here [2]. I'll add some topics a bit later. [1] https://ptg.opendev.org/ptg.html [2] https://etherpad.opendev.org/p/oct2023-ptg-os-helm -- Best regards, Kozhukalov Vladimir

2 2

D&I WG PTG Session - Leadership Shadowing
by Amy Marrich 20 Oct '23

20 Oct '23

The D&I WG will hold a session Monday at 13:00 UTC in the Diablo room. The subject of the session is a Leadership Shadowing program we have been brainstorming[0] to help generate the next generation of Leaders in the OpenInfra Projects. As this program can be used in all projects and at all levels of leadership we are hoping all projects will join us. Thanks, Amy (

1 0

[publiccloud-sig][ptg] Caracal PTG schedule
by Felix Kronlage-Dammers 20 Oct '23

20 Oct '23

Hey ho, Tobias, Artem and I prepared some initial topics for our PTG slots next week[1]. We meet on Tuesday from 13 - 15 UTC and on Wednesday at 7 UTC. First and foremore we want to dive into the standard set of properties and domain admin support and discuss (and decide) next steps (alongside who is going to do them until when). Another set of topics is the non-technical “organizational” aspect of the public cloud SIG. Looking at our wiki page[2]: “The aim of this group is to represent the interests of the OpenStack public cloud provider community, and to further adoption of OpenStack public cloud usage." We want to use the vPTG to discuss how we can further drive this from the SIG and see how the public cloud SIG can serve as a better feedback look between “stakeholders” (eg. the public cloud operators) and the development community. We’re very much looking forward to the PTG sessions! felix [1] https://etherpad.opendev.org/p/oct2023-ptg-publiccloud-sig [2] https://wiki.openstack.org/wiki/PublicCloudSIG

1 0

[neutron] Drivers meeting cancelled
by Brian Haley 20 Oct '23

20 Oct '23

Hello Neutrinos: Due to the lack of agenda, today's drivers meeting is cancelled. I will also cancel it next week due to the PTG. I will be working on the schedule for next week's meetings today and tomorrow, but it's looking like we will only have meetings Wednesday and Thursday from 13:00-16:00 UTC based on discussion topics added to the etherpad. Please add any additional topics you want to discuss today and I will adjust things if necessary. https://etherpad.opendev.org/p/oct2023-ptg-neutron Have a nice weekend! -Brian

1 0

[neutron] CI meeting for next two weeks is cancelled
by Yatin Karel 20 Oct '23

20 Oct '23

Hello Neutron Team !! Next week will be Caracal vPTG and the other week I am not available for some travel plans. So the next Neutron CI Meeting will be on 07th November, 2023. Thanks and Regards Yatin Karel

1 0

[kolla] [train] [cinder] Cinder issues during controller replacement
by Albert Braden 19 Oct '23

19 Oct '23

We’re replacing controllers, and it takes a few hours to build the new controller. We’re following this procedure to remove the old controller: https://docs.openstack.org/kolla-ansible/train/user/adding-and-removing-hos… After that the cluster seems to run fine on 2 controllers, but approximately 1/3 of our volumes can’t be attached to a VM. When we look at those volumes, we see this: | os-vol-host-attr:host | qde4-ctrl1.cloud.ourdomain.com@rbd-1#rbd-1 | Ctrl1 is the controller that is being replaced. Is it possible to change the os-vol-host-attr on a volume? How can we work around this issue while we are replacing controllers? Do we need to disable the API for the duration of the replacement process, or is there a better way?

6 9

[cinder] Cancelling Festival of XS reviews (20 Oct)
by Rajat Dhasmana 19 Oct '23

19 Oct '23

Hello Argonauts, Given that we have 2024.1 (Caracal) PTG next week, let's cancel today's festival of XS reviews today (20 October, 2023). Don't forget to add topics for the PTG[1]. See you next week! [1] https://etherpad.opendev.org/p/caracal-ptg-cinder-planning Thanks Rajat Dhasmana

1 0

[blazar][ptg] Caracal PTG schedule
by Pierre Riteau 19 Oct '23

19 Oct '23

Hello, I have booked a PTG slot on Monday, October 23 from 15:00 to 17:00 UTC for the Blazar project. The meeting will be held in the Bexar room. The initial agenda can be found here: https://etherpad.opendev.org/p/oct2023-ptg-blazar Please add any topics you would like to discuss. Anyone interested in Blazar is welcome to join. Cheers, Pierre Riteau (priteau)

1 0

[manila] Caracal PTG schedule
by Carlos Silva 19 Oct '23

19 Oct '23

Hello, Zorillas! I have worked on some initial slots for the topics of the next week's PTG [1]. Please take a look and please reach out to me in case you have conflicts in the schedule, so I can accommodate changes. Our operator hour will happen Tuesday, running from 16:00 to 17:00 UTC. During the operator hour, we also intend to talk about the features we implemented to get the work for VirtioFS going and collect feedback on it. Please add your thoughts or other themes you would like to talk about to the operator hour etherpad [2]. [1] https://etherpad.opendev.org/p/caracal-ptg-manila [2] https://etherpad.opendev.org/p/caracal-ptg-manila-operator-hour Looking forward to all the fun! Regards, carloss

1 0

[Glance] Cancelling Today's Weekly Meeting
by Pranali Deore 19 Oct '23

19 Oct '23

Hello All, As few of the team members are not around today and we are going to meet next week for Caracal PTG anyway, so let's cancel today's meeting. Next meeting will be directly on Nov 2nd. See you in the PTG !! Thanks, Pranali Deore

1 0

[sdk][cli][api][ansible-modules][ptg] Virtual PTG Planning
by Artem Goncharov 19 Oct '23

19 Oct '23

Hey, I have booked 2 hour slot on Wednesday 25 Oct 13:00-15:00 UTC for the SDK and CLI team (as usual on demand we can prolong the discussion). As I was already announcing some weeks ago we are going to discuss state of codegeneration in projects we maintain and use of OpenAPI to improve it, as well as getting OSC reworked to get a modern UX and performance. Therefore I would really appreciate a wide participation to get useful inputs. The agenda can be found at [1]. [1]: https://etherpad.opendev.org/p/oct2023-ptg-sdk-cli Regards, Artem

1 0

Openstack volume deletion
by vj66666＠gmail.com 19 Oct '23

19 Oct '23

Hi, OpenStack Kolla Ansible has been installed on Ubuntu 20 and integrated with Ceph storage. The volume associated with the instance is not being deleted by Cinder when I terminate the instance with this option (Delete Volume on Instance Delete), which is causing me problems. I need to log in to the server and run the cinder commands to manually delete the volume that is not associated with instances. I would appreciate it if you could provide a solution.

1 0

[release] Release countdown for week R-24, Oct 16 - 20
by Herve Beraud 19 Oct '23

19 Oct '23

Welcome back to the release countdown emails! These will be sent at major points in the 2024.1 Caracal development cycle, which should conclude with a final release on April 3, 2024. Development Focus ----------------- At this stage in the release cycle, focus should be on planning the 2024.1 Caracal development cycle, assessing 2024.1 Caracal community goals and approving 2024.1 Caracal specs. General Information ------------------- 2024.1 Caracal is a 26 weeks development cycle. In case you haven't seen it yet, please take a look over the schedule for this release: https://releases.openstack.org/ <https://releases.openstack.org/caracal/schedule.html>caracal <https://releases.openstack.org/caracal/schedule.html>/schedule.html <https://releases.openstack.org/caracal/schedule.html> By default, the team PTL is responsible for handling the release cycle and approving release requests. This task can (and probably should) be delegated to release liaisons. Now is a good time to review release liaison information for your team and make sure it is up to date: https://opendev.org/openstack/releases/src/branch/master/data/release_liais… By default, all your team deliverables from the 2023.2 Bobcat release are continued in 2024.1 Caracal with a similar release model. Upcoming Deadlines & Dates -------------------------- Virtual Caracal PTG: October 23-27 2024.1 Caracal-1 milestone: November 16, 2023 -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/

1 0

[interop][ptg] Virtual Caracal vPTG Planning
by Martin Kopec 18 Oct '23

18 Oct '23

Hello everyone, here is [1] our etherpad for the 2024.1 Caracal virtual PTG. Please, add your topics there if there is anything you would like to discuss / propose ... You can also vote for time slots for our session(s), so that they fit your schedule, at [2]. I have one topic I'd like to discuss - new view on interoperability testing, see [3] and this [4] article for the background info. [1] https://etherpad.opendev.org/p/oct2023-ptg-interop [2] https://framadate.org/rNFvjKVkMnXPfObf [3] https://etherpad.opendev.org/p/openstack-interop-2.0 [4] https://superuser.openinfra.dev/articles/new-view-on-interoperability-in-op… If you have any questions, feel free to reach out to me. Thanks, -- Martin Kopec Principal Software Quality Engineer Red Hat EMEA IM: kopecmartin

1 2

[qa][ptg] Virtual Caracal vPTG Planning
by Martin Kopec 18 Oct '23

18 Oct '23

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

1 2

[Glance][PTG] Caracal PTG Schedule
by Pranali Deore 18 Oct '23

18 Oct '23

Hello All, Caracal PTG is going to start next week and we have created our PTG etherpad [1] and also added day wise topics along with timings we are going to discuss. Kindly let me know if you have any concerns with allotted time slots. Friday is reserved for any unplanned discussions. So please feel free to add your topics if you haven't added yet. As a reminder, these are the time slots for our discussion. Tuesday 24 OCT 2023 1400 UTC to 1700 UTC Wednesday 25 OCT 2023 1400 UTC to 1700 UTC Thursday 26 OCT 2023 1400 UTC to 1700 UTC Friday 27 OCT 2023 1400 UTC to 1700 UTC NOTE: At the moment we don't have any sessions scheduled on Friday, if there are any last moment request(s)/topic(s) we will discuss that on Friday else we will conclude our PTG on Thursday 26th OCT. We will be using Gmeet for our discussion. The meeting URL is mentioned in etherpad [1] and will be the same throughout the PTG. [1] https://etherpad.opendev.org/p/oct2023-ptg-glance Hope to see you there!! Thanks & Regards, Pranali Deore

1 0

test
by Colin Tooley 18 Oct '23

18 Oct '23

test Colin Tooley Principal IT Support Engineer, IT Experience (ITX) Global Enterprise Support Red Hat NA <https://www.redhat.com> ctooley(a)redhat.com IM: ctooley <https://www.redhat.com>

1 0

[release] Release countdown for week R-24, Oct 16 - 20
by Herve Beraud 18 Oct '23

18 Oct '23

Welcome back to the release countdown emails! These will be sent at major points in the 2024.1 Caracal development cycle, which should conclude with a final release on April 3, 2024. Development Focus ----------------- At this stage in the release cycle, focus should be on planning the 2024.1 Caracal development cycle, assessing 2024.1 Caracal community goals and approving 2024.1 Caracal specs. General Information ------------------- 2024.1 Caracal is a 26 weeks development cycle. In case you haven't seen it yet, please take a look over the schedule for this release: https://releases.openstack.org/ <https://releases.openstack.org/caracal/schedule.html>caracal <https://releases.openstack.org/caracal/schedule.html>/schedule.html <https://releases.openstack.org/caracal/schedule.html> By default, the team PTL is responsible for handling the release cycle and approving release requests. This task can (and probably should) be delegated to release liaisons. Now is a good time to review release liaison information for your team and make sure it is up to date: https://opendev.org/openstack/releases/src/branch/master/data/release_liais… By default, all your team deliverables from the 2023.2 Bobcat release are continued in 2024.1 Caracal with a similar release model. Upcoming Deadlines & Dates -------------------------- Virtual Caracal PTG: October 23-27 2024.1 Caracal-1 milestone: November 16, 2023 -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/

1 0

[release] Release countdown for week R-24, Oct 16 - 20
by Herve Beraud 18 Oct '23

18 Oct '23

Welcome back to the release countdown emails! These will be sent at major points in the 2024.1 Caracal development cycle, which should conclude with a final release on April 3, 2024. Development Focus ----------------- At this stage in the release cycle, focus should be on planning the 2024.1 Caracal development cycle, assessing 2024.1 Caracal community goals and approving 2024.1 Caracal specs. General Information ------------------- 2024.1 Caracal is a 26 weeks development cycle. In case you haven't seen it yet, please take a look over the schedule for this release: https://releases.openstack.org/ <https://releases.openstack.org/caracal/schedule.html>caracal <https://releases.openstack.org/caracal/schedule.html>/schedule.html <https://releases.openstack.org/caracal/schedule.html> By default, the team PTL is responsible for handling the release cycle and approving release requests. This task can (and probably should) be delegated to release liaisons. Now is a good time to review release liaison information for your team and make sure it is up to date: https://opendev.org/openstack/releases/src/branch/master/data/release_liais… By default, all your team deliverables from the 2023.2 Bobcat release are continued in 2024.1 Caracal with a similar release model. Upcoming Deadlines & Dates -------------------------- Virtual Caracal PTG: October 23-27 2024.1 Caracal-1 milestone: November 16, 2023 -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/

1 0

[cinder] Cancelling this week's meeting (18 Oct)
by Rajat Dhasmana 18 Oct '23

18 Oct '23

Hello Argonauts, As you might be aware, we are going to have 2024.1 Caracal Cinder PTG next week from 24 October to 28 October, 2023. We will get a lot of time to meet and discuss topics there so let's cancel this week's cinder meeting (which was going to be held on 18 October). Don't forget to add topics to the planning etherpad[1]. See you all at the PTG! [1] https://etherpad.opendev.org/p/caracal-ptg-cinder-planning Thanks Rajat Dhasmana

1 0