November 2024 - openstack-discuss

[openstack-ansible] Victoria - enable neutron plugin Subnet_dns_publish_fixed_ip
by Rambo Rambo 11 Nov '24

11 Nov '24

Hi Team I am running openstack-ansible Victoria release and would need to activate automatic dns records creation when a new instance is created. So, I am looking for the way to enable neutron plugin Subnet_dns_publish_fixed_ip. After which I can enable dns_publish_fixed_ip in the subnet properties Regards Rambo

2 3

[telemetry] Event Pipeline Config and Use Cases
by Fernandes Figueiredo, Alex 11 Nov '24

11 Nov '24

Hello Openstack Telemetry Team, I'm currently working on re-enabling the Openstack Telemetry services for the StarlingX Openstack (STX-O) project. Openstack telemetry was integrated into STX-O long time ago, but it has been disabled for the past few years. Since the last time telemetry was used by STX-O, it seems that important updates happened, including: * Ceilometer API deprecation * Ceilometer Collector deprecation * Panko (event storage) deprecation My questions are mainly related to the last one (Panko deprecation): * Since Panko is deprecated and there is no actual replacement for event storage [1], is there any other possible telemetry use case to justify keeping the event pipeline enabled and generating data? * Are there any aodh alarming mechanisms that relies on events generated by Ceilometer event pipelines? If so, which "sinks.publishers" should be used to ensure the integration between the Ceilometer event pipeline and the aodh alarm service? * If event pipeline is enabled, what are the publishers currently supported for events? * The current event pipeline configuration (event_pipeline.yaml) in STX-O defines the "sinks.publishers" as "gnocchi://". However, based on Ceilometer doc, it looks like Gnocchi only supports samples/meters, it doesn't support events. Is my interpretation of the documentation correct or does Gnocchi support events and can be really used as a publisher for the event pipeline? [1] OpenInfra summit Vancouver 23 - Openstack Observability revamped<https://youtu.be/AhQJEBR5BUg?si=JbBuLG2iaaDZW7Iu&t=1590> Thank you in advance for any possible help! I'm looking forward to getting Openstack telemetry up and running on StarlingX Openstack. Best regards, Alex Figueirêdo.

3 4

[nova][neutron] Persistent PCI topology for network interfaces
by jan＠uponu.com 11 Nov '24

11 Nov '24

Hi, we have come came across the issue that some appliances rely on the PCI topology to assign network interfaces and not the mac address. This is the a problem, because the PCI topology changes, when an instance (the libvirt config) is recreated. Is there a way to make the network interface order persistent in the PCI topology and if not can someone give me a hint on the steps that would need to be done in nova? I think this could be an important feature in general. Thanks Jan ------ E-Mail: jan(a)uponu.com

2 1

[neutron] Bug deputy report (week starting on November 4)
by Elvira Garcia Ruiz 11 Nov '24

11 Nov '24

Hi folks! Here you have the list of bugs reported for Neutron during last week (04 Nov - 10 Nov) Many new RFEs this week. High ------ - https://bugs.launchpad.net/neutron/+bug/2086740 Deadlock when metadata agent starts Fix by Jakub https://review.opendev.org/c/openstack/neutron/+/934188 [Merged] - https://bugs.launchpad.net/neutron/+bug/2087824 random router related test failures since wsgi switch Unassigned Medium ----------- - https://bugs.launchpad.net/neutron/+bug/2087822 When security group rules have the same normalized CIDR, neutron-ovn-db-sync-util has a wrong log message. Unassigned - https://bugs.launchpad.net/neutron/+bug/2086787 Neutron fails with postgres on agents Unassigned Low ------ - https://bugs.launchpad.net/neutron/+bug/208678 ovn_db_revision_check is not required anymore Patch proposed by Sharat Sharma https://review.opendev.org/c/openstack/neutron/+/934241 Wishlist ---------- - https://bugs.launchpad.net/neutron/+bug/2086776 [RFE] Configurable Agent Termination on OVS Restart Unassigned - Reporter has updated the RFE description - https://bugs.launchpad.net/neutron/+bug/2086794 [RFE] L3 Agent Readiness Status for HA Routers Unassigned - https://bugs.launchpad.net/neutron/+bug/2086799 [RFE] OVS Agent Synchronization Status for Container Environments Unassigned - https://bugs.launchpad.net/neutron/+bug/2087541 [RFE] Add OVN Ganesha Agent to setup path for VM connectivity to NFS-Ganesha Assigned to Amir Nikpour Best regards, Elvira

1 0

[openstacksdk] Flakey unit test makes assumptions about the speed of API results
by Michael Still 08 Nov '24

08 Nov '24

So I've spent a day or so debugging an occasionally flakey unit test that I see in the py3 test suite for openstacksdk. I'm at the point that I want to check that I actually understand what it's doing before proposing a fix. Specifically, openstack.tests.unit.test_stats.TestStats.test_servers_no_detail periodically fails to find a statsd value: self.assert_reported_stat( 'openstack.api.compute.GET.servers.200', value='0', kind='ms' ) This assertion is effectively saying that a GET to the servers compute API should return a HTTP 200, and take 0 milliseconds to execute. The unit test is failing because sometimes it doesn't take 0 milliseconds. In my debugging for example, it takes 4 milliseconds in my environment every now and then: Considering key openstack.api.compute.GET.servers.200, value 4.000000|ms Value 4.000000, kind ms Value 0 != 4.000000 Am I understanding this correctly? It seems to me that perhaps we should be asserting the call took less than a threshold (5 milliseconds) instead of just insisting it always be instantaneous? Michael

1 0

[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