- openstack-discuss - lists.openstack.org

[OpenInfra Days NA] Recording/Slides from Workshop From zero to code
by Kaster, Jörn 12 Nov '24

12 Nov '24

Hello together, I have seen that on the OpenInfra Days NA there was a Session named 'From zero to code: A hands-on guide to making your first OpenStack code contribution' [1]. Unfortunately I can't attend the OpenInfraDays NA. Now the open question is the following: Is there any Recording/Slides or other Material available? Thank you for any information. Mit freundlichen Grüßen / Best Regards i.A. Jörn Kaster Cloud Platform Engineer Note: My work hours may not be your work hours. Please do not feel the need to respond during a time that is not convenient for you. EPG – Ehrhardt Partner Group [EPG_Logo_withClaim_rgb_transparent-background.png]<https://www.epg.com/de/> __________________________________________ EPX Ehrhardt + Partner Xtended GmbH Alte Römerstraße 3 56154 Boppard-Buchholz Germany Phone: (+49) 67 42 / 87 27 0 Fax: (+49) 67 42 / 87 27 50 E-Mail: info(a)epg.com Internet: www.epg.com __________________________________________ CEO: Marco Ehrhardt, Markus Derksen Commercial register Koblenz HRB 22546 Registered office: Boppard

1 0

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

12 Nov '24

Hello Stackers, This week is milestone-1 of the 2025.1 ("Epoxy") release cycle [1]. We've been hard at work implementing the action items from the recent Virtual Project Teams Gathering (PTG) [2]. This past week, we didn’t pursue any new governance changes, though several remain in draft as follow-ups from the PTG. We’re also excited about the extended deadline for the Call for Proposals for the OpenInfra Days event at SCaLE 2025. The new deadline is Nov 15, 2024 [3]. === Weekly Meeting === Last week, the Technical Committee met concurrently on video [4] and IRC [5]. Allison Price (aprice) and Jimmy McArthur (jimmymcarthur) from the OpenInfra VMware Migration Working Group [6] joined us to discuss the group's charter and activities so far. The working group’s goal is not only to address gaps and workarounds but also to influence the future development of OpenStack software. The group has published a whitepaper [7] for operators planning to migrate cloud workloads. The TC expressed interest in collaboration between the working group and the current maintainers of the VMware hypervisor driver in OpenStack Nova. We also highlighted low contributor numbers in several critical project teams mentioned in the whitepaper, including those maintaining OpenStack Compute High Availability (Masakari), OpenStack Storage Backup and Restore (Freezer), OpenStack Resource Optimization (Watcher), and OpenStack Database Service (Trove). The working group plans to hold regular meetings soon and will share details via this mailing list. The TC reviewed the maintenance status of the OpenStack documentation styling extension for Python Sphinx, openstackdocstheme. This library is outdated, as it depends on older versions, but there aren’t enough maintainers to review changes, which could impact documentation across all projects. Ideally, maintainers of this library should have expertise in Sphinx and JavaScript, making the TC a less-than-ideal group to support it. We encourage migrating documentation away from this custom tool, as Sphinx styling extensions have advanced and may now suffice without heavy customization. While there’s no immediate migration plan, we’re looking for volunteers to lead this effort. In the meantime, we’ll raise concerns with the Oslo project team about the lack of reviews for openstackdocstheme changes. The next meeting of the OpenStack Technical Committee is today (2024-11-12) on OFTC's #openstack-tc channel. You can find the agenda on the Meeting wiki [8]. I hope you'll be able to join us. === Governance Proposals === ==== Open for Review ==== Propose to select the eventlet-removal community goal | https://review.opendev.org/c/openstack/governance/+/931254 Add Cinder Huawei charm | https://review.opendev.org/c/openstack/governance/+/867588 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] Superuser compilation of PTG summaries: https://superuser.openinfra.dev/articles/october-2024-openinfra-ptg-summary/ [3] OpenInfra Days CFP: https://lists.openinfra.dev/archives/list/foundation@lists.openinfra.dev/me… [4] TC Meeting Video Recording, 2024-11-05: https://youtu.be/o_w3OutGEfM [5] TC Meeting IRC Log 2024-11-05: https://meetings.opendev.org/meetings/tc/2024/tc.2024-11-05-18.04.log.html [6] OpenStack VMware Migration Group: https://www.openstack.org/vmware-migration-to-openstack/ [7] VMware Migration to OpenStack White Paper: https://www.openstack.org/vmware-migration-to-openstack-white-paper [8] TC Meeting Agenda, 2024-11-12: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting

1 0

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

12 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 09 Nov '24

09 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 09 Nov '24

09 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 09 Nov '24

09 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