December 2024 - openstack-discuss

[manila] Cancelling Dec 26th and Jan 2nd weekly meeting
by Carlos Silva 19 Dec '24

19 Dec '24

Hello zorillas, As announced in the previous weekly meetings, we will not have the upstream weekly meeting in the next two weeks, as most of the Zorillas will be taking a break over the year-end holidays. We will be back to our regular schedule on Jan 9th. Thank you very much for your collaboration throughout the year. This has been an incredible year and we got a lot done together. You definitely make this community more special. Wishing you a very well-deserved break! Cheers, carloss

1 0

[manila] Removal of the Standalone CephFS NFS Protocol Helper in Epoxy
by Ashley Rodriguez 19 Dec '24

19 Dec '24

Hi zorillas! As per subject line, we will be deprecating the standalone CephFS NFS protocol helper in this cycle. This is following our deprecation warning we put out in 2024.1 / Caracal [1] [2]. We've supported using a clustered Ceph NFS service since the Zed release. We've also added upgrade helpers to migrate from a standalone NFS-Ganesha service to the ceph-orch-deployed clustered NFS service; this code was backported to stable/2023.1 (Antelope). Although the upgrade path is disruptive, there is a UX improvement in Manila to ease this migration through surfacing “preferred” export paths. Moving forward, deployments must have “cephfs_nfs_cluster_id” in your configuration, otherwise the driver will fail to start. Manila will not make any export changes to NFS-Ganesha, so upgrading manila without an NFS cluster will mean that only the control plane is not going to work; but, data plane will remain unaffected. To assist migration, admins can also configure "cephfs_ganesha_export_ips" (or alternatively, "cephfs_ganesha_server_ip") alongside "cephfs_nfs_cluster_id". Setting these options will allow the CephFS driver to report additional export paths. These additional export paths will have the "preferred" metadata key set to False. Best, Manila team [1] https://review.opendev.org/c/openstack/manila/+/912648 [2] https://docs.openstack.org/manila/2024.2/configuration/shared-file-systems/…

1 0

[Glance] Cancelling weekly meeting for Next 2 weeks
by Mridula Joshi 19 Dec '24

19 Dec '24

Hello, Due to year end holidays, most of the team members are not around for the next two weeks, so cancelling weekly meetings . Next Glance meeting will be on January 9th !! Thanks, Mridula Joshi

1 0

[kolla] No weekly meetings until 8th January 2025
by Michał Nasiadka 19 Dec '24

19 Dec '24

Hello Koalas, Weekly meetings until 8th January (i.e. 25th Dec and 1st Jan) are cancelled. See you on 8th of January! Cheers, Michal

1 0

OpenStack APIs
by rushit.ajudiya＠crestdata.ai 19 Dec '24

19 Dec '24

Hello, We want to retrieve all hypervisors available in OpenStack using the Hypervisor API documented at https://docs.openstack.org/api-ref/compute/#list-hypervisors-details. The documentation states that the "limit" and "marker" parameters can be used to manage pagination, but they don’t seem to work as expected. Is this a problem with the API, or is there another parameter not mentioned in the documentation that we should use?

2 1

[placement] isolating aggregates on kolla-ansible
by przemyslaw.kuczynski＠ochk.pl 19 Dec '24

19 Dec '24

Did someone manage to configure Windows host aggregate ? I tried same is in https://docs.openstack.org/nova/2024.2/reference/isolate-aggregates.html 1. Created 2 aggregates in 2 AZ , added 1 host to each 2. Set the scheduler.enable_isolated_aggregate_filtering config option to true in nova.conf and restart the nova-scheduler service cat /etc/kolla-pilot/config/nova.conf [libvirt] hw_machine_type=x86_64=q35 [scheduler] enable_isolated_aggregate_filtering = True 3. Add trait CUSTOM_LICENSED_WINDOWS to the resource providers for kvm01 and kvm03 in the Placement service.openstack resource provider list +--------------------------------------+-------+------------+--------------------------------------+----------------------+ | uuid | name | generation | root_provider_uuid | parent_provider_uuid | +--------------------------------------+-------+------------+--------------------------------------+----------------------+ | 36c0ae68-cc5f-4219-94bb-e46bcd3311d9 | kvm01 | 257 | 36c0ae68-cc5f-4219-94bb-e46bcd3311d9 | None | | 8abb4b5e-0407-405d-97d1-7a03a9a06cbe | kvm03 | 129 | 8abb4b5e-0407-405d-97d1-7a03a9a06cbe | None | | 14ed0962-d8ce-4bed-b90a-243b3a069f5d | kvm02 | 1096 | 14ed0962-d8ce-4bed-b90a-243b3a069f5d | None | | 8714da8e-7e9b-4823-93bb-df819c143e99 | kvm04 | 87 | 8714da8e-7e9b-4823-93bb-df819c143e99 | None | +--------------------------------------+-------+------------+--------------------------------------+----------------------+ openstack --os-placement-api-version 1.6 trait create CUSTOM_LICENSED_WINDOWStraits=$(openstack --os-placement-api-version 1.6 resource provider trait list -f value 36c0ae68-cc5f-4219-94bb-e46bcd3311d9 | sed 's/^/--trait /')openstack --os-placement-api-version 1.6 resource provider trait set $traits --trait CUSTOM_LICENSED_WINDOWS 36c0ae68-cc5f-4219-94bb-e46bcd3311d9traits=$(openstack --os-placement-api-version 1.6 resource provider trait list -f value 8abb4b5e-0407-405d-97d1-7a03a9a06cbe | sed 's/^/--trait /') openstack --os-placement-api-version 1.6 resource provider trait set $traits --trait CUSTOM_LICENSED_WINDOWS 8abb4b5e-0407-405d-97d1-7a03a9a06cbe openstack --os-compute-api-version 2.53 aggregate set --property trait:CUSTOM_LICENSED_WINDOWS=required WindowsW1 openstack --os-compute-api-version 2.53 aggregate set --property trait:CUSTOM_LICENSED_WINDOWS=required WindowsW2 Flavor metadata trait:CUSTOM_LICENSED_WINDOWS with value required nova.exception.NoValidHost: No valid host was found. There are not enough hosts available. Got no allocation candidates from the Placement API.

1 0

#eventlet-removal Thank you for 2024
by Herve Beraud 18 Dec '24

18 Dec '24

You are no doubt aware that we are currently facing a real challenge. We are living in a complex situation where we have to engage resources to exit from a problematic technology, eventlet, without especially gaining new features. This migration, although without immediate direct functional value, represente for us a considerable investment in time and resources. But such context is not far different from the Python 2/Python 3 migration. Remember that era. The core Python maintainers found themselves in a difficult situation: continue to maintain their code on Python 2, which had become insecure and unsupported, or go through the effort of completely migrating their codebase and toolchain to Python 3. All the community had to make a choice. Third-party libraries, frameworks were also on the edge case, to be upgraded or replaced with Python 3 compatible equivalents. At the time of the decision, these efforts appeared to represent a "non-value-added burden". These efforts did not bring any new functionality, did not respond to any new customer need, and even slowed down other more innovative developments. The Python maintainers could have chosen the easy way. They could have chosen to continue to support Python 2 again for years, they could have chosen to live in statu-quo, but that's not what happened [1]. They chose to fight the problem and they chose to engage strong efforts in this migration. They ensured the security and the perenniality of the Python programming language. Once the migration was completed, the benefits quickly became apparent. The innovation cadence increased. The community united behind one uniq major version. Better performances. More innovations. And last but not the least, a simpler life for the distros maintainers and for end-users, and so a reinforced confidence in Python by our industry. Python is now the number 1 technology, leaving Java and C in the dust [2]. This is the lesson we must learn. Necessary actions without immediate direct functional value can ultimately hide treasures of innovation. Engagement and dedication is the key to a sustainable future. It guarantees the long-term viability of a project, reduces risks, and opens the way to faster and more peaceful innovation. Today, I can tell you that I'm proud that our community engaged the same way. I'm proud to see all the milestones we reached during this exciting year. I'm proud to observe so much engagement coming from every side, from everybody, and from all our companies. That's a strong signal of trust from our industry. Our companies support this initiative, our companies support open source, our companies invest in the future of OpenStack. On behalf of this community initiative, let me thank you very much for all your efforts and engagements in 2024. Let me wish you happy holidays and enjoy your loved ones. [1] https://devguide.python.org/versions/ [2] https://www.tiobe.com/tiobe-index/ -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/

1 0

[neutron] Hold the rechecks
by Yatin Karel 18 Dec '24

18 Dec '24

With the latest Ubuntu jammy kernel released, jobs running with openvswitch/linux bridge are impacted https://bugs.launchpad.net/neutron/+bug/2091990. Almost all branches are impacted, so hold any recheck until it's fixed. Other projects should also be seeing the issue when running such jobs. -- Thanks and Regards Yatin Karel

1 1

[qa] Team Organization Updates
by Martin Kopec 18 Dec '24

18 Dec '24

Hello everyone, I'm changing my work focus in the new year, therefore, I will have reduced bandwidth for QA and PTL duties for the rest of the Epoxy cycle. As a result, I'd like to announce a few changes: 1. Ghanshyam will take over moderating office hours starting in the new year. To better accommodate his timezone, the office hours will be held *bi-weekly on Wednesdays 18:00 UTC (even weeks).* The first office hour in the new year will be on *Wednesday January 8th*. 2. Ghanshyam will also act as PTL proxy for any emergencies, e.g. patches that require an approval asap. However, feel free to add me as a reviewer to patches that need a final review. 3. Luigi Toscano volunteered to help us with reviews, mainly with Tempest-related ones as he is a long-term contributor to cinder-tempest-plugin and several other projects - https://review.opendev.org/q/owner:ltoscano@redhat.com Thanks, -- Martin Kopec Red Hat EMEA IM: kopecmartin

1 0

[manila] Removal of the Standalone CephFS NFS protocol helper in Epoxy
by Ashley Rodriguez 18 Dec '24

18 Dec '24

Hi zorillas! As per subject line, we will be deprecating the standalone CephFS NFS protocol helper in this cycle. This is following our deprecation warning we put out in 2024.1 / Caracal [1] [2]. We've supported using a clustered Ceph NFS service since the Zed release. We've also added upgrade helpers to migrate from a standalone NFS-Ganesha service to the ceph-orch-deployed clustered NFS service; this code was backported to stable/2023.1 (Antelope). Although the upgrade path is disruptive, there is a UX improvement in Manila to ease this migration through surfacing “preferred” export paths. Moving forward, deployments must have “cephfs_nfs_cluster_id” in your configuration, otherwise the driver will fail to start. Manila will not make any export changes to NFS-Ganesha, so upgrading manila without an NFS cluster will mean that only the control plane is not going to work; but, data plane will remain unaffected. To assist migration, admins can also configure "cephfs_ganesha_export_ips" (or alternatively, "cephfs_ganesha_server_ip") alongside "cephfs_nfs_cluster_id". Setting these options will allow the CephFS driver to report additional export paths. These additional export paths will have the "preferred" metadata key set to False. Best, Manila team [1] https://review.opendev.org/c/openstack/manila/+/912648 [2] https://docs.openstack.org/manila/2024.2/configuration/shared-file-systems/…

1 0