February 2024 - openstack-discuss

[neutron] bug deputy report for week of 2024-02-12
by Bence Romsics 19 Feb '24

19 Feb '24

Hi All, We had a handful of new bug reports last week: gate-failure: * https://bugs.launchpad.net/neutron/+bug/2052915 "neutron-ovs-grenade-multinode" and "neutron-ovn-grenade-multinode" failing in 2023.1 and Zed proposed fixes: https://review.opendev.org/q/topic:bug/2052915 * https://bugs.launchpad.net/neutron/+bug/2053227 [ovn-octavia-provider] ovn-octavia-provider-functional-master is broken by ovn build failure proposed fix: https://review.opendev.org/c/openstack/ovn-octavia-provider/+/909074 unassigned: * https://bugs.launchpad.net/neutron/+bug/2053274 [ovn] mtu for metadata veth interface is not set high: * https://bugs.launchpad.net/neutron/+bug/2052937 Policy: binding operations are prohibited for service role proposed fixes: https://review.opendev.org/q/topic:bug/2052937 * https://bugs.launchpad.net/neutron/+bug/2054203 Default flag change in netaddr breaks (at least) unit tests proposed fix: https://review.opendev.org/c/openstack/neutron/+/909317 rfe: * https://bugs.launchpad.net/neutron/+bug/2052906 [RFE] OpenVSwitch HTB QoS not efficient for a lot of interfaces Cheers, Bence

1 0

[Cinder] PTL non-candidacy
by Rajat Dhasmana 19 Feb '24

19 Feb '24

Hello everyone, I'm sending this email out to let everyone know that I will not be running for PTL for the Cinder project during the 2024.2 (Dalmatian) cycle. I started my PTL journey with the Zed cycle and it's been a great experience leading the Cinder project for 4 cycles. I think it is time for someone else to step up and bring their insights into the PTL tasks since I believe a new perspective will surely benefit the project. I would like to thank the Cinder team for their support, without which, it would have been a very hard task to accomplish. Last but not the least, Brian and Jay (former Cinder PTLs) helped out a lot to run things smoothly and in making complex decisions so a special thanks for all their help and support. Thanks Rajat Dhasmana

7 6

[all] Upcoming incompatible changes in netaddr 1.0.x
by Takashi Kajinami 17 Feb '24

17 Feb '24

Hello, While looking into some test failures in an attempt to bump netaddr from 0.10.x to 1.0.x[1], we learned that there are a few changes in netaddr 10.0.x impacting our current usage. I'll attempt to summarize a few important ones in this email, and would like to ask each team to look into your project to assess the impacts caused by these changes. 1. INET_PTON (more restrictive check by default) is used by default In 1.0.1, all features dependent on ip address parsing uses INET_PTON by default instead of INET_ATON. With this change a few "strange" address values such as '192.0' or even '1' is no longer accepted. In case you want to restore the previous behavior then you have to add flags=netaddr.core.INET_ATON to each call. See [2] for example. This is caught in neutron unit tests[4] but my need to be further check in libraries handling IP addresses. 2. valid_ipvN raises exception for non-string value. Previously netaddr.valid_ipv(4|6) returned False for non-string values such as None. This was (unintentionally) changed in 1.0.x. I proposed restoring the old behavior but the maintainer preferred strictness about the input type, and we eventually agreed on throwing more explicit exception (TypeError). At this moment this affects only manila unit tests which I'm fixing by [5], but I wonder if there is any specific use case in any project dependent on the previous behavior. If so then probably we can add our own logic to handle non-string value, for example in oslo_utils.netutils. 3. A few deprecated interfaces are removed. At this moment I'm aware of only impact on heat (caused by implicit_prefix removed), but double-check my be better. Thank you, Takashi [1] https://review.opendev.org/c/openstack/requirements/+/909300 [2] https://review.opendev.org/c/openstack/oslo.utils/+/909307 [3] https://github.com/netaddr/netaddr/issues/368 [4] https://bugs.launchpad.net/neutron/+bug/2054203 [5] https://review.opendev.org/c/openstack/manila/+/909298 -- Takashi Kajinami irc: tkajinam github: https://github.com/kajinamit launchpad: https://launchpad.net/~kajinamit

1 0

[kolla][rabbitmq]: Error when ensuring rabbitmq users exists
by Winicius Allan 17 Feb '24

17 Feb '24

Hello o/, After an upgrade of nodes packages, we have been facing a problem when reconfiguring RabbitMQ and Nova. In the tasks that ensures RabbitMQ users exists the output of task is: FAILED - RETRYING: [xxxx]: nova | Ensure RabbitMQ users exist (5 retries left). FAILED - RETRYING: [xxxx]: nova | Ensure RabbitMQ users exist (4 retries left). FAILED - RETRYING: [xxxx]: nova | Ensure RabbitMQ users exist (3 retries left). FAILED - RETRYING: [xxxx]: nova | Ensure RabbitMQ users exist (2 retries left). FAILED - RETRYING: [xxxx]: nova | Ensure RabbitMQ users exist (1 retries left). I've already tried to redeploy rabbit and reconfigure after that, but does not work neither Anyone can help? I'm unable to perform any operation in my environment. Thanks! Winicius.

3 6

How to enable or disable a hypervisor via openstack python module
by Saeed 16 Feb '24

16 Feb '24

Hello, I use this module to find if any hypervisors are disabled: https://github.com/openstack/openstacksdk I can find and see if any hypervisor is disabled and see the reason, but I didn't find any docs about how to enable (or even disable) a hypervisor. This is my code to find disabled hypervisors: import openstack > regions = ['region1', 'region2', 'region3'] > openstack.enable_logging(debug=False)disabled_hypervisors = [] > for region in regions: > conn = openstack.connect(cloud=region) # clouds.yaml > for server in conn.compute.hypervisors(details=True): > a = server.to_dict() > if a['status'] == 'disabled' and > a['service_details']['disabled_reason'] != None: > disabled_hypervisors.append({'name': a['name'], 'ip': > a['host_ip'], 'disabled_reason': a['service_details']['disabled_reason']}) Regards, Saeed

2 2

Subject: [tc][election] gouthamr's TC Candidacy for 2024.2
by Goutham Pacha Ravi 16 Feb '24

16 Feb '24

Hello Stackers, I'm expressing my interest to join the OpenStack Technical Committee with your acceptance. I have had a long and exciting stint with OpenStack; and can probably claim to have evolved along with it. I began my active contribution journey in the Liberty release, and have had the pleasure to build a community around the OpenStack Manila project for most of this time. In many ways, my efforts here were rooted in the core ideology of this community: the fervent desire for openness that drives each decision [1]. I coupled that with my own penchant for mentoring; the result of which is a vast number of new contributors in the form of Outreachy, Google Summer of Code, Grace Hopper Celebrations, and student projects with numerous universities. All of this was done with similarly motivated fellow conspirators. This experience has helped me foster the diversity of thought in our community, and provided sustained energy to a small group of people chopping wood and carrying water around software whose relevance transcends hype cycles. I now wish to employ this energy and experience in service as a member of the TC. I set out the following goals to drive within the team: * Sustain and improve collaboration: I wish to extend TC's charter on investment opportunities with the "formal" mentorship engagements we have had in the community, including but not limited to Outreachy, GSOC, GSOD, GHC and university projects. I've new ideas here, and feel like a TC member can add a ton of excitement to this niche area of people enthusiastic to do this year on year. * Commit to a closer collaboration with adjacent communities: I am inspired by our willingness to engage with maintainers of software that work with OpenStack. My pitch is for us to identify TC representation within projects like Ceph, Kubernetes and others for active and periodic communication. * Drive long running efforts to completion: prime examples here are efforts for coherence for operators and users: Unified CLI, Limits, and Secure RBAC defaults. Thank you for considering my candidacy. I look forward to the opportunity to serve our community and contribute to the continued success of OpenStack. Warm regards, Goutham Pacha Ravi (gouthamr) [1] https://openinfra.dev/four-opens/ [2] https://review.opendev.org/c/openstack/election/+/909239

1 0

[manila][ceph] Collab Review/design discussion for Cback Share Backup driver
by Goutham Pacha Ravi 16 Feb '24

16 Feb '24

Hello Zorillas and other interested stackers, Folks at CERN have been working with Manila's share backup feature and are authoring a new backup driver for CBack [1]. We are hosting a call to dive into the implementation and discuss how the feature works with CephFS shared file systems. If this is of interest to you, please join us on: Date: 22nd February 2024 Time: 1600 UTC Location: https://meetpad.opendev.org/manila-caracal-cback-driver Etherpad: https://etherpad.opendev.org/manila-caracal-cback-driver <https://meetpad.opendev.org/manila-caracal-cback-driver> [1] https://cds.cern.ch/record/2767135?ln=en Thanks, Goutham

1 0

[ironic] PTL non-candidacy
by Jay Faulkner 16 Feb '24

16 Feb '24

As I've mentioned in IRC, and various times throughout the cycle -- I do not intend to run for PTL of Ironic for Dalmation. I encourage Ironic contributors to run for PTL and will gladly offer any assistance to whomever is elected. Thanks, Jay Faulkner Ironic PTL

1 0

[release] Release countdown for week R-6, Feb 19-23
by Elõd Illés 16 Feb '24

16 Feb '24

Development Focus ----------------- Work on libraries should be wrapping up, in preparation for the various library-related deadlines coming up. Now is a good time to make decisions on deferring feature work to the next development cycle in order to be able to focus on finishing already-started feature work. General Information ------------------- We are now getting close to the end of the cycle, and will be gradually freezing feature work on the various deliverables that make up the OpenStack release. This coming week is the deadline for general libraries (except client libraries): their last feature release needs to happen before "Non-client library freeze" on February 22nd, 2024. Only bugfixes releases will be allowed beyond this point. When requesting those library releases, you can also include the stable/2024.1 branching request with the review (as an example, see the "branches" section here: https://opendev.org/openstack/releases/src/branch/master/deliverables/pike/… In the next weeks we will have deadlines for: * Client libraries (think python-*client libraries), which need to have their last feature release before "Client library freeze" (February 29th, 2024) * Deliverables following a cycle-with-rc model (that would be most services), which observe a Feature freeze on that same date, February 29th, 2024. Any feature addition beyond that date should be discussed on the mailing-list and get PTL approval. As we are getting to the point of creating stable/2024.1 branches, this would be a good point for teams to review membership in their $project-stable-maint groups. Once the stable/2024.1 branches are cut for a repo, the ability to approve any necessary backports into those branches for 2024.1 Caracal will be limited to the members of that stable team. If there are any questions about stable policy or stable team membership, please reach out in the #openstack-stable channel. Upcoming Deadlines & Dates -------------------------- Non-client library freeze: February 22nd, 2024 (R-6 week) Client library freeze: February 29th, 2024 (R-5 week) Caracal-3 milestone: February 29th, 2024 (R-5 week) Cycle Highlights Due: March 7th, 2024 (R-4 week) 2024.1 Caracal final release: April 3rd, 2024 Dalmatian PTG: April 8-12, 2024 Előd Illés irc: elodilles @ #openstack-release

1 0

[keystone] Reviewathon canceled
by Dave Wilde 16 Feb '24

16 Feb '24

I’m on PTO today and won’t be able to host the reviewathon so I’m cancelling it. Please reach out if you need anything. Thanks! /Dave

1 0