November 2024 - openstack-discuss

[neutron][ptg] 2025.1 Epoxy PTG summary
by Brian Haley 08 Nov '24

08 Nov '24

Hi all, First, sorry for taking so long to get this out, was traveling the week after the PTG. Second, thanks for all that attended the meetings, we had a good turnout for Neutron, the Ironic cross-team and some eventlet discussions that were important to the team. For complete notes see the etherpad [0] but a summary is below. And please comment if you feel I missed anything. Thank you, -Brian ### Dalmatian retrospective ### Everyone felt we were able to improve our CI stability, despite a few spikes during the cycle. We were also able to improve the OVN parity gap with ML2/OVS, and were able to move OVN to supporting WSGI (thanks Rodolfo!) Lack of developers and reviewers continues to be an issue, and we have struggled to reduce our bug backlog significantly. ### Eventlet deprecation ### We have started to identify and document changes needed to deprecate eventlet [1]. We will start creating bugs to track all this work. ### Spring cleanup ### At the beginning of every cycle, we always try and cleanup the code base, for example, removing deprecated and dead code, doc updates, job consolidation. We have made progress on those already. We had a discussion on two items that have been marked experimental in the code - Linuxbridge support and IPv6 prefix delegation - neither of which is well maintained or tested in our CI. I will send a follow-up on next steps for these in the coming week. ### Code base modernization ### As python 3.9 is now the minimal version, we are going through the steps of running pyupgrade/autopep8 on both the neutron and neutron-lib trees to adopt any new conventions. In the process we've been fixing a number of pylint warnings that is still ongoing. The mypy job is now voting, and we have started adding type hints to the code (thanks Ihar!). ### Ironic cross-project ### The high-level discussion point was on Neutron better supporting baremetal (of course). There are some issues with trunk ports as well as external network Single Source of Truth (to help better integrate Neutron with DC networking). An RFE will be proposed for either creating a pre-commit hook to help validate a VNI is okay to use, or to be able to modify the VNI range via the API, as it is currently fixed in the conf file. The other topic was around implementing an additional DHCP backend, as dnsmasq has not been actively maintained, and there was at least one issue Ironic was seeing with it crashing. The consensus was to start supporting Kea, an RFE will be created. See etherpad for further information. ### ML2/OVS future ### As two of the major distros have moved to make OVN their default, there has been less of an emphasis on ML2/OVS development over the past few cycles, and as such, there are an increasing number of bugs in the backlog. There are still a large number of clouds running ML2/OVS as seen in the 2024 User Survey [2], so there is some risk there. As a team we wanted to make sure we communicated this concern, and also wanted to make it known that users doing new deployments, or migrating from older ones (eg Linuxbridge) strongly consider using OVN. We will attempt to give any help we can in this area as migration and deployment issues arise. ### Distributed metadata ### This has been ongoing work from Liu to better support distributed metadata in ML2/OVS, similar to what is done in OVN. Patches have been updated accordingly after discussion. ### Performance/scale testing ### Some recent bugs have shown there are some places where Neutron has DB scaling issues. Any we've found so far have been fixed, but there is a need to do some targeted testing to see if there are others. We also discussed changing our rally testing to try and better detect such issues. My take away was we should be vigilant when any DB change is proposed to make sure it doesn't regress things, and to start looking at places we don't use 'selectin' to see if a simple change would help. ### Gate stability ### Similar to the weekly Neutron CI meeting, we discusses issues in the gate, from things related to the WSGI switch, scenario and fullstack failures. Please see the etherpad for specific bug links. ### RFE discussions ### On-demand topic to discuss any in-progress or proposed RFE changes, please see etherpad for more information. [0] https://etherpad.opendev.org/p/oct2024-ptg-neutron [1] https://etherpad.opendev.org/p/neutron-eventlet-deprecation [2] https://www.openstack.org/analytics

1 0

[ironic/neutron] Using neutron to bind a specific port on an ironic node
by Michael Sherman 08 Nov '24

08 Nov '24

So, my question is: Is there a way for an end-user, launching an instance with nova, to specify which ironic port neutron should use? For context, a subset of our ironic nodes have relatively heterogenous network interfaces, but are configured as being attached to the same physical networks. Examples include nodes with both Broadcom and Mellanox 25g interfaces attached to the same switch, but also nodes with both 1g, 25g, and 100g NICs attached to different switches, but with the same vlans available. In our configuration we’re using Neutron with openvswitch, networking-baremetal, and networking-generic-switch. From initial observations, it seems like if we *don’t* specify, neutron allocates ports in the same order that they’re returned from “baremetal port list”. What we’d like to be able to do is let our users send some API call to bind neutron port X based on some property of the ironic port, ether UUID, tags for speed or vendor, or something else we’re able to define, but it’s not clear to me what information is even available to neutron to use in say, a binding profile? Any pointers would be appreciated. Thanks! -Mike Sherman

1 0

[release] Release countdown for week R-20
by Thierry Carrez 08 Nov '24

08 Nov '24

Development Focus ----------------- The Epoxy-1 milestone is next week, on November 14th! Project team plans for the 2025.1 Epoxy cycle should now be solidified. General Information ------------------- Libraries need to be released at least once per milestone period. Next week, the release team will propose releases for any library which had changes but has not been otherwise released since the 2024.2 Dalmatian release. PTL's or release liaisons, please watch for these and give a +1 to acknowledge them. If there is some reason to hold off on a release, let us know that as well, by posting a -1. If we do not hear anything at all by the end of the week, we will assume things are OK to proceed. NB: If one of your libraries is still releasing 0.x versions, start thinking about when it will be appropriate to do a 1.0 version. The version number does signal the state, real or perceived, of the library, so we strongly encourage going to a full major version once things are in a good and usable state. Upcoming Deadlines & Dates -------------------------- Epoxy-1 milestone: November 14th, 2024 2025.1 Epoxy final release: April 2nd, 2025 -- Thierry Carrez (ttx)

1 0

[kolla][OSA][release] 2024.2 Dalmatian cycle-trailing release deadline
by Elõd Illés 08 Nov '24

08 Nov '24

Hello teams with deliverables following the cycle-trailing release model! This is just a reminder to wrap up your trailing deliverables for 2024.2 Dalmatian. The release deadline is *December 5th, 2024.* [1]. If things are ready sooner than that though, all the better for our downstream consumers. Some of them have been delivered already, so let's list here the ones that still need a release before the deadline: kayobe openstack-ansible-roles openstack-ansible [1] https://releases.openstack.org/epoxy/schedule.html#e-cycle-trail Thanks in advance, Előd Illés irc: elodilles @ #openstack-release

1 0

[all] CFP for OpenInfra Days North America Open for One More week!
by Jeremy Stanley 07 Nov '24

07 Nov '24

For those of you who may not be subscribed to the OpenInfra Foundation mailing list[*], just a heads up that we have another week until the OpenInfra Days North America planning committee will begin reviewing talks, so the CFP deadline has been extended to November 15. If you want to present in Pasadena, California this March, get your proposal in ASAP![**] [*] https://lists.openinfra.dev/archives/list/foundation@lists.openinfra.dev/me… [**] https://forms.gle/81QV3SFV6ixSdsBq8 -- Jeremy Stanley

1 0

[neutron] Drivers meeting canceled Friday, November 8th
by Brian Haley 07 Nov '24

07 Nov '24

Hello Neutrinos: I'm going to cancel tomorrow's drivers meeting as there is no agenda and I will be offline. I will triage incoming ones next week so plan to meet next Friday. Have a nice weekend! -Brian

1 0

[Cinder][Ceph] Volumetria errada no cluster ceph
by lfsilva＠binario.cloud 07 Nov '24

07 Nov '24

Hello, I'm experiencing an issue with the volume usage of the Ceph cluster, which is currently used in OpenStack for volumes. I am working with Ceph version Octopus (15.2.17). When I run the ceph df command, I get this output: --- RAW STORAGE --- CLASS SIZE AVAIL USED RAW USED %RAW USED hdd 120 TiB 33 TiB 87 TiB 87 TiB 72.72 TOTAL 120 TiB 33 TiB 87 TiB 87 TiB 72.72 --- POOLS --- POOL ID PGS STORED OBJECTS USED %USED MAX AVAIL device_health_metrics 1 32 69 MiB 101 137 MiB 0 11 TiB images 2 256 1.3 TiB 166.90k 2.5 TiB 10.72 11 TiB vms 3 64 574 KiB 21 2.5 MiB 0 11 TiB volumes 4 2048 41 TiB 3.94M 82 TiB 79.42 11 TiB backups 5 1024 407 GiB 111.85k 818 GiB 3.63 11 TiB And when I run the rbd du -p volumes command, I get this total: NAME PROVISIONED USED <TOTAL> 14 TiB 8.3 TiB This "volumes" pool is currently set to replica 2, and mirroring is not enabled. I have checked for any locked or deleted snapshots but found none. I also ran a ceph osd pool deep-scrub volumes, but it didn't resolve the issue. Has anyone encountered this problem before? Could someone provide assistance?

3 21

[kolla] Vacation - kevko
by Michal Arbet 07 Nov '24

07 Nov '24

Hello, I would like to inform you that I will be on vacation from November 7th, 2024, to November 23rd, 2024. Thank you, Michal Arbet Michal Arbet Openstack Engineer Ultimum Technologies a.s. Na Poříčí 1047/26, 11000 Praha 1 Czech Republic +420 604 228 897 michal.arbet(a)ultimum.io *https://ultimum.io <https://ultimum.io/>* LinkedIn <https://www.linkedin.com/company/ultimum-technologies> | Twitter <https://twitter.com/ultimumtech> | Facebook <https://www.facebook.com/ultimumtechnologies/timeline>

1 0

Pointers to FOSDEM devrooms CfPs
by Felix Kronlage-Dammers 07 Nov '24

07 Nov '24

Hi, in the last couple weeks the Call for Participations for the various FOSDEM[1] devrooms have been published. In case not everyone knows FOSDEM: FOSDEM is _the_ yearly European free and open source software event where people from around the globe meet and discuss. Aside from the main track FOSDEM consists mainly of many devrooms which focus on certain topics. I wanted to quickly highlight a few of the relevant devrooms for the OpenStack audience and would like to encourage to submit talks :) An overview of the devrooms can be seen here: https://fosdem.org/2025/schedule/ The CfP for the room is linked from the details page of each devroom. Virtualization and Cloud Infrastructure: https://lists.fosdem.org/pipermail/fosdem/2024q4/003574.html Confidential Computing: https://falder.org/fosdem25-cfp Software Defined Storage: https://lists.fosdem.org/pipermail/fosdem/2024q4/003563.html Monitoring and Observability: https://docs.google.com/document/d/1KQmNqzN3cO29ZZUSpd83REvJY_QhbvxIYr4IRBr… The SCS projects organizes, together with the german ZenDiS and the french DINUM, a room with the topic ‘Government Collaboration’. As part of the room we would love to receive proposals that cover: - Standardization and certification of digital sovereign solutions and infrastructure - Automating deployment and operations of such solutions on sovereign infrastructure - Examples and success stories of digital sovereign cloud computing by the public sector The CfP for this room is here: https://lists.fosdem.org/pipermail/fosdem/2024q4/003608.html Am sure there are more relevant devrooms :) An easy overview is also the mailing list archive: https://lists.fosdem.org/pipermail/fosdem/2024q4/thread.html regards felix [1] <url: https://fosdem.org/2025/>

1 0

Question about Package Inclusion and User Creation in Kolla Base Image
by Amir Hossein Ahmadi 06 Nov '24

06 Nov '24

Hello OpenStack Community, I'm currently reading through the OpenStack Kolla source code, and I noticed a few design choices in the kolla/base image that I’d like to understand better: - The kolla/base image includes a number of packages (such as Apache) that don’t appear to be necessary for most containers. - Additionally, user and group accounts for all services are created in the base image, even though they aren’t used by all containers. Could someone explain the reasoning behind including these components in the base image? Is there any documentation available that provides insight into the design approach for Kolla images? Thank you in advance for your help and guidance. Best regards, Amir Hossein, Burna innovation Bridge

1 0