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

[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

[cinder] No meeting today (10/30)
by Jon Bernard 30 Oct '24

30 Oct '24

Hello all, I'm not feeling well today and need to cancel today's meeting. See you all next wednesday. -- Jon

1 0

[horizon][ptg] 2025.1 Epoxy PTG summary
by Radomir Dopieralski 30 Oct '24

30 Oct '24

We had two days of Horizon discussion on the last PTG, first the internal one: https://etherpad.opendev.org/p/horizon-epoxy-ptg and then the cross-project sessions with other teams: https://etherpad.opendev.org/p/horizon-feature-gap On the first day we looked back at the previous cycle and summarized what was achieved, and what needs further attention. We mentioned the work done for Neutron API migrating it to OpenStackSDK, the improvements of integration and UI tests, and the work done by our Outreachy student. We discussed ways to make Horizon easier to approach for new developers. We also discussed the problems with AngularJS and a plan to remove it from Horizon. On the second day, we met with other project teams and discussed what needs to be done in Horizon to bring it up to speed with the progress made in other projects. We also discussed further work on migrating to OpenStackSDK. After further discussion, we decided to focus in this cycle on the following issues: • New SASS compiler library • Remove AngularJS • Research Unified Limits • Placement API Discussion — follow-up meeting with the Nova team • Use "direct" upload mode by default in the operator configuration • Start migration to OpenStackSDK for Nova • GUI for managing Keystone 2FA • Configuring integration tests for different themes • Better grooming of upstream bugs and easy-to-start issues In addition, if there are new contributors or we have spare time, we consider working on: • Keystone Re-enable user • Refresh Cinder API microversions • Hidden image in Glance • Filtering of images dropdown in rebuild dialog • Show backends in Glance information

1 0

[Horizon] Cancelling weekly IRC meeting tomorrow
by Tatiana Ovchinnikova 30 Oct '24

30 Oct '24

Hello team, Thank you for joining the vPTG last week! Since there's a week of chaos because of the time change, and part of the team is on PTO, I'm canceling our weekly meeting tomorrow. See you all next Wednesday! With kind regards, Tatiana

1 0

[i18n][ptg] I18n SIG vPTG summary
by Ian Y. Choi 30 Oct '24

30 Oct '24

Hi all, I would like to share with you a summary of the recent discussions held during the 2025.1 Epoxy PTG regarding the Internationalization (I18n) Special Interest Group (SIG). During the period, the I18n SIG explored approaches to improve multilingual support, discussing Weblate migration, AI-based translation implementation, sustainable documentation translation strategies, and addressing current translation tool issues. Special thank you to TC and Nova team for elaborate discussions. Please refer to the below brief summary from Etherpad: https://etherpad.opendev.org/p/oct2024-ptg-i18n . 1. Overall Translation Status discussion - Clarifying that StringFreezes applies to Horizon and dashboard plugin projects [1] - Confusion exists about the current state of translations. Horizon translations were added months ago but not proposed by the tooling. : No translation proposals on the master branch after April 19, 2024. [2] : Horizon removed Python 3.8 support [3], while translation jobs depend on Ubuntu Bionic. 2. Towards sustainable Documentation Translation - Discussion on utilizing AI machine translation: : Proposal to use Weblate's machine translation feature. : Consideration of open-source tools like LibreTranslate [4]. : Concerns raised about legal issues. - Emphasis on the necessity of human reviewers: : Suggestion to create a 'language-moderator' group in Gerrit? : Need to add voting labels for translation patches. 3. Weblate Migration - Ongoing migration of translated project files from Zanata to Weblate. - Integration with Zuul is the second-phase goal. - Difficulties encountered due to API usage issues. 4. Weblate Issues - There was an authentication issue with Weblate and openinfraid (note: but it appears to be resolved now. Thank you @rosmaita!) 5. AI Translation Approach - Step-by-step ways a. Model selection b. Community review of the model c. Model utilization d. Model + RAG (Reviewed/Translated OpenStack documents, glossary) utilization - Plan to conduct PoC with Nova RST documents. 6. Action items - To start a 3-month PoC to test AI translation with Nova RST files (ianychoi) - Zuul investigation for Weblate migration (seongsoocho) - Horizon Zuul job issue check (discussion with other teams) Thank you all, /Ian [1] https://review.opendev.org/c/openstack/releases/+/930929 [2] https://review.opendev.org/q/owner:proposal-bot+project:openstack/horizon+b… [3] https://docs.openstack.org/releasenotes/horizon/2024.2.html#upgrade-notes [4] https://github.com/LibreTranslate/LibreTranslate

1 0

[all[qa] Tempest dropping python 3.8 support
by Ghanshyam Mann 29 Oct '24

29 Oct '24

Hello Everyone, As you know, services and Oslo libs are dropping Python 3.8 in this cycle. Tempest is branchless, and we use Tempest master to test all supported stable branches (currently 2023.1 to 2024.2). Because Python 3.8 is still supported in stable/2023.1 to stable/2024.1 Initially, we thought of continuing the py 3.8 support in Tempest, but without Oslo libs, Tempest cannot support it. One way is to keep the python 3.8 constraints separately (either a separate file in Tempest or separate constraints for python3.8 in requirements), which stops Tempest from adding any new features from oslo/deps. Another way (this is what we did in the previous Python version bump) is to drop the Python 3.8 support, and if anyone wants to test the cloud with Python 3.8, they can install and run Tempest on Python >=3.9 virtual env. In upstream testing, we also install and run Tempest from the virtual environment. or use the Tempest 41.0.0 (the last release which supports py3.8) to test python 3.8 cloud. This is what we did during py3.6/3.7 support removal. - https://review.opendev.org/c/openstack/tempest/+/933398 -gmann

1 1

Re: [Cinder][Ceph] Volumetria errada no cluster ceph
by Luiz Fernando Silva 29 Oct '24

29 Oct '24

I am sending the file with the ceph osd df tree and ceph pg ls-by-pool volumes output as an attachment. ceph -s: cluster: id: ccdcc86e-c0e7-49ba-b2cc-f8c162a42f91 health: HEALTH_OK services: mon: 3 daemons, quorum hc-node02,hc-node04,hc-node03 (age 5w) mgr: hc-node02(active, since 4M) osd: 54 osds: 54 up (since 14h), 54 in (since 3M) task status: data: pools: 5 pools, 3424 pgs objects: 4.25M objects, 43 TiB usage: 88 TiB used, 32 TiB / 120 TiB avail pgs: 3424 active+clean io: client: 16 MiB/s rd, 5.7 MiB/s wr, 856 op/s rd, 483 op/s wr Thank you very much, we will adjust to replica 3.

1 0

Re: [barbican][vault]
by Andy Speagle 29 Oct '24

29 Oct '24

On Thu, 2024-10-24 at 18:06 -0700, melanie witt wrote: > On 10/24/24 16:43, Andy Speagle wrote: > > Hey Folks, > > > > I'm having some trouble getting barbican to generate and/or store > > keys > > in our hashicorp vault in our charmed openstack environment. I have > > issues with both TPM and SSL related keys. > > > > I get extremely generic errors back that I can't seem to figure out > > how > > to troubleshoot: > > > > 'Traceback (most recent call last):\n File "/usr/lib/python3/dist- > > packages/nova/conductor/manager.py", line 688, in build_instances\n > > scheduler_utils.populate_retry(\n File "/usr/lib/python3/dist- > > packages/nova/scheduler/utils.py", line 998, in populate_retry\n > > raise > > exception.MaxRetriesExceeded(reason=msg)\nnova.exception.MaxRetries > > Exce > > eded: Exceeded maximum number of retries. Exceeded max scheduling > > attempts 3 for instance 0c50b2d7-8ac5-41a2-90ab-1e33f7aa1c22. Last > > exception: Key manager error: Internal Server Error: Secret > > creation > > failure seen - please contact site administrator.\n' > > Just FYI this is the generic MaxRetriesExceeded error which means > that > the server action failed on nova-compute(s). So you'll want to look > in > your nova-compute.log for the error that triggered the retries and > eventual MaxRetriesExceeded. > > > I'm using barbican 14.0.2 in yoga/stable ... anyone have an ideas > > how > > to troubleshoot this? > > I'm guessing in nova-compute.log you will see an error 403 forbidden > for > creating a barbican secret. If so, the most common reason I have seen > for this is if you have in your barbican.conf > [oslo.policy]enforce_new_defaults = False, then secret creates > require > the requester to have the 'creator' role assigned to them (you can do > this by 'openstack role add <options> <role>' [1]). > > When [oslo.policy]enforce_new_defaults = True, the 'creator' role is > not > required. Yup... nailed it. I really appreciate the insight. :) > The tl;dr is 'enforce_new_defaults' means to use the newer secure > RBAC > policies and the secure RBAC changes are shown in the Wallaby release > notes:

1 0