December 2024 - openstack-discuss

[neutron] Bug deputy Dec 16 - Dec 22
by Rodolfo Alonso Hernandez 23 Dec '24

23 Dec '24

Hello Neutrinos: This is the bug list from last week: HIGH * api slow due to missing LRP index ( https://bugs.launchpad.net/neutron/+bug/2092133) Assigned and patch proposed: https://review.opendev.org/c/openstack/ovsdbapp/+/938004 MEDIUM * [RFE] OVN: allow to configure activation-strategy (change it to a different strategy from rarp; or disable completely) ( https://bugs.launchpad.net/neutron/+bug/2092250) Assigned and patch proposed: https://review.opendev.org/c/openstack/neutron/+/938106 LOW * [OVN] Migrate the OVN L3 scheduler to use HA_Chassis_Group ( https://bugs.launchpad.net/neutron/+bug/2092271) Assigned. * Deprecate and remove vlan_transparent config option ( https://bugs.launchpad.net/neutron/+bug/2092174) *NOT ASSIGNED*. Regards.

1 0

[freezer][freezer-dr] Proposal to retire Freezer DR project
by Dmitriy Rabotyagov 23 Dec '24

23 Dec '24

Hi folks, As an ongoing effort to return Freezer project back to the list of Active projects and recovering gate health for repositories owned by Freezer, I've come across freezer-dr[1] Freezer DR is a separate from freezer/freezer-api instance-ha project which is highly pluggable by design with the main goal to evacuate instances from the compute node once service detects that the serving compute node is down. And that is what is currently achieved by the Masakari project. While pluggable design for the service, can be treated as a good benefit in favor of it. Another relatively valuable benefit of freezer-dr, is that it uses nova service state to detect if the compute is down, rather then require 3rd party cluster tooling to independently evaluate hypervisor health. Regardless, I don't see enough value to keep maintenance of that project and instead it's better to keep focus on Masakari maintenance/development instead. With that being said, I suggest the retirement of the freezer-dr project. If someone feels in favor of keeping maintenance of a separate project for instance evacuation - please feel free to reply in thread until December 10, 2024. After that date I will initiate the project retirement process. [1] https://opendev.org/openstack/freezer-dr

2 2

[magnum][cluster api] Heads-up - Octavia OVN driver and latest CAPO
by Stig Telfer 20 Dec '24

20 Dec '24

Hi Magnum folks - Heads up - we wanted to make people aware of a recent upstream CAPO change that could break your Magnum setup if using Cluster API and the Octavia OVN driver. What we've seen is that a recent contribution to CAPO tightens the security group rules for NodePorts to the local tenant network. This works fine for Octavia's Amphora driver, in which HAproxy becomes the source for all back-end API requests. The Octavia OVN driver doesn't have that behaviour, which results in inbound requests getting filtered. The CAPO release is v0.11.0 (https://github.com/kubernetes-sigs/cluster-api-provider-openstack/releases/…) The issue is described here: https://github.com/kubernetes-sigs/cluster-api-provider-openstack/issues/23… The Magnum drivers will pin CAPO driver versions so it's more of a developer / power-user concern than for conventional operators. Cheers, Stig

1 0

[masakari] is this project still active and can be used in production environment
by luckydog xf 20 Dec '24

20 Dec '24

Hi, list, I saw this project hasn't been active for months. So I'm wondering if it is still actively developed and can it be used in production? Are there any use cases ? Thanks.

4 8

Openstack ansible Upgrades
by engineer2024 20 Dec '24

20 Dec '24

Is it possible to upgrade openstack ansible from one major release to another, along with the os distribution upgrade all in one flow ? I mean, as of now we are doing the upgrade as two step process. first we are upgrading the os of the hosts and then the os of the lxc containers and then re running the existing openstack version playbooks. Next , we are upgrading to major release of OSA. This two step process is doubling our effort and time to upgrade to a major version. Is it possible to download and run the major release playbooks soon after the os upgrades ? instead of rerunning the existing playbook again and then download and running next version playbooks ?

2 1

[openstack][magnum] user who created cluster was deleted from keystone
by Nguyễn Hữu Khôi 19 Dec '24

19 Dec '24

Hello. I have a case: What will we do if the user who created the cluster was deleted from the keystone? In this case, we cannot add or remove node groups or use autoscale and autoheal. I tried to create a new application credential and patch my cluster. Then I can add or remove node groups but new node groups cannot join the cluster(nodes not ready) Thank you. Regards Nguyen Huu Khoi

2 2

[cinder] Next 2 Meetings cancelled
by Jon Bernard 19 Dec '24

19 Dec '24

Hello all, the next two weekly meetings (Dec. 25 and Jan 1) are cancelled for the holidays. I hope everyone has a nice break! Catch you at the Jan 8. meeting. Take care, -- Jon

1 0

[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 18 Dec '24

18 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 18 Dec '24

18 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 17 Dec '24

17 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

[tc][all] No weekly meetings over the holidays (2024-12-24 and 2024-12-31)
by Goutham Pacha Ravi 17 Dec '24

17 Dec '24

Hello Stackers, As we approach the end-of-the-year holidays, please note that the OpenStack Technical Committee weekly meetings [1] previously scheduled for 2024-12-24 and 2024-12-31 are cancelled. We will resume our weekly meetings on 2025-01-07, and I will share the agenda closer to that date. Wishing everyone a happy and restful holiday season! Thank you, Goutham Pacha Ravi (gouthamr) OpenStack TC Chair [1] https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee

1 0

[openstack-ansible] Weekly meetings on Dec 24 and Dec 31 cancelled
by Dmitriy Rabotyagov 17 Dec '24

17 Dec '24

Hi, Last week we decided to cancel the weekly meetings on December 24 and December 31 2024 due to Christmas holidays as many people will not be around for the meeting. This means that the next meeting will happen only on January 7 2025. With that being said, I want to congratulate the community with the upcoming Christmas and New Year and wish to have plenty of fun during holidays! And thank for all the hard work that was put in during 2024.

1 0

[neutron] End of year meeting schedule
by Brian Haley 17 Dec '24

17 Dec '24

Hello Neutrinos: Just wanted to make sure everyone was aware of our meeting schedule for the rest of the year. As discussed in our meeting Tuesday, next week will be the last week of meetings for the year, specifically: December 13th - Drivers meeting cancelled December 16th - Neutron CI meeting December 17th - Neutron meeting December 20th - Drivers meeting cancelled December 23rd - Neutron CI meeting (?) will leave up to Yatin Meetings the week of December 23rd and December 30th are cancelled, starting up again the week of January 6th. As usual, reach out on IRC/gerrit/email with questions for me or the core team, but assume a potentially slow turn-around. I will be offline from December 19th to January 8th, checking-in occasionally to make sure there are no fires, Miguel has offered to lead the team meeting on January 7th in my absence (thanks Miguel!). -Brian, Neutron PTL

2 2

Vault cannot authorize approle
by Andy Speagle 17 Dec '24

17 Dec '24

Hey Team, I'm working with charmed openstack and it looks like I let my certs expire stupidly... and now I'm seeing this from vault: Vault cannot authorize approle Further info from the logs indicate this: unit-vault-0: 08:42:04 WARNING unit.vault/0.juju-log InternalServerError: Unable to authorize approle. This may indicate failure to communicate with the database unit-vault-0: 08:42:04 ERROR unit.vault/0.juju-log Traceback (most recent call last): File "/var/lib/juju/agents/unit-vault- 0/charm/reactive/vault_handlers.py", line 896, in client_approle_authorized vault.get_local_client() File "/var/lib/juju/agents/unit-vault-0/.venv/lib/python3.10/site- packages/tenacity/__init__.py", line 339, in wrapped_f return self(f, *args, **kw) File "/var/lib/juju/agents/unit-vault-0/.venv/lib/python3.10/site- packages/tenacity/__init__.py", line 430, in __call__ do = self.iter(retry_state=retry_state) File "/var/lib/juju/agents/unit-vault-0/.venv/lib/python3.10/site- packages/tenacity/__init__.py", line 378, in iter raise retry_exc.reraise() File "/var/lib/juju/agents/unit-vault-0/.venv/lib/python3.10/site- packages/tenacity/__init__.py", line 206, in reraise raise self.last_attempt.result() File "/usr/lib/python3.10/concurrent/futures/_base.py", line 451, in result return self.__get_result() File "/usr/lib/python3.10/concurrent/futures/_base.py", line 403, in __get_result raise self._exception File "/var/lib/juju/agents/unit-vault-0/.venv/lib/python3.10/site- packages/tenacity/__init__.py", line 433, in __call__ result = fn(*args, **kwargs) File "/var/lib/juju/agents/unit-vault-0/charm/lib/charm/vault.py", line 258, in get_local_client client.auth_approle(app_role_id) File "/var/lib/juju/agents/unit-vault-0/.venv/lib/python3.10/site- packages/hvac/v1/__init__.py", line 2072, in auth_approle return self.auth('/v1/auth/{0}/login'.format(mount_point), json=params, use_token=use_token) File "/var/lib/juju/agents/unit-vault-0/.venv/lib/python3.10/site- packages/hvac/v1/__init__.py", line 1726, in auth return self._adapter.auth( File "/var/lib/juju/agents/unit-vault-0/.venv/lib/python3.10/site- packages/hvac/adapters.py", line 159, in auth response = self.post(url, **kwargs).json() File "/var/lib/juju/agents/unit-vault-0/.venv/lib/python3.10/site- packages/hvac/adapters.py", line 103, in post return self.request('post', url, **kwargs) File "/var/lib/juju/agents/unit-vault-0/.venv/lib/python3.10/site- packages/hvac/adapters.py", line 233, in request utils.raise_for_error(response.status_code, text, errors=errors) File "/var/lib/juju/agents/unit-vault-0/.venv/lib/python3.10/site- packages/hvac/utils.py", line 39, in raise_for_error raise exceptions.InternalServerError(message, errors=errors) hvac.exceptions.InternalServerError: internal error The database seems to be up and accessible... so, I gotta believe it's a cert issue... so, I feel like this might be a chicken-egg issue where it can't connect to the DB due to certs... but then can't issue certs because it can't connect to the DB. Any thoughts? ----- Andy Speagle

2 4

[neutron] bug deputy report for week of 2024-12-09+
by Ihar Hrachyshka 16 Dec '24

16 Dec '24

Hi all, Bugs ------- Gate issues ========= 1. fullstack failures in l3ha agent, placeholder: https://bugs.launchpad.net/neutron/+bug/2091351 May be related to https://bugs.launchpad.net/neutron/+bug/2083609 There's a fix for the latter: https://review.opendev.org/c/openstack/neutron/+/937758 2. functional suite OOMing when CPU number is low: https://bugs.launchpad.net/neutron/+bug/2091855 There's a fix to split the suite in serial runs: https://review.opendev.org/c/openstack/neutron/+/937759 The bug alludes that memory consumption could be improved; I'd recommend to limit the scope of this bug to fixing the CI failure and let the memory concerns be addressed elsewhere / by another owner if needed. 3. tempest failure in stable branch in psql job: https://bugs.launchpad.net/neutron/+bug/2091711 No fix; no owner. API / policy ========= All assigned to Slawek; not sure if he really wants to own all of them. 1. no quota on the number of tags breaks api: https://bugs.launchpad.net/neutron/+bug/2091410 DoS when too many tags are created; CVE adjacent. Need quotas for tags? 2. policy mechanism allows to work around some limitations on external connectivity when fwaas is used: https://bugs.launchpad.net/neutron/+bug/2091536 Not sure if it has a security angle or affects anything but fwaas. 3. custom policy rule failing due to missing fields: https://bugs.launchpad.net/neutron/+bug/2091493 Needs owner ========== 1. Unicast leakage on flat network: https://bugs.launchpad.net/neutron/+bug/2091211 The next step would be to set up a 2-compute devenv setup with flat and see if ml2/ovs openvswitch driver can reproduce. Additional tests to functional / fullstack / tempest validating leakage is not happening could be helpful too. Already fixed ========== 1. 500 when backend doesn't support vlan-transparent: https://bugs.launchpad.net/neutron/+bug/2091613 2. pylint change broke ovn agent delete: https://bugs.launchpad.net/neutron/+bug/2091071 New RFEs -------------- 1. use unicast mode for keepalived to avoid vxlan flooding when mcast is off: https://bugs.launchpad.net/neutron/+bug/2091599 Ihar

1 0

[Neutron] DHCP port status inactive
by Vinicius Afonso 16 Dec '24

16 Dec '24

Hello, I am new to Openstack environment and I need help with a Neutron problem. When I create a new network, the DHCP port launches with status inactive. Even though I tried to create a VM, the DHCP generate a port for the machine, However it takes a few minutes to give an error: "Build of instance ed6c8835-f2d4-4730-9638-74ded388361b aborted: Failed to allocate the network(s), not rescheduling." The only alternative solution to overcome this issue is to change the DHCP agent of the network. If I change it, the new DHCP port will have an active status and then I can launch a VM. Nothing conclusive was found in the logs, just the error to bind the port. It doesn't say anything to why the port is inactive, just that the port was created and with status active. Things that I already tried: -> See nova and neutron logs -> Restart neutron-server, neutron-dhcp-agent, neutron-openvswitch-agent -> Change manually the DHCP agent Anyone had the same problem as this one? Any tips to troubleshoot? Any help is welcome! Thanks.

2 1

Dalmatian: Dimensions of instance console
by berndbausch＠gmail.com 15 Dec '24

15 Dec '24

This is a Dalmatian-based Devstack. The instance console's height is too large for my screen. Documentation claims that console dimensions can be configured in a file named _detail_vnc.html [1], but there is no file with this name anywhere in the filesystem. I just submitted a bug [2] but wonder if somebody can help me out right now. How can the console dimensions be configured? Thanks! Bernd Bausch Instructor and tinkerer Here is my bug description: Under Frequently Asked Questions (https://docs.openstack.org/nova/2024.2/admin/remote-console-access.html#fre quently-asked-questions), the answer to Q: How do I adjust the dimensions of the VNC window image in the OpenStack dashboard? is incorrect. My Devstack installation contains no file named _detail_vnc.html. I found a file with the interesting name _detail_console.html under /opt/stack/horizon/openstack_dashboard/dashboards/project/instances/template s/instances, but it doesn't contain the answer's code for width and height. [1] https://docs.openstack.org/nova/2024.2/admin/remote-console-access.html#freq uently-asked-questions [2] https://docs.openstack.org/nova/2024.2/admin/remote-console-access.html#freq uently-asked-questions

1 0

[publiccloud-sig] Reminder: next meeting December 18th - 0800 UTC
by Felix Kronlage-Dammers 15 Dec '24

15 Dec '24

Hi everyone, This upcoming Wednesday (December 18th) the next meeting of the publiccloud-sig is going to happen. We’ll be meeting at 0800 UTC here: https://meetpad.opendev.org/publiccloud-sig <https://meetpad.opendev.org/publiccloud-sig> See also here for all other details: https://wiki.openstack.org/wiki/PublicCloudSIG <https://wiki.openstack.org/wiki/PublicCloudSIG> See ya in our pre-christmas special edition of the public cloud SIG :) felix -- Felix Kronlage-Dammers Sovereign Cloud Stack — standardized, built and operated by many Ein Projekt der Open Source Business Alliance - Bundesverband für digitale Souveränität e.V. Tel.: +49-30-206539-205 | Matrix: @fkronlage:matrix.org | fkr(a)osb-alliance.com

1 0

[tc][all] OpenStack Technical Committee Weekly Summary and Meeting Agenda (2025.1/R-15)
by Goutham Pacha Ravi 15 Dec '24

15 Dec '24

Hello Stackers, We're 15 weeks away from the 2025.1 ("Epoxy") release date (2024-04-02) [1]. During the last week, the Technical Committee continued discussing the state of "unmaintained" code branches across OpenStack repositories and election officials proposed dates for the combined TC+PTL elections for the next release cycle [2]. We have decided to cancel the weekly meetings previously scheduled for 24th December and 31st December in lieu of the holidays. === Weekly Meeting === The OpenStack Technical Committee met over IRC on 2024-12-10 [3]. We revisited challenges with using CentOS 10 in the community CI system due to lack of AVX/AVX2 CPU flags on current cloud providers. Discussions revolved around finding providers with suitable hardware or reducing reliance on CentOS testing. We then revisited the state of "unmaintained" branches across OpenStack repositories. The oldest "unmaintained" branch tracks the "victoria" release (GA: 2020-10-14). The consensus amongst TC members was to enforce the policy to default old branches to EOL unless explicitly opted-in with required maintenance assurances. To do this, we need tooling to automate the transition, and a way to track and validate volunteer opt-ins for unmaintained branches. Volunteers stepped up to transition branches up until the 2023.1 ("Antelope") release to "end-of-life", beginning with the Victoria release branch [4]. If you're interested in keeping a particular branch open, for any repository, please express your interest directly on the gerrit change. All EOL transition patches will be merged after 1 month of community review. The next meeting of the OpenStack Technical Committee is on 2024-12-17 at 1800 UTC. This meeting will take place in the #openstack-tc channel on OFTC's IRC server. Please find the meeting agenda on the wiki [5]. Please remember that you can propose topics for upcoming TC meetings by directly editing the wiki. If you're unable to do so, please holler at me (IRC nick: gouthamr) or in the TC's IRC channel (#openstack-tc). === Governance Proposals === ==== Merged ==== - Retire Murano/Senlin/Sahara OpenStack-Ansible roles | https://review.opendev.org/c/openstack/governance/+/935677 ==== Open for Review ==== - Add ansible-role-httpd repo to OSA-owned projects | https://review.opendev.org/c/openstack/governance/+/935694 - Rework the initial goal proposal as suggested by people | https://review.opendev.org/c/openstack/governance/+/931254 - Resolve to adhere to non-biased language | https://review.opendev.org/c/openstack/governance/+/934907 - Propose to select the eventlet-removal community goal | https://review.opendev.org/c/openstack/governance/+/934936 - Allow more than 2 weeks for elections | https://review.opendev.org/c/openstack/governance/+/937741 === How to Contact the TC === You can reach the TC in several ways: - Email: send an email with the tag [tc] on this mailing list. - IRC: Ping us using the tc-members keyword on the #openstack-tc IRC channel on OFTC. - Weekly Meeting: The Technical Committee meets every week on Tuesdays at 1800 UTC [5]. Thank you very much for reading! On behalf of the OpenStack TC, Goutham Pacha Ravi (gouthamr) OpenStack TC Chair [1] 2025.1 "Epoxy" Release Schedule: https://releases.openstack.org/epoxy/schedule.html [2] 2025.2/"F" elections proposal: https://review.opendev.org/c/openstack/election/+/937408 [3] TC Meeting IRC Log 2024-12-10: https://meetings.opendev.org/meetings/tc/2024/tc.2024-12-10-18.01.log.html [4] Transition unmaintained/victoria to EOL: https://review.opendev.org/c/openstack/releases/+/937515 [5] TC Meeting Agenda, 2024-12-17: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting

1 0