Search results for "#eventlet-removal" - openstack-discuss

[neutron] Bug Deputy Jul 14 - Jul 28

by Jakub Libosvar

Hi, as I didn’t find the bug deputy report from the last week and confirmed by looking at the IRC meeting logs, I’ve skimmed through the bugs of the last 2 weeks to make sure nothing falls through the cracks. There are a few incomplete bugs that require more info from the reporters in order to find the culprit, seems Brian and Rodolof are on top of it. There is one Critical from today and seems it’s clear what is wrong with it and it seems Yatin is looking at it. Thanks Kuba Critical -------- * tobiko jobs failing while download fedora qcow2 image Edit https://bugs.launchpad.net/neutron/+bug/2118902 Yatin seems to be looking into it Fedora 40 image URL has moved, we need to update the URL to fetch Fedora 41 High —--- * test_subport_delete random failure https://bugs.launchpad.net/neutron/+bug/2117405 Functional test that fails sporadically Assigned to Rodolfo * [tobiko] OVN Metadata agent class failing when using OVN agent https://bugs.launchpad.net/neutron/+bug/2118398 Assigned to Rodolfo Patch proposed: https://review.opendev.org/c/x/tobiko/+/955769 * OVN Neutron agent is being registered as OVN Metadata agent https://bugs.launchpad.net/neutron/+bug/2118876 Rodolfo and Yatin are working on it Patch proposed: https://review.opendev.org/c/openstack/neutron/+/955987 Medium ------- * Horizon shows all prefix lengths when creating subnet from subnet pool https://bugs.launchpad.net/neutron/+bug/2116927 Lajos looked at it as it might be related to the SDK migration, unclear if any fix in Neutron is required * [eventlet-removal] Add N535 hacking check to ban eventlet imports https://bugs.launchpad.net/neutron/+bug/2117373 This is to add the check into Neutron tree but later the check itself was questioned as it might be not working as intended * [neutron-tempest-plugin] Test ``test_create_router_update_external_gateways`` failing https://bugs.launchpad.net/neutron/+bug/2117383 Assigned to Miguel * [unmaintained-only] unknown keyword flow_group_id https://bugs.launchpad.net/neutron/+bug/2117477 Assigned to Bence * [OVN] OVN agents should clean up "Chassis_Private" previous tags https://bugs.launchpad.net/neutron/+bug/2118893 Assigned to Rodolfo Patch proposed: https://review.opendev.org/c/openstack/neutron/+/955998 Low —-- * NotFoundException: 404 error when associating FIP with an unreachable network https://bugs.launchpad.net/neutron/+bug/2118360 Incomplete ---------- * VPN Perfect Forward Secrecy (PFS) is deactivated although configured as active https://bugs.launchpad.net/neutron/+bug/2116723 Rodolfo asked the reporter for more details * Performance Tuning for Nested VXLAN Tunnel in OpenStack (OVS Backend) https://bugs.launchpad.net/neutron/+bug/2116837 Brian asked the reporter for more details * OVN: Intermittent metadata failures for SR-IOV VMs https://bugs.launchpad.net/neutron/+bug/2117078 Rodolfo asked the reporter for more details, the root cause is still unknown * neutron-openvswitch-agent crashes on start https://bugs.launchpad.net/neutron/+bug/2117153 Brian asked the reporter for more details, the root cause is still unknown, happened just once

1 week, 6 days

[magnum] April vPTG summary and Magnum meeting time change

by Dale Smith

Hello all, I wanted to post a short summary to this list of the vPTG[1] the Magnum team held on April 8th and 9th 2025. These are the topics and a summary of my notes from the discussions. If I missed key details please add these to the etherpad and/or reply here. Thank you all for attending. Please get in touch if the timing of the vPTG did not work for you, as we could propose multiple timezone slots in future. * Heat driver deprecation. o This driver is marked deprecated in Dalmation 2025.1, being replaced by either of the Cluster API drivers, and we discussed when and how we will remove it from Magnum codebase. o We are now looking at removing the Heat driver in this (Flamingo 2025.2) cycle, as waiting longer may imply waiting until 2026.2 due to SLURP release expectations. We would like to hear any feedback on this plan from users of Magnum - either in the mailing list or join one of our IRC meetings[2]. o One option is to move the driver out of tree into its own codebase (perhaps in `x/`), to allow deployers to keep their existing clusters functional and addressable by Magnum while transitioning to a Cluster API driver. This initiative needs effort and a champion to drive it. * Helm charts (magnum-capi-helm driver) o While the driver code is now in opendev the Helm charts live in azimuth-cloud's github. These are a major component of the driver and we discussed the reasoning behind keeping them in github and stability of the Magnum-capi-helm driver. o The current proposal is to snapshot the upstream repo at regular intervals into the opendev repo. This avoids maintenance of a complete fork, but keeps the Magnum-capi-helm driver with a stable internal reference of the helm charts. * CI for the Magnum project was discussed o One big implication of the Heat driver being removed is what we test against. o Including the CAPI drivers (initially non-voting) would give stability, provided external changes wouldn't break the CI. * Normalised labels proposal o Dale has a proposal for Normalised labels[3], aiming for Mutable labels. The video format discussion of the vPTG was very helpful to give context and move the idea forward to cover API backwards compatibility requirements and a better way to implement support labels for different drivers. o The proposal as it stands should be re-worked to look at covering a similar extension pattern that Nova has with drivers, and possibly look to replace labels. * TC initiatives o We discussed the upcoming Eventlet removal and as we are a small team we will wait for guidance and examples to follow before implementing, but we remain aware of this initiative. Finally, I wanted to announce to the list that at last weeks Magnum IRC meeting we proposed and agreed on a new time slot. This is on alternate (every second) Tuesday at 8am UTC starting on the 27th May[2]. See the meeting notes for a full transcript and discussion[4]. Links and references: [1] Magnum vPTG topics and notes can be found on https://etherpad.opendev.org/p/apr2025-ptg-magnum [2] Magnum weekly meeting times and agenda, https://etherpad.openstack.org/p/magnum-weekly-meeting [3] Normalisation of labels proposal, https://review.opendev.org/c/openstack/magnum-specs/+/943358 [4] Magnum meeting 2025-05-14, https://meetings.opendev.org/meetings/magnum/2025/magnum.2025-05-14-09.00.l… Thank you for reading! (or skim reading!) Dale Smith Magnum PTL for Epoxy cycle.

2 months, 3 weeks

Re: nova-ovs-hybrid-plug CI jobs failing for Nova

by Sean Mooney

so looking at the logs devstack did not compelte on the contoler do it did not even start running on the compute the way these jobs work is we fully deploy the all-in-one controller host, then we copy the data related to the tls or ceph secrets to the subnodes and then finally run devstack on those. once all devstack tasks are complete we then proced to do tempest config and run the tests. the controller failed when creating the inital neutorn netowrks which is not reallse surpisign given the q-svr the nenturon server as not deploysed. 2025-06-29 09:01:01.801 | Error while executing command: HttpException: 500, Request Failed: internal server error while processing your request. 2025-06-29 09:01:01.140 | ++ lib/neutron_plugins/services/l3:create_neutron_initial_network:202 : oscwrap --os-cloud devstack --os-region RegionOne network create private -f value -c id my guess is this is related to the eventlet removal it looks like it has been replaced with the neutron-api wsgi application https://zuul.opendev.org/t/openstack/build/fcc678f62f584bbb9726821f5992ae90… that has a bunch of sql errors https://zuul.opendev.org/t/openstack/build/fcc678f62f584bbb9726821f5992ae90… almost as if the schema had not been applied properly. ah yep https://zuul.opendev.org/t/openstack/build/fcc678f62f584bbb9726821f5992ae90… when it was ran it failed here https://zuul.opendev.org/t/openstack/build/fcc678f62f584bbb9726821f5992ae90… the hybrid plug job is testing with debian 12 currently and i guess its using 3.11 as a result. the python version might be unrelated but it is a delta form the normal ubuntu 24.04 jobs. the error seams to be sqlalchemy.exc.OperationalError: (pymysql.err.OperationalError) (1273, "Unknown collation: 'utf8mb4_0900_as_cs'") so it looks liek the version of mariadb/myxql that debian 12 is shiping may not supprot that type. so this is a regression introduced by https://github.com/openstack/neutron/commit/8990dd598f84b9da976d72672c6fd60… debian 12 is one of the testign runtimes so neutron annog uncondionally use that coaltion type this cycle it would be better to use utf8mb4_bin as the case sensitive encoding instead. that is much older then the new _0900_ variants On 29/06/2025 23:16, Michael Still wrote: > Thanks for the pointer. I think its clear that I am not an expert on > this job... However, I note that both the original failed run and > another log this: > > Warning: Permanently added '200.225.47.19' (ED25519) to the list of > known hosts. > rsync: [sender] link_stat > "/var/lib/zuul/builds/12aacd4951a64c0abef5cfe1bf925c2e/work/ca-bundle.pem" > failed: No such file or directory (2) > rsync error: some files/attrs were not transferred (see previous > errors) (code 23) at main.c(1338) [sender=3.2.7] > > Which seems like it might be causing the compute node to not start? I > certainly cannot see any logs from nova on the compute node's zuul output. > > I'll continue to dig. > > Michael > > On Mon, Jun 30, 2025 at 6:15 AM Jeremy Stanley <fungi(a)yuggoth.org> wrote: > > On 2025-06-30 05:36:00 +1000 (+1000), Michael Still wrote: > [...] > > I am unsure who owns 200.225.47.11. Is it possible its offline? > > It's a 2-node job, and that's the address of the controller node > according to: > https://zuul.opendev.org/t/openstack/build/fcc678f62f584bbb9726821f5992ae90… > > Maybe check the logs for services collected from the controller to > see if something crashed or failed to start? > -- > Jeremy Stanley >

1 month, 1 week

[tc][all] OpenStack Technical Committee Weekly Summary and Meeting Agenda (2025.2/R-8)

by Goutham Pacha Ravi

Hello Stackers, We're eight weeks away from wrapping up the 2025.2 "Flamingo" release, and three weeks away from its feature freeze (August 28, 2025) [1]. Over the past week, no new governance changes were merged, but some new changes are undergoing community review. The nomination window for Project Team Leads and for four seats on the OpenStack Technical Committee begins on August 6, 2025 [2]. If you have any questions about the process, please post them on this mailing list or hop into #openstack-tc, #openstack-election, or #openstack-dev on OFTC and let's chat. This week, the TC is also looking to refresh the liaisons for projects governed by the "distributed-project-leadership" model—an opportunity for those teams to switch their governance styles, as well. === Weekly Meeting === The TC's weekly meeting focused on two major topics [3]: finalizing the definition of “affiliation” for TC election candidates and the next steps for retiring Monasca. On the affiliation front, we debated whether to reuse the OpenInfra bylaws language or simplify it for our needs. During the meeting, there was a consensus that the definition should focus on contributor intent and a visible employee-employer relationship without getting bogged down in legal technicalities. It's important to share our biases upfront for the sake of transparency and to strive toward the TC's affiliation diversity requirement. We are moving ahead with retiring the Monasca project. After earlier signals of interest in continuing maintenance, the project team now seems comfortable with retirement. The TC consulted this mailing list [4] to seek any further interest in the project. We'll work with the "unmaintained-core" group to clean up deliverables and code branches. We also touched on CI work to test OpenStack with Debian Bookworm and Trixie, which will help us make progress on the Eventlet removal community goal. Finally, a brief discussion ensued on OpenStack for AI, encouraging folks with architectural insight to join the Foundation's AI working group and its mailing list [5]. We wrapped with a shout out to the i18n interns and mentors for their recent progress [6]. The next weekly meeting of the TC is today, August 5, 2025, at 1700 UTC. This meeting will be hosted simultaneously over Meetpad and IRC. Please find the meeting's agenda and call details in the wiki [7]. I hope you'll be able to join us. === Governance Proposals === ==== Open for review ==== - Define "affiliation" within the context of the TC | https://review.opendev.org/c/openstack/governance/+/956024 - Add series names to runtimes doc | https://review.opendev.org/c/openstack/governance/+/955810 - Remove Monasca from active project | https://review.opendev.org/c/openstack/governance/+/953671 - os-test-images never releases | https://review.opendev.org/c/openstack/governance/+/954249 - Require declaration of affiliation from TC Candidates | https://review.opendev.org/c/openstack/governance/+/949432 === Upcoming Events === - 2025-08-06: Nominations open for OpenStack elections: https://governance.openstack.org/election/ - 2025-08-20: Nominations close for OpenStack elections - 2025-08-26: OpenInfra Days, Korea: https://2025.openinfradays.kr/ - 2025-08-28: Feature Freeze deadline, Milestone-3 of the Flamingo release [1] - 2025-08-29: Colombia OpenInfra User Group Meetup: https://www.meetup.com/colombia-openinfra-user-group/events/307096751/ - 2025-10-17: OpenInfra Summit, Paris-Saclay: https://summit2025.openinfra.org/ Thank you very much for reading! On behalf of the OpenStack TC, Goutham Pacha Ravi (gouthamr) OpenStack TC Chair [1] 2025.2 "Flamingo" Release Schedule: https://releases.openstack.org/flamingo/schedule.html [2] 2026.1 OpenStack Elections: https://governance.openstack.org/election/ [3] TC Meeting IRC Log 2025-07-29: https://meetings.opendev.org/meetings/tc/2025/tc.2025-07-29-17.00.html [4] Call for maintainers for Monasca: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… [5] OpenInfra AI WG List: https://lists.openinfra.org/mailman3/lists/ai-openstack-wg.lists.openinfra.… [6] i18n Internship with CMU: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… [7] TC Meeting Agenda, 2025-08-05: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting

5 days, 23 hours

Re: Upstream Oslo IRC Meetings Are Back.

by Herve Beraud

Le mer. 30 oct. 2024 à 13:06, Stephen Finucane <stephenfin(a)redhat.com> a écrit : > On Tue, 2024-10-29 at 15:43 +0900, Takashi Kajinami wrote: > > +1 for using doodle vote to decide the slot. > > > > > > Just dumping my preference here for your refernce but I'll reflect these > > in the vote once it is open. > > > > Regarding the time slot, assuming we have more people from US/EMEA TZ > > attending the meeting, I'm ok with having the meeting late, but I hope > > we can finish it before 16:00 UTC (25:00 JST). > > > > Regarding the day, here in Japan we have more local holidays on Monday > > than the other days of a week, so I hope we can avoid Monday as I > mentioned > > in my reply to the previous thread. I more likely get my own things on > > Friday or Wednesday. So I personally prefer Tuesday and Thursday, and > then > > Wednesday as a fallback. > > Just thinking out loud: is it possible to alternate between (European) > mornings > and afternoons to catch both audiences? I don't think the Doodle captures > this > option. > This is a good idea, I was thinking of maybe doing the same for the IRC meetings related to eventlet-removal. It would leave a chance for everybody to attend. The eventlet meetings are a bit different because they are bimonthly meetings so we could easily shift the time slot between the first and the second meeting. But as Daniel pushed to run it each week, IMO, it would be more complexe to apply it to oslo meetings. I'm far from a doodle expert, but from what I observed, doodle want specific dates so... maybe the trick is to propose 2 time slots on fake dates that more represent days of the week (monday, tuesday, wed...) than real dates, and then to select the both opposite time slots that best cover our extended time zone needs. > Stephen > > > > > On 10/29/24 1:59 AM, Herve Beraud wrote: > > > I don't think we can answer that question here. I'd encourage you to > propose time slots and day and then to run a doodle vote on them. > > > > > > Le lun. 28 oct. 2024 à 17:22, Daniel Bengtsson <dbengt(a)redhat.com > <mailto:dbengt@redhat.com>> a écrit : > > > > > > > > > > > > On 2024-10-28 15:55, Herve Beraud wrote: > > > > If we decide to change the hour, then, the meeting page should > > > > be updated (https://meetings.opendev.org/#Oslo_Team_Meeting < > https://meetings.opendev.org/#Oslo_Team_Meeting> <https:// > > > > meetings.opendev.org/#Oslo_Team_Meeting < > http://meetings.opendev.org/#Oslo_Team_Meeting>>). > > > Yes I will updated but what is the best time and day for everyone? > > > > > > -- > > > Daniel Bengtsson > > > Software engineer > > > > > > > > > > > > -- > > > Hervé Beraud > > > Senior Software Engineer at Red Hat > > > irc: hberaud > > > https://github.com/4383/ <https://github.com/4383/> > > > > > > > -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/

9 months, 1 week

[tc][all] OpenStack Technical Committee Weekly Summary and Meeting Agenda (2025.1/R-23)

by Goutham Pacha Ravi

Hello Stackers, This week, the OpenStack community is convening virtually to set the agenda for the 2025.1 "Epoxy" release and beyond [1][2]. As of today, there are 33 different discussion tracks spread over five days. Now's as good a time as ever to review the Community Code of Conduct as we step into this event [3]. In the past week, the North American section of the OpenInfra community gathered in Indianapolis (and virtually) for a two-day conference. I had the privilege to attend in person and chat with numerous users, operators, and contributors. The community is as energetic as ever, as evidenced by the participation we saw in the leadership meet-and-greet event [4]. Amy Marrich (spotz) organized this event, and we had representation from the OpenInfra Board, Zuul, OpenStack TC, SIGs, and PTLs. The audience learned the essence of our "Open Community," how elections are conducted, what different community leadership roles are, and how one can participate in OpenInfra governance. We brainstormed how to revive projects with dwindling contributors and recapped takeaways from the "Bridging the Gap" and Security SIG-related discussions. Prof. Corey Leong (profcorey) from Valencia College volunteered to propose a "Higher Education" Special Interest Group focused on increasing awareness and creating learning material for university students interested in joining the OpenStack community. I'll share a link with video recordings of this conference in a future post. === Weekly Meeting === Dmitriy Rabotyagov (noonedeadpunk) chaired the weekly IRC meeting [5] of the OpenStack Technical Committee last week. We had fewer attendees than usual, but it was a productive discussion nevertheless. We prepped the TC's PTG etherpad [6] with topics and timings for the discussion. As is tradition, please allow flexibility in terms of the discussion schedule. Discussions may start a bit later (or earlier) than planned, and we'll have to be dynamic to accommodate scheduling conflicts, as many contributors are involved across multiple topics. In lieu of the PTG, the weekly IRC meeting scheduled for 2024-10-22 has been canceled [7]. We briefly discussed the leadership appointment patches concerning the Watcher and Mistral project teams. These are still being reviewed, and we'll try to get them closed out after the PTG week. We also discussed grenade job changes that Ghanshyam Mann (gmann) and other community members have been pursuing [8]. Concerns were raised about projects (like Kolla and Loci) publishing container images under the OpenStack name without a clear security policy. The need to clarify OpenStack's support and security posture on such deliverables was discussed. We have more to discuss on this topic at the PTG and beyond. The next weekly IRC meeting for the OpenStack Technical Committee is on 2024-10-29. The agenda is up early [9], but I'll write to you once again before it is formalized. I look forward to seeing you all at the PTG and possibly seeding more topics for this weekly meeting afterward. === Governance Proposals === ==== Open for Review ==== Add Cinder Huawei charm | https://review.opendev.org/c/openstack/governance/+/867588 Appoint Ke Chen as PTL for Watcher | https://review.opendev.org/c/openstack/governance/+/932419 Adding Axel Vanzaghi as PTL for Mistral | https://review.opendev.org/c/openstack/governance/+/927962 Retire kuryr-kubernetes and kuryr-tempest-plugin | https://review.opendev.org/c/openstack/governance/+/922507 Propose a pop-up team for eventlet-removal | https://review.opendev.org/c/openstack/governance/+/931978 Propose to select the eventlet-removal community goal | https://review.opendev.org/c/openstack/governance/+/931254 === Upcoming Events === 2024-10-21 to 2024-10-25: OpenInfra Project Teams Gathering: https://openinfra.dev/ptg/ 2024-10-27: All Things Open: https://allthingsopen.org/ 2024-11-04: OpenInfra Board Meeting: https://board.openinfra.dev/ 2024-11-15: KubeCon + CloudNativeCon: https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/ 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] "Epoxy" PTG Schedule: https://ptg.opendev.org/ptg.html [3] OpenInfra Community Code of Conduct: https://openinfra.dev/legal/code-of-conduct [4] OpenInfra Leadership Meet-and-Greet: https://etherpad.opendev.org/p/leadership-na [5] TC Meeting IRC Log, 2024-10-15: https://meetings.opendev.org/meetings/tc/2024/tc.2024-10-15-18.00.log.html [6] TC PTG Etherpad: https://etherpad.opendev.org/p/oct2024-ptg-os-tc [7] TC IRC meeting 2024-10-22 is canceled: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… [8] Grenade Job changes: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… [9] TC Meeting Agenda, 2024-10-29: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting

9 months, 3 weeks

Re: [nova] multiple pci types with same address

by Sean Mooney

On 17/06/2025 09:30, Arnaud Morin wrote: > Hello nova team, > > Quick question regarding support for multiple types (see [1]) with the same address: > {vendor_id: "10de", product_id: "233b", "address": "00000000:03:00.0", "resource_class": "CUSTOM_H200_A"} > {vendor_id: "10de", product_id: "233b", "address": "00000000:04:00.0", "resource_class": "CUSTOM_H200_A"} > {vendor_id: "10de", product_id: "233b", "address": "00000000:44:00.0", "resource_class": "CUSTOM_H200_A"} > {vendor_id: "10de", product_id: "233b", "address": "00000000:45:00.0", "resource_class": "CUSTOM_H200_A"} > {vendor_id: "10de", product_id: "233b", "address": "00000000:83:00.0", "resource_class": "CUSTOM_H200_B"} > {vendor_id: "10de", product_id: "233b", "address": "00000000:84:00.0", "resource_class": "CUSTOM_H200_B"} > {vendor_id: "10de", product_id: "233b", "address": "00000000:C3:00.0", "resource_class": "CUSTOM_H200_B"} > {vendor_id: "10de", product_id: "233b", "address": "00000000:C4:00.0", "resource_class": "CUSTOM_H200_B"} > > This works fine, I was able to define multiple aliases: > {name: "h200a", device_type:"type-PF", resource_class: "CUSTOM_H200_A"} > {name: "h200b", device_type:"type-PF", resource_class: "CUSTOM_H200_B"} > > I did that to create two blocks of 4 resources (A or B). > > But now, I need to create a flavor to boot instances with these devices. > I want to have only one flavor that can use either A or B: > For now I created a flavor with: > pci_passthrough:alias='h200a:4' > > And was forced to create a second flavor with h200b:4. > > Is there any way to achieve a single flavor with both: > Something like this? > pci_passthrough:alias='h200a:4|h200b:4' > > I can't figure that out for now, is it possible? no its not and for reasons is also not easy to implement that in the future because of how placement works. we would need a new OneOF type query in the allocation candidates api. the feature you really want is https://specs.openstack.org/openstack/nova-specs/specs/2024.1/approved/pci-… it was proposed but never implemented. with that spec you can carve ups pci device into groups in the pci devspec and then have a a singel resouce class to select any one of the groups. so in your case you would express ``` {vendor_id: "10de", product_id: "233b", "address": "00000000:03:00.0", "resource_class": "CUSTOM_H200_A"} {vendor_id: "10de", product_id: "233b", "address": "00000000:04:00.0", "resource_class": "CUSTOM_H200_A"} {vendor_id: "10de", product_id: "233b", "address": "00000000:44:00.0", "resource_class": "CUSTOM_H200_A"} {vendor_id: "10de", product_id: "233b", "address": "00000000:45:00.0", "resource_class": "CUSTOM_H200_A"} {vendor_id: "10de", product_id: "233b", "address": "00000000:83:00.0", "resource_class": "CUSTOM_H200_B"} {vendor_id: "10de", product_id: "233b", "address": "00000000:84:00.0", "resource_class": "CUSTOM_H200_B"} {vendor_id: "10de", product_id: "233b", "address": "00000000:C3:00.0", "resource_class": "CUSTOM_H200_B"} {vendor_id: "10de", product_id: "233b", "address": "00000000:C4:00.0", "resource_class": "CUSTOM_H200_B"} ``` as ``` {vendor_id: "10de", product_id: "233b", "address": "00000000:03:00.0", "group_name": "A", "group_type": "H200"} {vendor_id: "10de", product_id: "233b", "address": "00000000:04:00.0", "group_name": "A", "group_type": "H200"} {vendor_id: "10de", product_id: "233b", "address": "00000000:44:00.0", "group_name": "A", "group_type": "H200"} {vendor_id: "10de", product_id: "233b", "address": "00000000:45:00.0", "group_name": "A", "group_type": "H200"} {vendor_id: "10de", product_id: "233b", "address": "00000000:83:00.0", "group_name": "B", "group_type": "H200"} {vendor_id: "10de", product_id: "233b", "address": "00000000:84:00.0", "group_name": "B", "group_type": "H200"} {vendor_id: "10de", product_id: "233b", "address": "00000000:C3:00.0", "group_name": "B", "group_type": "H200"} {vendor_id: "10de", product_id: "233b", "address": "00000000:C4:00.0", "group_name": "B", "group_type": "H200"} alias = {"name":"h200", resource_class:"CUSTOM_PCI_GROUP_H200"} ``` and in the flavor you would request pci_passthrough:alias='h200:1' pci groups allocate a full group to the request. its a very useful propal that we have discuss on an over for thet better part of a decade and finally got as far as writign it down for 2024.1 but then the implementation never got started. i know some redhat customer are also asked about this type of grouping functionality so at least internally this comes up form time to time. i strongly suspect this will eventually get implemtned but there have been higher priorites for the nova team like eventlet removal or gpu live migrations. if some one propsoes it again i know at least john garbutt was keen to see this added for some hpc usecases and i suspect with the current AI boom passing blocks of H200 gpus to a workload is becomming more common not less. > > [1] https://docs.openstack.org/nova/latest/admin/pci-passthrough.html#support-f… >

1 month, 3 weeks

Re: Upstream Oslo IRC Meetings Are Back.

by Ghanshyam Mann

---- On Wed, 30 Oct 2024 08:06:11 -0700 Herve Beraud wrote --- > > > Le mer. 30 oct. 2024 à 13:06, Stephen Finucane stephenfin(a)redhat.com> a écrit : > On Tue, 2024-10-29 at 15:43 +0900, Takashi Kajinami wrote: > > +1 for using doodle vote to decide the slot. > > > > > > Just dumping my preference here for your refernce but I'll reflect these > > in the vote once it is open. > > > > Regarding the time slot, assuming we have more people from US/EMEA TZ > > attending the meeting, I'm ok with having the meeting late, but I hope > > we can finish it before 16:00 UTC (25:00 JST). > > > > Regarding the day, here in Japan we have more local holidays on Monday > > than the other days of a week, so I hope we can avoid Monday as I mentioned > > in my reply to the previous thread. I more likely get my own things on > > Friday or Wednesday. So I personally prefer Tuesday and Thursday, and then > > Wednesday as a fallback. > > Just thinking out loud: is it possible to alternate between (European) mornings > and afternoons to catch both audiences? I don't think the Doodle captures this > option. > > This is a good idea, I was thinking of maybe doing the same for the IRC meetings related to eventlet-removal. It would leave a chance for everybody to attend.The eventlet meetings are a bit different because they are bimonthly meetings so we could easily shift the time slot between the first and the second meeting.But as Daniel pushed to run it each week, IMO, it would be more complexe to apply it to oslo meetings. > I'm far from a doodle expert, but from what I observed, doodle want specific dates so... maybe the trick is to propose 2 time slots on fake dates that more represent days of the week (monday, tuesday, wed...) than real dates, and then to select the both opposite time slots that best cover our extended time zone needs. ++ on alternate TZ meetings, and that way, EU and Asia TZ can be covered in one of the meetings. To keep it simple, we can have separate doodle poll for each TZ meeting. -gmann > > > Stephen > > > > > On 10/29/24 1:59 AM, Herve Beraud wrote: > > > I don't think we can answer that question here. I'd encourage you to propose time slots and day and then to run a doodle vote on them. > > > > > > Le lun. 28 oct. 2024 à 17:22, Daniel Bengtsson dbengt(a)redhat.com dbengt(a)redhat.com>> a écrit : > > > > > > > > > > > > On 2024-10-28 15:55, Herve Beraud wrote: > > > > If we decide to change the hour, then, the meeting page should > > > > be updated (https://meetings.opendev.org/#Oslo_Team_Meeting https://meetings.opendev.org/#Oslo_Team_Meeting> <https:// > > > > meetings.opendev.org/#Oslo_Team_Meeting http://meetings.opendev.org/#Oslo_Team_Meeting>>). > > > Yes I will updated but what is the best time and day for everyone? > > > > > > -- > > > Daniel Bengtsson > > > Software engineer > > > > > > > > > > > > -- > > > Hervé Beraud > > > Senior Software Engineer at Red Hat > > > irc: hberaud > > > https://github.com/4383/ https://github.com/4383/> > > > > > > > > > -- > Hervé BeraudSenior Software Engineer at Red Hatirc: hberaudhttps://github.com/4383/ > >

9 months, 1 week

[watcher] 2025.2 Flamingo PTG summary

by Douglas Viroel

Hello everyone, Last week's PTG had very interesting topics. Thank you all that joined. The Watcher PTG etherpad with all notes is available here: https://etherpad.opendev.org/p/apr2025-ptg-watcher Here is a summary of the discussions that we had, including the great cross-project sessions with Telemetry, Horizon and Nova team: Tech Debt (chandankumar/sean-k-mooney) ================================= a) Croniter - Project is being abandoned as per https://pypi.org/project/croniter/#disclaimer - Watcher uses croniter to calculate a new schedule time to run an audit (continuous). It is also used to validate cron like syntax - Agreed: replace croniter with appscheduler's cron methods. - *AI*: (chandankumar) Fix in master branch and backport to 2025.1 b) Support status of Watcher Datasources - Only Gnocchi and Prometheus have CI job running tempest tests (with scenario tests) - Monaska is inactive since 2024.1 - *AI*: (jgilaber) Mark Monasca and Grafana as deprecated, unless someone steps up to maintain them, which should include a minimal CI job running. - *AI*: (dviroel) Document a support matrix between Strategies and Datasources, which ones are production ready or experimental, and testing coverage. c) Eventlet Removal - Team is going to look at how the eventlet is used in Watcher and start a PoC of its removal. - Chandan Kumar and dviroel volunteer to help in this effort. - Planned for 2026.1 cycle. Workflow/API Improvements (amoralej) ============================== a) Actions states - Currently Actions updates from Pending to Succeeded or Failed, but these do not cover some important scenarios - If an Action's pre_conditions fails, the action is set to FAILED, but for some scenarios, it could be just SKIPPED and continue the workflow. - Proposal: New SKIPPED state for action. E.g: In a Nova Migration Action, if the instance doesn't exist in the source host, it can be skipped instead of fail. - Proposal: Users could also manually skip specific actions from an action plan. - A skip_reason field could also be added to document the reason behind the skip: user's request, pre-condition check, etc. - *AI*: (amoralej) Create a spec to describe the proposed changes. b) Meaning of SUCCEEDED state in Action Plan - Currently means that all actions are triggered, even if all of them fail, which can be confusing for users. - Docs mention that SUCCEEDED state means that all actions have been successfully executed. - *AI*: (amoralej) Document the current behavior as a bug (Priority High) - done: https://bugs.launchpad.net/watcher/+bug/2106407 Watcher-Dashboard: Priorities to next release (amoralej) =========================================== a) Add integration/functional tests - Project is missing integration/functional tests and a CI job running against changes in the repo - No general conclusion and we will follow up with Horizon team - *AI*: (chandankumar/rlandy) sync with Horizon team about testing the plugin with horizon. - *AI*: (chandankumar/rlandy) devstack job running on new changes for watcher-dashboard repo. b) Add parameters to Audits - It is missing on the watcher-dashboard side. Without it, it is not possible to define some important parameters. - Should be addressed by a blueprint - Contributors to this feature: chandankumar Watcher cluster model collector improvement ideas (dviroel) ============================================= - Brainstorm ideas to improve watcher collector process, since we still see a lot of issues due to outdated models when running audits - Both scheduled model update and event-based updates are enabled in CI today - It is unknown the current state of event-based updates from Nova notification. Code needs to be reviewed and improvements/fixes can be proposed - e.g: https://bugs.launchpad.net/watcher/+bug/2104220/comments/3 - We need to check if we are processing the right notifications of if is a bug on Nova - Proposal: Refresh the model before running an audit. A rate limit should be considered to avoid too many refreshments. - *AI*: (dviroel) new spec for cluster model refresh, based on audit trigger - *AI:* (dviroel) investigate the processing of nova events in Watcher Watcher and Nova's visible constraints (dviroel) ==================================== - Currently, Watcher can propose solutions that include server migrations that violate some Nova constraints like: scheduler_hints, server_groups, pinned_az, etc. - In Epoxy release, Nova's API was improved to also show scheduler_hints and image_properties, allowing external services, like watcher, to query and use this information when calculating new solutions. - https://docs.openstack.org/releasenotes/nova/2025.1.html#new-features - Proposal: Extend compute instance model to include new properties, which can be retrieved via novaclient. Update strategies to filter invalid migration destinations based on these new properties. - *AI*: (dviroel) Propose a spec to better document the proposal. No API changes are expected here. Replacement for noisy neighbor policy (jgilaber) ==================================== - The existing noisy neighbor strategy is based on L3 Cache metrics, which is not available anymore, since the support for it was dropped from the kernel and from Nova. - In order to keep this strategy, new metrics need to be considered: cpu_steal? io_wait? cache_misses? - *AI*: (jgilaber) Mark the strategy as deprecated during this cycle - *AI*: (TBD) Identify new metrics to be used - *AI*: (TBD) Work on a replacement for the current strategy Host Maintenance strategy new use case (jeno8) ===================================== - New use case for Host Maintenance strategy: instance with ephemeral disks should not be migrated at all. - Spec proposed: https://review.opendev.org/c/openstack/watcher-specs/+/943873 - New action to stop instances when both live/cold migration are disabled by the user - *AI*: (All) Review the spec and continue with discussion there. Missing Contributor Docs (sean-k-mooney) ================================ - Doc missing: Scope of the project, e.g: https://docs.openstack.org/nova/latest/contributor/project-scope.html - *AI*: (rlandy) Create a scope of the project doc for Watcher - Doc missing: PTL Guide, e.g: https://docs.openstack.org/nova/latest/contributor/ptl-guide.html - *AI*: (TBD) Create a PTL Guide for Watcher project - Document: When to create a spec vs blueprint vs bug - *AI*: (TBD) Create a doc section to describe the process based on what is being modified in the code. Retrospective ========== - The DPL approach seems to be working for Watcher - New core members added: sean-k-mooney, dviroel, marios and chandankumar - We plan to add more cores in the next cycle, based on reviews and engagement. - We plan to remove not active members in the 2 last cycles (starting at 2026.1) - A new datasource was added: Prometheus - Prometheus job now also runs scenario tests, along with Gnocchi. - We triaged all old bugs from launchpad - Needs improvement: - current team is still learning about details in the code, much of the historical knowledge was lost with the previous maintainers - core team still needs to grow - we need to focus on creating stable releases Cross-project session with Horizon team =============================== - Combined session with Telemetry and Horizon team, focused on how to provide a tenant and an admin dashboard to visualize metrics. - Watcher team presented some ideas of new panels for both admin and tenants, and sean-k-mooney raised a discussion about frameworks that can be used to implement them - Use-cases that were discussed: - a) Admin would benefit from a visualization of the infrastructure utilization (real usage metrics), so they can identify bottlenecks and plan optimization - b) A tenant would like to view their workload performance, checking real usage of cpu/ram/disk of instances, to proper adjust their resources allocation. - c) An admin user of watcher service would like to visualize metrics generated by watcher strategies like standard deviation of host metrics. - sean-k-mooney presented an initial PoC on how a Hypervisor Metrics dashboard would look like. - Proposal for next steps: - start a new horizon plugin as an official deliverable of telemetry project - still unclear which framework to use for building charts - dashboard will integrate with Prometheus, as metric store - it is expected that only short term metrics will be supported (7 days) - python-observability-client will be used to query Prometheus Cross-project session with Nova team ============================= - sean-k-mooney led topics on how to evolve Nova to better assist other services, like Watcher, to take actions on instances. The team agreed on a proposal of using the existing metadata API to annotate instance's supported lifecycle operations. This information is very useful to improve Watcher's strategy's algorithms. Some example of instance's metadata could be: - lifecycle:cold-migratable=true|false - ha:maintenance-strategy:in_place|power_off|migrate - It was discussed that Nova could infer which operations are valid or not, based on information like: virt driver, flavor, image properties, etc. This feature was initially named 'instance capabilities' and will require a spec for further discussions. - Another topic of interest, also raised by Sean, was about adding new standard traits to resource providers, like PRESSURE_CPU and PRESSURE_DISK. These traits can be used to weight hosts when placing new VMs. Watcher and the libvirt driver could work on annotating them, but the team generally agreed that the libvirt driver is preferred here. - More info at Nova PTG etherpad [0] and sean's summary blog [1] [0] https://etherpad.opendev.org/p/r.bf5f1185e201e31ed8c3adeb45e3cf6d [1] https://www.seanmooney.info/blog/2025.2-ptg/#watcher-topics Please let me know if I missed something. Thanks! -- Douglas Viroel - dviroel

3 months, 3 weeks

[tc][all] OpenStack Technical Committee Weekly Summary and Meeting Agenda (2025.1/R-11)

by Goutham Pacha Ravi

Hello Stackers, Time flies! We're 11 weeks away from the 2025.1 "Epoxy" release day [1]. OpenStack project teams must be working on their deliverables according to the schedule shared by Előd Illés (elodilles) from the release team [2] this week. In the past week, the OpenStack Technical Committee (TC) worked with election officials to adjust the dates of the elections preceding the 2025.2 ("Flamingo" [3]) release cycle. This change was made in response to a revision in the TC's charter that now allows more time for polling. Election officials will share the updated schedule on this list soon. Additionally, the TC approved the retirement of openstack-ansible roles for former projects: Murano (Application Catalog), Senlin (Clustering Service), and Sahara (Data Processing). The OpenInfra Board's Individual Member Director elections are currently underway [4]. If you are an OpenInfra Foundation member, please check your email for a ballot and participate. The election will conclude on Friday, 2025-01-17. === Weekly Meeting === The OpenStack TC resumed its regular weekly meeting schedule last week following a brief hiatus due to the year-end holidays. Last week's meeting was held on 2025-01-07 at 1800 UTC, simultaneously on Zoom and IRC. Please find the meeting minutes on eavesdrop [5] and a recording on YouTube [6]. The meeting began with a discussion about the pending proposal [7] to delete the "unmaintained/victoria" branch on OpenStack git repositories. There is interest from at least one contributing organization in keeping this branch open for specific repositories. The deadline to merge this change is 2025-01-31. We aim to identify the specific repositories and the responsible maintainers by then. I'll keep you updated in future emails. The TC then discussed initiating the election cycle for the 2025.2 release. We recognize that long holidays (such as the upcoming Chinese New Year) could impact nominations from interested candidates. We hope to encourage nominations as early as possible since even a couple of extra weeks could make a difference in coordinating for such a geographically diverse community. The TC also reviewed the status of the community goal to migrate test jobs to Python 3.12 (and "Ubuntu 24.04 / Noble Numbat" where applicable). Ghanshyam Mann (gmann), the goal champion, shared that test jobs in three projects (Heat, Skyline, and devstack-plugin-container) need attention from their respective project teams [8]. We also expressed our gratitude to the OpenDev Infrastructure team for keeping the systems running smoothly during the holidays. The next OpenStack Technical Committee meeting is today, 2025-01-14, at 1800 UTC. This meeting will be held over IRC in OFTC's #openstack-tc channel. Please find the agenda on the meeting wiki [9]. I hope you can join us. Remember, any community member can propose meeting topics—just mention your IRC nick so the meeting chair can call upon you. === Governance Proposals === ==== Merged ==== - Allow more than 2 weeks for elections | https://review.opendev.org/c/openstack/governance/+/937741 - Put whitebox-tempest-plugin under release management | https://review.opendev.org/c/openstack/governance/+/938401 - Retire Murano/Senlin/Sahara OpenStack-Ansible roles | https://review.opendev.org/c/openstack/governance/+/935677 ==== Open for Review ==== - Rework the eventlet-removal goal proposal | https://review.opendev.org/c/openstack/governance/+/931254 - Add ansible-role-httpd repo to OSA-owned projects | https://review.opendev.org/c/openstack/governance/+/935694 - Retire Freezer DR | https://review.opendev.org/c/openstack/governance/+/938183 - Retire qdrouterd role | https://review.opendev.org/c/openstack/governance/+/938193 - Remove Freezer from inactive state | https://review.opendev.org/c/openstack/governance/+/938938 - Propose to select the eventlet-removal community goal | https://review.opendev.org/c/openstack/governance/+/934936 - Resolve to adhere to non-biased language | https://review.opendev.org/c/openstack/governance/+/934907 === 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. - Ping us using the 'tc-members' keyword on the #openstack-tc IRC channel on OFTC. - Join us at our weekly meeting: The Technical Committee meets every week on Tuesdays at 1800 UTC [9]. === Upcoming Events === - 2025-01-17: 2025 OpenInfra Board Individual Member Director Elections conclude - 2025-02-01: FOSDEM 2025 (https://fosdem.org/2025/) OpenStack's 15th Birthday Celebration - 2025-02-28: 2025.1 ("Epoxy") Feature Freeze and release milestone 3 [1] - 2025-03-06: SCALE 2025 + OpenInfra Days NA (https://www.socallinuxexpo.org/scale/22x) 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] Release countdown for week R-11: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… [3] OpenStack 2025.2 'F' Release Naming Poll: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… [4] OpenInfra Foundation Board Elections: https://openinfra.dev/election/2025-individual-director-election [5] TC Meeting IRC Log 2025-01-07: https://meetings.opendev.org/meetings/tc/2025/tc.2025-01-07-18.00.log.html [6] TC Meeting Video Recording, 2025-01-07: https://youtu.be/-Nxul8_ykto [7] Transition unmaintained/victoria to EOL: https://review.opendev.org/c/openstack/releases/+/937515 [8] Projects failing the "migrate-to-noble" goal: https://etherpad.opendev.org/p/migrate-to-noble#L172 [9] TC Meeting Agenda, 2025-01-14: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting

6 months, 4 weeks

openstack-discuss search results for query "#eventlet-removal"