October 2024 - openstack-discuss - lists.openstack.org

[qa][all] stable/2023.1 gate is blocked (hold the recheck)
by Ghanshyam Mann 31 Oct '24

31 Oct '24

Hello Everyone, Yatin pointed out that the python 3.8 drops impacted the stable/2023.1 focal jobs also. As per the stable/2023.1 testing runtime[1], we run at least one job on focal and the rest all on jammy. Python 3.8 drops broke the focal job[2]. To solve this, we need to pin the Tempest on stable/2023.1 testing (Yatin has proposed it[3]) We are testing it on neutron gate - https://review.opendev.org/c/openstack/neutron/+/933705 Until the fixes[3] are merged, please hold off on rechecking stable/2023.1 focal job failure. [1] https://governance.openstack.org/tc/reference/runtimes/2023.1.html#addition… [2] https://bugs.launchpad.net/devstack/+bug/2085886 [3] https://review.opendev.org/q/topic:%22bug/2085886%22 -gmann

1 1

[python-openstackclient] List security group IDs used by a VM with "openstack server show"
by Sebastian Luna Valero 31 Oct '24

31 Oct '24

Hello, Currently "openstack server show" provides the list of security groups used by the VM. However, this is a list of names only [1]. Therefore a VM may contain multiple security groups with the same name but different IDs. However, getting the IDs of the security groups used by a VM seems possible according to the API [2]. Would it be possible to make this available via the python-openstackclient CLI? Many thanks, Sebastian [1] https://docs.openstack.org/api-ref/compute/#show-server-details [2] https://docs.openstack.org/api-ref/compute/#list-security-groups-by-server

2 1

[barbican] KMIP integration
by przemyslaw.kuczynski＠ochk.pl 31 Oct '24

31 Oct '24

Why KMIP integration always create OPAQUE secret with name Opaque Object . There can be created only 1 entry Is there bug ? https://bugs.launchpad.net/barbican/+bug/2033620

2 1

How best to find a compatible cpu model for disparate CPUs?
by Andy Speagle 31 Oct '24

31 Oct '24

Hey Folks, I have some wildly disparate CPUs throughout my nova-compute environment and I'm trying to figure out the best way to find the correct cpu_model and any "extra_flags" that might need to be passed. According to "virsh capabilities" I have Broadwell-IBRS, Skylake- Server-IBRS and SapphireRapids-noTSX ... And... my attempts at finding a compatible model/flags has failed miserably. I tried getting all of the "capabilities" in one file and passing that through "virsh cpu-baseline" but that returned something completely incompatible with the Broadwell ... I looked at "virsh domcapabilities" and found that they all support "Broadwell-noTSX-IBRS" ... and nova- compute will start up using that... but, live migrations between the Broadwell and Skylake CPUs to the SapphireRapids doesn't work properly. tl;dr ... any tips on making this work with wildly disparate CPUs? -- Andy Speagle

3 2

[skyline]Using multi-domain management with the skyline UI
by 啧啧啧 31 Oct '24

31 Oct '24

Hi , Skyline Team I'm trying the skyline UI using multi-domain management, find some problems。 I created a new domain for domain-test1 using the openstack backend, create a test1 project under domain-test1. I used the skyline UI to add users to the test1 project and found that the user under the default domain could be added and given the admin role, but it was not available. I understand that this assignment is wrong and that the roles of project management should be different for projects that are not in the same domain. At the same time, I used skyline to try to integrate keystone LDAP. Reference https://docs.openstack.org/keystone/latest/admin/configurati…. I used the openstack backend to create a new domain for domain-test2 and create a test2 project under domain-test2 to configure ldap. I used the skyline ui to view the users in the domain-test2 domain, and all the users configured in ldap could be queried. The project in the domain-test2 domain could not manage the view users and was authorized.

1 0

[skyline]Using multi-domain management with the skyline UI
by 任亮 30 Oct '24

30 Oct '24

Hi , Skyline Team I'm trying the skyline UI using multi-domain management, find some problems。 I created a new domain for domain-test1 using the openstack backend, create a test1 project under domain-test1.  I used the skyline UI to add users to the test1 project and found that the user under the default domain could be added and given the admin role, but it was not available. I understand that this assignment is wrong and that the roles of project management should be different for projects that are not in the same domain. At the same time, I used skyline to try to integrate keystone LDAP. Reference https://docs.openstack.org/keystone/latest/admin/…. I used the openstack backend to create a new domain for domain-test2 and create a test2 project under domain-test2 to configure ldap. I used the skyline ui to view the users in the domain-test2 domain, and all the users configured in ldap could be queried.  The project in the domain-test2 domain could not manage the view users and was authorized.

1 0

[PTL][release][stable] 2023.1 Antelope transition to Unmaintained
by Elõd Illés 30 Oct '24

30 Oct '24

Hi teams, As 2024.2 Dalmatian was released last week and we are in a less busy period, now is the good time to call your attention to the following: At the end of October 2023.1 Antelope is planned to transition to Unmaintained phase [1] (planned date: 2024-10-30). I have generated the list of the current *open* and *unreleased* changes in stable/2023.1 for every repositories [2] (where there are such patches). These lists could help the teams who are planning to do a *final* release on Antelope before moving stable/2023.1 branches to unmaintained/2023.1. Feel free to edit and extend these lists to track your team's progress! Note that the last hash on stable/2023.1 branch will be tagged ('<series>-eom' tag) and transition patches will be generated soon. After the tagging and cutting unmaintained/2023.1 branch, the new unmaintained branch will be open to for bug fixes, but there won't be official releases for 2023.1 Antelope anymore. (You can get some information about the Unmaintained state on stable policy page [3]). *NOTE*: teams, please focus on wrapping up your libraries first if there is any concern about the changes, in order to avoid broken (final!!) releases! [1] https://releases.openstack.org/ [2] https://etherpad.opendev.org/p/2023.1-antelope-final-release-before-eom [3] https://docs.openstack.org/project-team-guide/stable-branches.html#unmainta… Thanks, Előd Illés irc: elodilles @ #openstack-release

2 1

[manila] Cancelling Oct 31 weekly meeting
by Carlos Silva 30 Oct '24

30 Oct '24

Hello everyone! Traditionally in the past cycles we cancelled the upstream weekly meeting that followed the PTG to get closure to some PTG AIs. I believe we can continue that tradition this time too. We'll get back to the weekly meetings next week, Nov 7th. If you have something urgent, please ping me on IRC. Regards, carloss

1 0

[tooz] Recommended driver
by William Szumski 30 Oct '24

30 Oct '24

Hi all, Just wondering what the recommend driver is these days. The docs[1] seem to suggest zookeeper is the most stable and feature rich. Is that still the case? Is it advisable to use zookeeper over redis/valkey? What gets the most testing in upstream CI? Thanks, Will [1] https://docs.openstack.org/tooz/latest/user/drivers.html

3 2

[Openstack-Helm] 2025.1 Epoxy PTG session summary
by Vladimir Kozhukalov 30 Oct '24

30 Oct '24

Hi Openstack-Helmers, Thank you for attending our 3 hours 2025.1 (Epoxy) PTG session. The session etherpad is here [0] and the following is the short summary. Items listed below are more or less sorted by their priority. ### Charts Agreed to fix the issue regarding overriding charts when publishing them with the same version. There must be a spec that clearly describes the workflow of how we are going to bump versions, build and publish charts. Items: - Migrate from Helm API v1 to Helm API v2 for Chart.yaml (including tracking dependencies in the Chart.yaml file instead of requirements.yaml) - Move overrides to a separate directory - Add CHANGELOG.md to every chart - Since we are using kubernetes-entrypoint [1] for orchestration, let's consider removing post-* hooks. This is going to make it easier to integrate with third party CI/CDs. - Let's consider switching to the same major version for all charts. If the subchart is changed the minor chart version must be bumped. ### Secrets Some upstream charts provide the possibility to refer to existing secrets. See for example [2]. This allows easy integration with various CI/CDs. We agreed to create a design spec and implement a similar pattern to make it possible for users to get sensitive info from external predeployed secrets. Also in some cases users would like to stick to third party projects when talking about Openstack backend like MariaDB and RabbitMQ. The spec must also describe the way how we are going to make OSH charts compatible with this. In case of Rook Ceph we use `ceph-adapter-rook` chart which takes care of creating secrets that are then consumed by the rest of charts. Probably the same approach can work for other cases. ### Images - We agreed to de-duplicate the image build code for Openstack images and switch to using Loci images. - Loci tries to go its own way using one Dockerfile for building all Openstack projects. This leads to having project/version specific parts in the build workflow that makes it harder for users to customise the build workflow. Let's be more straightforward here. There are examples like this [3] where per project Dockerfiles are used that utilize two base images for `python-venv-builder` and `python-runtime`. Let's consider adopting this approach. Agreed to prepare a spec for this. ### Gateway API, Ingress, NetworkPolicy, PodDisruptionBudget ... Gateway API is coming and is supposed to substitute the Ingress API. We agreed to prepare the design to support Gateway API. Also let's try to re-factor the way how the Openstack-Helm charts deploy Ingress objects and try to follow more common practices regarding this. Instead of having these two types of Ingresses cluster and namespace it is better to have a way for a user to define explicitly the list of Ingresses with their routes. Let's also use similar pattern for managing other optional K8s API obejects like NetworkPolicies and PodDisruptionBudget. It is better for users when they are able to define explicitly what they want to deploy instead of using hidden logic like what we have for managing Ingresses. Design spec is needed. ### Noble It is not clear at the moment whether Ceph will officially support Noble by 2025.1. So perhaps we'll be forced to build 2025.1 Jammy images. Anyway we are going to have two sets of test jobs with Jammy and Noble as a host OS. This is to make sure users can upgrade the host OS smothly. At the moment there are no volunteers to add support any other OS. ### Testing There are lots of test cases and having all these test jobs in the check pipeline not necessary. Instead we agreed to have a meta layer for tracking all these test cases and generate zuul jobs files programmatically. ### OceanBase OceanBase is a distributed database compatible with MariaDB. This is the blog post [4] about how it can be used with Openstack as the DB backend. The OceanBase team showed a demo during OpenInfra days in Asia in Sep/2024. We agreed that this use case can be interesting at least for some users so let's have a test job for this. [0] https://etherpad.opendev.org/p/oct2024-ptg-os-helm [1] https://github.com/airshipit/kubernetes-entrypoint.git [2] https://github.com/bitnami/charts/blob/f14d986d3713716a9b263075ac784ef74943… [3] https://github.com/vexxhost/atmosphere/tree/main/images [4] https://en.oceanbase.com/blog/13879352832 -- Best regards, Kozhukalov Vladimir

1 0