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

GPU PCI passthrough woes.
by Andy Speagle 30 Oct '24

30 Oct '24

Hey Folks, I could use a little assistance getting GPU passthrough working. I had this working already for one flavor of nvidia gpu... and I've added some hosts with a much newer gpu... I've updated the pci_alias and pci_passthrough variables and those seem to be getting set properly in nova.conf passthrough_whitelist = [{"vendor_id":"10de", "product_id":"1b06"},{"vendor_id":"10de", "product_id":"26b9"}] alias = {"name": "gpu", "product_id": "1b06", "vendor_id": "10de"} alias = {"name": "gpu-l40s", "product_id": "26b9", "vendor_id": "10de"} I believe I have all of the iommu stuff configured and have the pci- stub module entries... dmesg output shows that the GPUs are being claimed by the stub module. $ openstack flavor show t1.small_gpu_l40s +----------------------------+--------------------------------------+ | Field | Value | +----------------------------+--------------------------------------+ | OS-FLV-DISABLED:disabled | False | | OS-FLV-EXT-DATA:ephemeral | 0 | | access_project_ids | None | | description | None | | disk | 0 | | id | af70c94e-0026-4a39-bc1e-dfb93b286a54 | | name | t1.small_gpu_l40s | | os-flavor-access:is_public | True | | properties | pci_passthrough:alias='gpu-l40s:1' | | ram | 2048 | | rxtx_factor | 1.0 | | swap | 0 | | vcpus | 1 | +----------------------------+--------------------------------------+ Yet... I can't seem to get an instance to run using that new flavor... keeps complaining about there not being enough hosts available. Fault: code: 500 created: 2024-10-30T02:04:33Z message: "No valid host was found. There are not enough hosts available." details: | Traceback (most recent call last): File "/usr/lib/python3/dist-packages/nova/conductor/manager.py", line 1580, in schedule_and_build_instances host_lists = self._schedule_instances(context, request_specs[0], File "/usr/lib/python3/dist-packages/nova/conductor/manager.py", line 940, in _schedule_instances host_lists = self.query_client.select_destinations( File "/usr/lib/python3/dist- packages/nova/scheduler/client/query.py", line 41, in select_destinations return self.scheduler_rpcapi.select_destinations(context, spec_obj, File "/usr/lib/python3/dist-packages/nova/scheduler/rpcapi.py", line 160, in select_destinations return cctxt.call(ctxt, 'select_destinations', **msg_args) File "/usr/lib/python3/dist- packages/oslo_messaging/rpc/client.py", line 189, in call result = self.transport._send( File "/usr/lib/python3/dist- packages/oslo_messaging/transport.py", line 123, in _send return self._driver.send(target, ctxt, message, File "/usr/lib/python3/dist- packages/oslo_messaging/_drivers/amqpdriver.py", line 689, in send return self._send(target, ctxt, message, wait_for_reply, timeout, File "/usr/lib/python3/dist- packages/oslo_messaging/_drivers/amqpdriver.py", line 681, in _send raise result nova.exception_Remote.NoValidHost_Remote: No valid host was found. There are not enough hosts available. Traceback (most recent call last): File "/usr/lib/python3/dist- packages/oslo_messaging/rpc/server.py", line 241, in inner return func(*args, **kwargs) File "/usr/lib/python3/dist-packages/nova/scheduler/manager.py", line 223, in select_destinations selections = self._select_destinations( File "/usr/lib/python3/dist-packages/nova/scheduler/manager.py", line 250, in _select_destinations selections = self._schedule( File "/usr/lib/python3/dist-packages/nova/scheduler/manager.py", line 416, in _schedule self._ensure_sufficient_hosts( File "/usr/lib/python3/dist-packages/nova/scheduler/manager.py", line 455, in _ensure_sufficient_hosts raise exception.NoValidHost(reason=reason) nova.exception.NoValidHost: No valid host was found. There are not enough hosts available. Any clues on how/where to dig into this more to see what might be missing? Thanks. -- Andy Speagle

2 1

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

29 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][infra][horizon] Zanata translation job failures after Python 3.8 deprecation
by Ian Y. Choi 29 Oct '24

29 Oct '24

Hi all, During last week's PTG, the I18n SIG identified Zanata translation job failures for Horizon (and likely related plugins). The root cause appears to be Python 3.8 deprecation on Horizon [1]. Failed jobs have been observed on Zuul [2], and translation proposals were made on Gerrit [3]. Since translation sync on Horizon stable branches is functioning correctly, the error message seems to be related to Python 3.8 deprecation: ERROR: Cannot install -r doc/requirements.txt (line 3) due to conflicting package version dependencies. To address this, I'd like to raise two points: 1/ To resolve the issue, would you support updating translation sync jobs with Bionic-based Zuul jobs by either upgrading to Jammy or modifying the Bionic image to support Python >3.8? 2/ At least me from I18n SIG acknowledges that recognizing these translation job errors was delayed. Moving forward, would it be beneficial to implement periodic (e.g., monthly) reporting on translation job successes and failures? Thank you, /Ian [1] https://docs.openstack.org/releasenotes/horizon/2024.2.html#upgrade-notes [2] https://zuul.opendev.org/t/openstack/builds?job_name=propose-translation-up… [3] https://review.opendev.org/q/owner:proposal-bot+project:openstack/horizon+b…

2 1

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

29 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