- openstack-discuss - lists.openstack.org

[kolla-ansible] rocky spice containers missing
by Michael Knox 11 Dec '23

11 Dec '23

Hi all. I was looking to use SPICE instead of VNC, but noticed that there are no rocky containers for it on quay.io. I found a ticket for CentOS 8 source, is this still the same reason? https://bugs.launchpad.net/kolla-ansible/+bug/1955549 Cheers Michael

3 3

[neutron] Bug Deputy Report December 4 - December 10
by Lajos Katona 11 Dec '23

11 Dec '23

Hi Neutrinos, I was the Neutron bug deputy last week, and I send the report of last week's bugs. - High prio bugs - Unassigned: https://bugs.launchpad.net/neutron/+bug/2045549 (OVS jobs randomly fails as Guest VMs not(or delayed) configured with DHCP) - https://bugs.launchpad.net/neutron/+bug/2045725 (scenario jobs randomly fails downloading ubuntu image) - related devstack patch: https://review.opendev.org/c/openstack/devstack/+/901699 - Medium prio bugs: - https://bugs.launchpad.net/neutron/+bug/2045811 (neutron-ovn-db-sync-util can fail with KeyError) - https://review.opendev.org/c/openstack/neutron/+/902841 - https://bugs.launchpad.net/neutron/+bug/2045889 ([OVN] ML2/OVN mech driver does not set the OVS bridge name in the port VIF details) - related mail thread: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… - https://bugs.launchpad.net/neutron/+bug/2045950 (Security group performance issue for iptables driver due to "stateless feature") - performance issue with stateless security-groups. Best wishes Lajos Katona (lajoskatona)

1 0

[all] Ussuri and Train EOL
by Elõd Illés 11 Dec '23

11 Dec '23

Hi, With the new TC resolution '2023-07-24 Unmaintained status replaces Extended Maintenance' [1] the last 3 EM branches (Xena, Wallaby, Victoria) will transition to Unmaintained, but older branches (Ussuri, Train) should move to End of Life unless someone steps up as maintainer of this branch for this project. (In that case the branch of that project will transition to unmaintained/{ussuri,train}) To signal this, please add a -1 for the given generated EOL patch [2][3] if you or the team want to keep this branch open for further maintenance. If there is no response from anyone within a reasonable time frame, then PTLs/release liaisons will be asked to confirm the EOL transition with their +1. Thanks, Előd Illés irc: elodilles @ #openstack-stable / #openstack-release [1] https://governance.openstack.org/tc/resolutions/20230724-unmaintained-branc… [2] https://review.opendev.org/q/topic:train-eol [3] https://review.opendev.org/q/topic:ussuri-eol

1 0

[docs]OpenStack compatible list
by steven.wang＠gigacomputing.com 11 Dec '23

11 Dec '23

Hi, For OpenStack compatible check, how should we know the connection with base OS? Example; If the machine support RHEL9 and OpenStack Wallaby, can we say it is compatible to the newest OpenStack than Wallaby? So it should be no problem with Xena, Yoga, Zed, Antelope and Bobcat? Or please kindly let me know where can find the similar document? Thanks. Steven

2 2

System configuration in OpenStack
by lostghost1 11 Dec '23

11 Dec '23

Hi all, Sorry if this has been asked already, but is it feasible to use OpenStack to configure running systems - including virtual instances, containers, and the physical nodes themselves. I know that conceptually OpenStack takes a hands-off approach - it deals with images in abstract and further configuration is delegated to tools such as Ansible. Same for bare metal nodes - you provision them with Ironic, flash an image to them, and that's where configuaration ends for OpenStack. At least this is how I understand it, may be wrong. I was thinking about introducing systems configuration as a first-class concept into OpenStack - that means integration with the package manager, writing of config files from templates, filesystem management in general. The most well thought-out "solution" that there is for systems configuration is Nix in my opinion. I could intergrate it into OpenStack, I could write my own package manager. I haven't decided yet, these are just ideas for a pet project. So if I were to do such a thing, how would I go about achieving it? Obviously I would need to write a Horizon console module for the web UI. But beyond that I'd also need integration with other components. What do you all think?

1 0

Redundancy and high availability of basic services...
by Jorge Visentini 10 Dec '23

10 Dec '23

Hello everybody. I've been studying for some time now, reading official and third-party documentation about deploying and day-to-day maintenance of openstack. What I don't usually read about is the redundancy and high availability of basic services, such as the database, keystone, neutron... I wanted to better understand how it works in a small deployment scenario... I mean... 5 or 10 nodes and 3 controllers, for example... Here we use block storage fiber channel, so we won't use ceph... Of course, I won't implement it in production overnight, but I would like to hahaha but I would like to better understand this part of service redundancy. Thank you all for the emails sent every day. I learn a lot from them. -- Att, Jorge Visentini +55 55 98432-9868

1 0

[all] [ironic] Heads-up: another eventlet-related issue on Stream 8
by Dmitry Tantsur 09 Dec '23

09 Dec '23

Hi stackers, I've noticed this some time ago, but somehow decided that it wouldn't affect OpenStack upstream. Early sign of burn-out? Anyway... Red Hat has fixed CVE 2023-40217 in its Python 3.6 packages (used by default on CentOS Stream 8). Unfortunately, it was done in a way that breaks TLS in eventlet (more details in https://issues.redhat.com/browse/OCPBUGS-20486) It manifests in the following traceback: Traceback (most recent call last): File "/usr/lib64/python3.6/ssl.py", line 754, in __init__ self.getpeername() OSError: [Errno 107] Transport endpoint is not connected During handling of the above exception, another exception occurred: Traceback (most recent call last): <... SNIP ...> File "/usr/lib/python3.6/site-packages/oslo_service/wsgi.py", line 173, in start self.dup_socket = sslutils.wrap(self.conf, self.dup_socket) File "/usr/lib/python3.6/site-packages/oslo_service/sslutils.py", line 104, in wrap return ssl.wrap_socket(sock, **ssl_kwargs) # nosec File "/usr/lib/python3.6/site-packages/eventlet/green/ssl.py", line 422, in wrap_socket return GreenSSLSocket(sock, *a, **kw) File "/usr/lib/python3.6/site-packages/eventlet/green/ssl.py", line 117, in __init__ ca_certs, do_handshake_on_connect and six.PY2, *args, **kw) File "/usr/lib64/python3.6/ssl.py", line 759, in __init__ blocking = (self.gettimeout() != 0) File "/usr/lib/python3.6/site-packages/eventlet/green/ssl.py", line 145, in gettimeout return self._timeout AttributeError: 'GreenSSLSocket' object has no attribute '_timeout' The fix should be rather simple IMO: just remove the condition on Python 2 from here: https://github.com/eventlet/eventlet/blob/master/eventlet/green/ssl.py#L108. But I'm not sure, given the state of eventlet community, we can land anything these. The issue affects, for example. ironic-python-agent on stable/yoga. We're considering our options, the most likely is to use a non-default Python, which is 3.9. Xena and older did not support 3.9, so they're probably out in the cold... Thoughts, ideas? Dmitry

3 5

[goals][kolla][tripleo][all] Migrating from WSGI scripts to module paths
by Stephen Finucane 09 Dec '23

09 Dec '23

o/ For anyone that hasn't been following along, there are changes coming down the line in the Python packaging world that look likely to break pbr's 'wsgi_scripts' entrypoint functionality. As things stand, if we do nothing then at some point these auto-generated scripts will no longer end up in 'bin' when pip installed (as we do with e.g. DevStack). From where I'm standing, we appear to have two options: we can either invest time in pbr to re-implement this functionality from scratch, or we can drop the idea of auto-generating wsgi scripts from our packaging tool and instead start using module paths. Having looked at the former, I suspect it is going to be a *lot* of work that will require implementing our own PEP-517 compatible build backend instead of cribbing setuptools' one as we do now. Personally, I don't think this is a good investment of anyone's time, and it gives us more stuff to maintain for the many years ahead (Did you know that pbr *still* technically supports Python 2. Fun story that). As such, I think we should instead look to the former. I've proposed some patches for Nova [1][2], which I am hoping will provide a blueprint for the other services, and patch for DevStack to enable the new Nova functionality [3]. As you'll see, these patches are relatively small and hopefully easy to grok. The biggest downside I see to this approach is that tooling which deploys Apache+mod_wsgi rather than uWSGI used by e.g. DevStack will need to start packaging their own wsgi script. This is because mod_wsgi does not appear to support configuration by module paths. On the flipside, gunicorn does not support configuration by wsgi script so we get that for free. I would like to hear other's opinions on this approach. As this is something that likely affects all services, I suspect that if there's consensus that this is the correct way to go, there should probably be a small goal drafted for the current cycle. In my opinion, it would be good to do the migration consistently: in nova's case, I have proposed placing wsgi objects in the 'nova.wsgi' module and IMO if all projects could adopt the same convention we would make the lives of our deployment tooling colleagues easier. Please do let me know if you have any questions or concerns. Cheers, Stephen [1] https://review.opendev.org/c/openstack/nova/+/902687/2 [2] https://review.opendev.org/c/openstack/nova/+/902688/2 [3] https://review.opendev.org/c/openstack/devstack/+/902758/1

10 23

[keystone] Reviewathon canceled today
by Dave Wilde 08 Dec '23

08 Dec '23

Hi folks, I'm on PTO today and will be canceling the reviewathon unless someone else would like to run it. The Google Meet link will still work but I won't be there to run the meeting. Thanks! /Dave

1 0

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

08 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