April 2025 - openstack-discuss - lists.openstack.org

[OpenInfra Foundation] VMware to OpenStack Migration Survey
by Jimmy McArthur 17 Apr '25

17 Apr '25

Last year we created the first VMware to OpenStack Migration survey and gained some valuable insight into the state of the market given the Broadcom shakeup. This year, we’re expanding the scope a bit and have added some new questions. I’d greatly appreciate it if you could take a few moments and fill this out if your organization has any business interest in this topic. https://openinfrafoundation.formstack.com/forms/vmware_strategy_survey_nm Please note that there are a couple of opportunities highlighted in the survey: An option to do a customer case study and opting your org in to sharing info with some research firms that have expressed interest in this topic. I am more than happy to answer any questions around the survey and/or data usage! Thanks everyone! Jimmy McArthur OpenInfra Foundation

1 0

[nova][ptg] 2025.2 Flamingo PTG summary
by Rene Ribaud 17 Apr '25

17 Apr '25

Hello everyone, Last week was the PTG—thank you to those who joined! I hope you enjoyed it. I haven’t gathered exact attendance stats, but it seemed that most sessions had at least around 15 participants, with some peaks during the cross-team discussions. If you’d like to take a closer look, here’s the link to the PTG etherpad: https://etherpad.opendev.org/p/r.bf5f1185e201e31ed8c3adeb45e3cf6d We had a pretty full agenda for Nova, so here’s a summary I’ve tried to keep as short as possible. #### 2025.1 Epoxy Retrospective #### 17 specs were accepted, and 12 implemented — an excellent ratio. This represents a clear improvement over previous cycles. Virtiofs was successfully merged, unblocking other work and boosting contributor motivation. ✅ We agreed to maintain regular status updates via the etherpad and follow up during Nova meetings. API Microversions & Tempest Coverage, several microversions were merged with good structure. However, some schema changes were not reflected in Tempest, causing downstream blockers. Also the updates covered by the microversions were not propagated into the sdk and openstack client. ✅ Ensure client-side features (e.g., server show) are also published and tracked. ✅ Keep microversions isolated and document Tempest implications clearly in specs. ✅ Raise awareness of the tempest-with-latest-microversion job during Nova meetings. ✅ Monitor OpenAPI efforts in Nova, which may allow offloading schema checks from Tempest in the future. Eventlet Removal, progress is behind schedule, especially compared to other projects like Neutron. ✅ Flag this as a priority area for upcoming cycles. Review Process & Tracking, spec review days were difficult to coordinate, and the status etherpad often outdated. ✅ Encourage active contributors to support occasional contributors during review days. ✅ Commit to keeping the etherpad current throughout the cycle. #### 2025.2 Flamingo Planning #### Timeline: Soft spec freeze (no new specs): June 1st Hard spec freeze (M2): July 3rd Feature Freeze (FF): August 28th Final release: late September / early October ✅ We agreed to officially adopt June 1st as the soft freeze date, based on the successful approach in Epoxy. ✅ A spec review day will be scheduled around mid June, these will be scheduled and announced early to ensure participation. ✅ Uggla will update the schedule document with the proposed milestones. #### Upstream Bug Triage #### We acknowledged that active bug triage has slowed down, resulting in a backlog increase (~150 untriaged bugs). There is a consensus that triage remains important to maintain a clear picture of the actual bug landscape. ✅ Trial a new approach: review some untriaged bugs at the end of Nova team meetings. ✅ Process the list by age (starting with the newest or most-voted first). #### Closing Old Bugs #### A proposal was made to bulk-close bugs older than 2 years, with a respectful and explanatory message, aiming to reduce backlog and improve visibility. However, multiple voices expressed strong reservations. ✅Take no action for now. Focus efforts on triaging new bugs first. ✅ If we successfully reduce the number of untriaged new bugs, we can consider scrubbing the bug backlog and possibly closing some of the older ones. #### Preparation for Python 3.13 #### While Python 3.13 is not mandatory for 2025.2, early compatibility work was discussed due to known issues (e.g., eventlet is broken on 3.13, as observed on Ubuntu 25.04) Ubuntu 24.04 and CentOS Stream 10 will stay on 3.12 for their supported lifespans. A non-voting unit test job for Python 3.13 (openstack-tox-py313) has already been added and is currently passing. Introducing a functional job for 3.13 could be a good next step, if resources allow. ✅ Gibi will track this as part of the broader eventlet removal work. #### Confidential Computing Feature Planning #### AMD SEV is already supported in Nova. SEV-ES is implemented in libvirt and work is ongoing in Nova. SEV-SNP is now supported in libvirt (v10.5.0). Work in Nova has not started yet. ✅ Pay closer attention to SEV-ES reviews to help move this forward. ✅ Tkajinam will write a new spec for SEV-SNP. Intel TDX Kernel support is nearly ready (expected in 6.15). Libvirt patches exist, but feature is not yet upstreamed or widely released. ✅ No action agreed yet, as this remains exploratory. Arm CCA No hardware is available yet; earliest expected in April 2027 (Fujitsu Monaka). Support in libvirt, QEMU, and Linux kernel is still under development. ✅ The use case is reasonable, but too early to proceed — we should wait until libvirt and QEMU support is mature. ✅ It would be beneficial to wait for at least one Linux distribution to officially support Arm CCA, allowing real-world testing. ✅ Attestation support for Arm is seen as external to Nova, with only minor flags possibly needed in the guest. #### RDT / MPAM Feature Discussion #### RDT (Intel PQoS) and MPAM (Arm equivalent) aim to mitigate “noisy neighbor” issues by allocating cache/memory bandwidth to VMs. Development has stalled since 2019, primarily due to: - Lower priority for contributors - Lack of customer demand - Infrastructure complexity (NUMA modeling, placement limitations) ✅ r-taketn to reopen and revise the original spec, showing a clear diff to the previous version. ✅ Ensure that abstractions are generic, not tied to proprietary technology, using libvirt + resource classes/traits may provide enough flexibility. #### vTPM Live Migration #### A spec for vTPM live migration was approved in Epoxy: https://specs.openstack.org/openstack/nova-specs/specs/2025.1/approved/vtpm… <https://specs.openstack.org/openstack/nova-specs/specs/2025.1/approved/vtpm…>To support live-migratable vTPM-enabled instances, Barbican secrets used for vTPM need to be owned by Nova, rather than the end user. This shift in ownership allows Nova to access the secret during live migration operations. Opt-in is handled via image property or flavor extra spec, meaning user consent is explicitly required. Current Proposal to enable this workflow: - Castellan should allow per-call configuration for sending the service token (rather than relying on a global all-or-nothing setting). Proposal: https://review.opendev.org/c/openstack/castellan/+/942015 - If the Nova service token is present, Barbican should set the secret owner to Nova. Proposal: https://review.opendev.org/c/openstack/barbican/+/942016 This workflow ensures Nova can read/delete the secret during lifecycle operations like migration, without involving the user. A question was raised around possible co-ownership between Nova and the end user (e.g., both having access to the secret). While this may be interesting longer-term, current implementation assumes a single owner. ✅ User and host modes are as described in the spec. For deployment mode, Nova will: - Authenticate to Barbican as itself (using a service token). - Own the vTPM secret it creates — it will be able to create, read, and delete it. - The user will not see or control the secret, including deletion. - The secret will be visible to other members of the Nova service project by default, but this could be restricted in future via Barbican ACLs to limit visibility to Nova only. #### Cloud Hypervisor Integration #### There is an ongoing effort to integrate Cloud Hypervisor into Nova via the Libvirt driver: Spec: https://review.opendev.org/c/openstack/nova-specs/+/945549 The current PoC requires only minor changes to work with Libvirt, and the team is ready to present the proposal at the PTG. ✅ We’re happy with the direction the spec is taking. Below are some key highlights regarding the spec. ✅ Clarify platform support (e.g., is libvirt compiled with cloud hypervisor support by default? Is it available in distros?). ✅ Provide a plan for runtime attach of multiple NICs and volumes. ✅ Mark as experimental if cloud hypervisor is not yet in upstream distro packages. ✅ Ensure that the following features are expected to work and covered in the spec: resize, migrate, rebuild, evacuate, snapshot. ✅ Justify raw-only image support, and outline the path to qcow2 compatibility. #### vGPU (mdev) and PCI SR-IOV Topics #### 1. Live-migratable flag handling (physical_network tag) Bug: https://bugs.launchpad.net/nova/+bug/2102161 ✅ We agreed that the current behavior is correct and consistent with the intention: If live_migratable = false → fallback to hotplug during live migration. If live_migratable = true on both source and destination → prefer transparent live migration. ✅ Investigate how Neutron might participate by requesting live-migratable ports. 2. Preemptive live migration failure for non-migratable PCI devices Nova currently checks for migratability during scheduling and conductor phases. There’s a proposal to move these checks earlier, possibly to the API level. Bug: https://bugs.launchpad.net/nova/+bug/2103631 ✅ Confirm with gmann whether a microversion is needed — likely not, as return codes are already supported (202 → 400/409). ✅ Uggla may submit a small spec to formalize this change. ✅ Split the work into two steps: - Fix existing bug (can be backported). - Incrementally move other validations earlier in the flow. 3. PCI SR-IOV: Unify the Live Migration Code Path There’s agreement on the need to reduce technical debt by refactoring the current dual-code-path approach into a unified model for PCI live migration. ✅ A dedicated spec is needed to clarify and unify PCI claiming and allocation. ✅ This refactor should address PCI claiming and allocation, potentially deprecating or replacing move_claim in favor of more robust DB-backed logic. ✅ This effort is directly related to point 1 (migratability awareness) and will help ensure consistent resource management across the codebase. #### SPICE VDI – Next Steps #### There is an ongoing effort to enhance libvirt domain XML configuration for desktop virtualization use cases (e.g. SPICE with USB and sound controllers). Some patches were proposed but not merged in time for Epoxy. Mikal raised the question of whether a new spec would be required in Flamingo, which would be the third iteration of this work. The team also raised concern about the complexity of adding traits (e.g. os-traits) for relatively simple additions, due to the multi-step process involved (traits patch, release, requirements update, etc.). ✅ Proceed with a specless blueprint. ✅ Plan to pull os-traits and os-resource-classes logic into Placement, to simplify the integration process and reduce friction. Link the required Placement version in Nova documentation accordingly. This is a strategic direction, even if some traits might still be shared with Neutron/Cinder. #### Virtiofs Client Support #### The virtiofs server-side support was merged in Epoxy, but SDK and client-side support did not make it in time. The proposal is to merge both patches early in Flamingo and then backport to Epoxy. ✅ No concern with microversion usage here. ✅The ordering of microversion support patches across Nova, SDKs, and clients will be handled by respective owners. ✅ Uggla to track that each new microversion in Nova has a corresponding patch in SDK/client layers. ✅ Not directly related to virtiofs, but the new reset-state confirmation prompt in the client was noted and welcomed. #### One-Time-Use (OTU) Devices #### OTU devices are designed to be consumed once and then unreserved. There is a need to provide practical guidance on handling these cleanly, especially in notification-driven environments. Additionally, there's an important patch related to Placement behavior on over-capacity nodes: https://review.opendev.org/c/openstack/placement/+/945465 Placement currently blocks new allocations on over-capacity nodes — even if the new allocation reduces usage. This breaks migration from overloaded hosts. The proposed fix allows allocations that do not worsen (or improve) usage. Note: A similar OTU device handling strategy has been successfully used in Ironic. ✅ Provide an example script or tool for external OTU device cleanup, based on notifications. ✅ Agreement on the proposed Placement fix — it is operator-friendly and resolves real issues in migration workflows. ✅ We likely need to dig deeper into implementation and tooling for broader OTU support. #### Glance cross-project session #### Please look at glance summary. #### Secure RBAC – Finalization Plan #### Tobias raised concerns about incomplete secure RBAC support in Nova, particularly around default roles and policy behavior. Much of the groundwork has been done, but a number of patches still require review and finalization. ✅ Gmann will continue working on the outstanding patches during the Flamingo cycle. The objective is to complete secure RBAC support in Nova as part of this cycle. #### Image Properties Handling – DB Schema & API Response #### The issue arises from discrepancies between image property metadata stored by Nova and what is received from Glance. Nova’s DB schema enforces a 255-character limit on metadata keys and values, which can lead to silent truncation or hard failures (e.g., when prefixing keys like image_ pushes the total length over 255). Nova stopped supporting custom image properties nearly a decade ago, when the system moved to structured objects (ImageMetaProps via OVO). Glance still allows some custom metadata, which may be passed through to Nova. This led to invalid or non-standard keys (e.g., owner_specified.openstack.sha256) being stored or exposed, even though they are not part of Nova’s supported set. Consensus emerged that we are facing two issues: - Nova's API may expose more metadata than it should (from Glance). - Nova stores non-standard or overly long keys/values, resulting in silent truncation or hard DB errors. ✅ Nova should stop storing non-standard image properties altogether. ✅ A cleanup plan should be created to remove existing unused or invalid metadata from Nova's database post-upgrade. ✅ During instance.save(), Nova should identify and delete unused image_* keys from the system metadata table. ✅ We must be cautious to preserve snapshot-related keys that are valid but not part of the base ImageMetaProps. ✅ These changes are considered bugfixes and can proceed without a new spec. #### Eventlet removal #### Please read the excellent blog post series from Gibi here: https://gibizer.github.io/posts/Eventlet-Removal-Flamingo-PTG/ #### Enhanced Granularity and Live Application of QoS #### This was cross team Neutron/Cinder/Nova first topic. Bloomberg folks presented early ideas around making QoS settings more granular and mutable, and potentially applicable to existing ports or VMs, not just at creation time. Nova does not operate on multiple instances at once, which conflicts with some proposed behaviors (e.g., live update of QoS on a network/project level). QoS is currently exposed via flavors in Nova, and is only supported on the frontend for the Libvirt driver. QoS mutability is non-trivial, with implications for scheduling, resource modeling, and placement interactions. The scope is broad and would require cross-project collaboration (Neutron, Cinder, Placement). Use cases and notes from Bloomberg: https://etherpad.opendev.org/p/OpenStack_QoS_Feature_Enhancement_Discussion ✅ Use flavor-based modeling for QoS remains the Nova approach. ✅ Nova should not apply policies across many instances simultaneously. ✅ A spec will be required, especially if new APIs or behavior modifications for existing VMs are introduced. The spec should provide concrete use case examples and API design proposals, including expected behavior during lifecycle operations (resize, rebuild, shelve, etc.). ✅ Max bandwidth adjustments may be possible (as they don’t require reservations), but broader mutability is more complex. ✅ Neutron and Cinder raised no objections regarding Bloomberg’s use cases and proposals. However, please look at Neutron and Cinder's respective summaries. #### Moving TAP Device Creation from Libvirt to os-vif #### This change proposes moving the creation of TAP devices from the Libvirt driver into os-vif, making it more consistent and decoupled. However, it introduces upgrade and timing considerations, especially regarding Neutron and OVN behavior. Bug: https://bugs.launchpad.net/nova/+bug/2073254 Patch: https://review.opendev.org/c/openstack/nova/+/942786 ✅ Neutron team is open to adjusting the timing of the "port ready" event, which could eliminate the need for Nova-side hacks. ✅ Sean will proceed with the patch and verify behavior through CI. #### Instance Annotations, Labels & K8s-Like Semantics #### Sean proposed introducing a mechanism similar to Kubernetes annotations and labels in Nova, to: - Express user intent regarding instance behavior (e.g., "should this instance be migrated?") - Convey lifecycle preferences to external tools like Watcher and Masakari - Expose capabilities or constraints of an instance (e.g., "cannot be shelved because it has a vTPM") Proposed Examples of Instance Annotations: lifecycle:live-migratable=true|false ha:role=primary|secondary These would be: - Set by users (or operators) - Optionally inherited from flavors (but conflicts would raise 400 Bad Request) - Expressed intent only — not enforcement of policy In addition, labels generated by Nova could reflect actual capabilities, like: lifecycle:live-migratable=false if an instance has a PCI device lifecycle:shelvable=false if it uses vTPM ✅ Define a new API to expose capabilities of instances (e.g., “can this instance be live-migrated?”) Values will be derived by Nova based on configuration/hardware and exposed via nova server show. ✅ Sean will create a spec. ✅ Looking at user-defined labels, we eventually considered defining a second API for them to express scheduling/HA preferences. However we decided the current preferred approach is to start with metadata API, and evolve to a first-class model. We may need admin-only metadata (e.g., for HA tooling like Masakari) this has been discussed in Admin-Only Instance Metadata / Annotations later point. ✅ Sean will also create a spec for this. (Sean). #### External Traits and Node Pressure Metrics #### Sean also proposed allowing external systems (e.g., Watcher, telemetry agents) to annotate compute nodes with traits such as memory/cpu/io pressure, based on /proc/pressure. Examples: CUSTOM_MEM_PRESSURE=high EXTERNAL_IO_PRESSURE=moderate ✅ Support a COMPUTE_MEM_PRESSURE-like trait, populated from sysfs as static info (not dynamic). ✅ A weigher could use these traits to influence placement.Default traits list could be configured (e.g., prefer/avoid hosts with certain pressures or hardware features). This approach could evolve into a generic “preferred traits” weigher, similar to Kubernetes taints/tolerations. ✅Sean will create a dedicated spec for this feature. ✅ Sbauza volunteered to help, especially as the work aligns with weigher logic from the previous cycle. #### OpenAPI Schema Integration #### Stephen highlighted that most of the heavy lifting for OpenAPI support is now complete, and the work is down to pure response schema definitions. This effort spans over three cycles now, and it would be valuable to finalize it early in Flamingo. ✅ We'll formalize this work with a blueprint. ✅ The goal is to make early progress in Flamingo, ideally with a dedicated review day. ✅ Stephen is happy to join synchronous review sessions and will coordinate pings for progress. ✅ Masahito volunteered to help with the remaining work. #### OpenStack SDK & Client Workflows #### Stephen raised a few concerns regarding timing mismatches between SDK/OSC freezes and microversion patch merges in Nova. Some microversion support landed too late to be integrated in the SDK before the Epoxy freeze. Patches were sometimes missed due to lack of "depends-on" links or broken initial submissions. ✅ Uggla will follow up and finalize these patches early in the Flamingo cycle. #### Upstream Testing for PCI Passthrough and mdev Devices #### With IGB support merged in Epoxy, and vIOMMU enabled in some Vexxhost workers (thanks to dansmith), the opportunity exists to expand PCI testing upstream in Tempest. This would also benefit testing of one-time-use (OTU) devices. Finalizing mtty testing is a priority, as it helps ensure device support is consistent and regressions (like bug #2098892) are caught early. ✅ Bauzas will lead on wrapping up mtty testing. ✅ Gibi will coordinate with cloud providers to assess Epoxy support and revisit this topic during the next PTG if needed. #### CPU Power Management – Expected Behavior #### Melanie raised questions about inconsistencies between design and implementation in Nova’s CPU power management logic. In particular: - CPUs were being offlined too aggressively, sometimes during reboot or migration operations. - This contradicts the intent that only unassigned or deallocated cores should be powered off. There was confusion between two approaches: - Aggressive power-down of unused CPUs during all idle states (stop, shelve, etc.) - Conservative behavior, powering off cores only when the VM is deleted or migrated away Consensus favored the aggressive-but-safe model: - Power down cores only when not used, e.g., VM is stopped or migrated. - Be cautious not to power off cores prematurely (e.g., during reboot or verify-resize). ✅ Do not rush to power off CPU cores at compute startup or mid-operation. ✅ Revisit the implementation so the resource tracker runs first, and determines actual core assignments before making decisions. #### Live Migration with Encrypted Volumes (Barbican Integration) #### HJ-KIM raised the point that Nova does not currently support live migration of instances using encrypted Cinder volumes managed by Barbican. This is a critical blocker in environments with strict compliance requirements. ✅ This is a parallel issue to vTPM support. We will learn from the vTPM implementation and consider applying similar concepts. ✅ A future solution may involve adjusting how ownership is managed, or providing scoped access via ACLs. ✅ Further discussion/spec work will be needed once an implementation direction is clearer. #### Manila–Nova Cross-Team Integration #### The initial Manila–Nova integration is now merged — thanks to everyone involved! The next step is to: - Add automated testing (currently manual tests only). - Start with a few basic positive and negative test scenarios (create, attach, write, delete; snapshot and restore; rule visibility; restricted deletion; etc.). Additionally, longer-term features and improvements are being considered please look at the etherpad. ✅ We will work on tempest tests. ✅ We will continue enhancing Nova–Manila integration during Flamingo (F) and beyond. ✅ Uggla will submit a spec as needed for land memfd support. #### Provider Traits Management via provider.yaml #### 📌 Spec: https://review.opendev.org/c/openstack/nova-specs/+/937587 Problem: Traits defined in provider.yaml are added to Placement but never removed if deleted from the file. ✅ Implement a mechanism where Nova copies the applied file to /var/lib/nova/applied_provider.yaml, and diffs it with the active one on restart. This would allow traits (and possibly other config) to be safely removed. #### Admin-Only Instance Metadata / Annotations #### 📌 Spec: https://review.opendev.org/c/openstack/nova-specs/+/939190 Issue: Current instance metadata is user-owned, and shouldn't be used by admins. Proposal: Introduce admin-only annotations (or metadata with ownership tracking), allowing operators to set system-visible metadata without violating user intent. ✅ Introduce a created_by field (similar to locked_by) to track who created metadata: user vs admin. Consider an admin: prefix namespace for admin-controlled keys (applied to annotations or metadata). Implementation requires a DB change and a nova-spec. Note: This aligns well with broader annotation work already discussed in this cycle. #### delete_on_terminate for Ports (Server Create / Network Attach APIs) #### 📌 Related discussion: https://review.opendev.org/c/openstack/nova-specs/+/936990 Background: This was discussed in past PTGs. Currently, delete_on_terminate can't be updated dynamically across instance lifetime. ✅ A spec with a working PoC will help clarify the desired behavior and unblock the discussion. Long-term solution may require storing this flag in Neutron as a port property (rather than Nova-specific DB). #### Graceful Shutdown of Nova Compute Services #### 📌 Spec: https://review.opendev.org/c/openstack/nova-specs/+/937185 Challenge: Need a mechanism to drain compute nodes gracefully before shutdown, without interrupting active workloads or migrations. Graceful shutdown is tricky in the presence of live migrations. Ideas include: - Temporary “maintenance mode” (block write requests). - Group-level compute draining. ✅ The topic is important but not urgent — bandwidth is limited. Note: Eventlet removal may simplify implementing this. ✅ Please report concrete bugs so we understand the blockers. ✅ A nova-spec with PoC would help drive the conversation. #### Libvirt/QEMU Attributes via Flavor Extra Specs #### Target: Advanced tuning of I/O performance via iothreads and virtqueue mapping, based on: https://developers.redhat.com/articles/2024/09/05/scaling-virtio-blk-disk-i… ✅ Introduce new flavor extra specs such as: - hw:io_threads=4 - hw:blk_multiqueue=2 These can be added to both flavor and image properties. ✅ A nova-spec should be written to document naming and semantics. #### Dynamic Modification of libvirt Domain XML (Hook Proposal) #### oVirt allows for plugins to alter the libvirt domain XML just before instance launch (via VDSM hooks). Nova does not offer a mechanism to intercept or modify the domain XML, and the design explicitly avoids this. The desired use case involves injecting configuration that libvirt cannot currently represent, for example, enabling multiuser SPICE consoles. ✅ This proposal is explicitly rejected. ✅ Nova will not support hook points for permuting libvirt XML. ✅ Operators may use out-of-band libvirt/qemu hooks at their own risk, but should not expect upstream support or stability guarantees. #### Revisiting the "No More API Proxies" Rule #### Masahito proposed allowing users to filter instances via API based on related service data, such as network_id. ✅ The "no API proxy" rule remains, but with pragmatic exceptions: - Filtering is acceptable if the data exists in Nova’s DB (e.g., network ID, image ID). - No cross-service REST calls allowed (e.g., Neutron QoS types still out of scope). - Filtering by network_id in nova list is reasonable and can proceed. ✅ Masahito will provide a spec. #### OVN Migration & Port Setup Timing #### 📌 Context: https://bugs.launchpad.net/nova/+bug/2073254 In OVN-based deployments, Neutron signals the network-plugged event too early, before the port is fully set up. This causes issues in live migration, especially under load. ✅ Nova already supports waiting on the network-plugged event. OVN in Ubuntu Noble should behave properly. A proposal to improve timing in Neutron was discussed (Neutron to wait for port claim in southbound DB). Nova might support this via a Neutron port hint that triggers tap interface creation earlier during migration (pre-live-migration). ✅ Next step: open an RFE bug in Neutron. If accepted, a Nova spec may be needed. #### Blocking API Threads During Volume Attachments #### 📌 Context: https://bugs.launchpad.net/nova/+bug/1930406 Volume attachment RPC calls block API workers in uWSGI, leading to starvation when multiple attachments are made in parallel. ✅ Volume/interface attachments should become async, reducing API lock contention. Fix is non-trivial and will require a microversion. In the meantime, operators may tune uWSGI workers/threads or serialize attachment calls. #### Inventory Update Failure – DISK_GB Bug #### 📌 Bug: https://bugs.launchpad.net/nova/+bug/2093869 When local storage becomes temporarily unavailable (e.g., Ceph down), Nova sends total=0 for DISK_GB, which Placement rejects if allocations exist. ✅ The real fix is to restore the storage backend. Nova should improve error handling/logging, but should not shut down the compute service. #### Security Group Name Conflict Bug #### 📌 Bug: https://bugs.launchpad.net/nova/+bug/2105896 When multiple security groups share the same name (via Neutron RBAC), instance builds can fail due to incorrect duplicate detection logic. ✅ The issue was fixed in: https://review.opendev.org/c/openstack/nova/+/946079 ✅ Fix will be reviewed and backported to Epoxy. If you've read this far — thank you! 🙏 If you spot any mistakes or missing points, please don't hesitate to let me know. Best regards. René.

2 1

[manila] 2025.2 Flamingo PTG summary
by Carlos Silva 17 Apr '25

17 Apr '25

Hello Zorillas and interested stackers, Last week's PTG had plenty of topics and good takeaways. In case you would like to watch any of the discussions, please take a look at the videos in the OpenStack Manila Youtube channel [0]. The PTG etherpad has all of the notes we took [9]. Here is a summary of the discussions grouped by each topic: Retrospective ========== Highlights ------------- Mid cycle alongside feature proposal freeze provided a good opportunity for us to have collaborative review sessions and move faster on reviews. Two bugsquashes had a good impact on the bug backlog and the bug trend was more positive on this cycle, despite the numbers growing due to low-hanging-fruits we started reporting. Internships with City University of Seattle, Valencia College and North Dakota State University - they are definitely helping with progress on manila-ui and OpenAPI. We will continue the effort. We would like to speed up reviews and improve our metrics [1] on how long changes are open before being merged. Review dashboards can help and we can work with our reviewers to have a more disciplined approach on reviews. Broken third party CI systems currently mean that we have little testing. We need to rely on the authors' or their peers to test and ensure that a feature is working. We will look into documenting CI setup procedures and gather thoughts from maintainers. New API Features should be tested as early as possible to ensure it won't break any workflows. Our contributor documentation will be updated with extra guidelines. AIs: (carloss) Encourage Bug Czar candidates and bring this up more often in the manila weekly meetings (carloss) Encourage spec authors to schedule a meeting to discuss the spec to speed up the review process. (carloss) include iCal with event announcements (bugsquash / mid cycle) (gouthamr) Creating a review dashboard (carloss) Record "expert seminars" on FAQs: it would be great to have some videos documenting how-tos in OpenStack and help people to unblock themselves when they are hitting common openstack-developer issues: https://etherpad.opendev.org/p/manila-howcasts (carloss) communicate a deadline for the manila CLI -> OSC documentation changes. The work with our interns should go until FPF. It needs to be done before the client release, when we are planning to drop the manilaclient support. ashrodri offered help to get it completed after we come to the FPF deadline. (carloss) We should update these docs and mention that first party driver implementations should be done for features and be more strict about the testing requirements. All things CephFS [2] ================ Deprecation of standalone NFS-Ganesha ------------------------------------------------------- We added a warning in Dalmatian, deferred plans to deprecate based on community feedback. Our plan is to remove it in the 2026.1 release. There is a suggested update procedure, please reach out in case there are questions. AI: (carloss) send a reminder email in this cycle to incentivize people to move to clustered NFS Supporting NFSv3 for Windows workloads -------------------------------------------------------- manila-tempest-plugin now supports multiple NFS protocol versions in one of the scenario tests. As soon as we get the build, we will update the CephFS NFS job to run tests for NFSv3 as well. Testing and stabilization -------------------------------- Bumped Ceph version in the CI jobs to Reef in Antelope, Bobcat, Caracal, Dalmatian. We are starting to test with Ceph Squid; we intend to test with Squid on "master" and "stable/2025.1" (epoxy) branches. A couple of Ceph and NFS-Ganesha issues are impacting us at the moment [4] [5] [6] and we managed to find the workaround for some. We needed to stop testing with ingress daemon at the moment and we will get back to testing as soon as the fix is out. Manage unmanage of shares and snapshots ----------------------------------------------------------- Feature is merged and working and we are going to backfill tempest test patches AI: (carloss) will propose a new job variant to allow testing this feature. Plans for 2025.2 Flamingo ----------------------------------- Investigate support for SMB/CIFS Ceph-NFS QoS: we will follow the implementation of this feature in NFS Ganesha and start discussing and drafting the Manila implementation when the code is merged in Ganesha upstream. Out of place restores and backup enhancements [7] ======================================== CERN is pursuing a backup backend with their C-Back tool. Currently Manila backups can be restored back to the same share; there are some problems with such approach when the source share backend is down and to prevent browse by restore behavior. Zachary Goggins (za) proposed a specification, and plans to work on it during the Flamingo Cycle. The share backups feature also needs some enhancements like a get progress and get restore progress actions. Zach plans to make it part of the implementation. We agreed that a backup resource should have a new "state" attribute, instead of only relying on the status in order to have well defined backup states. AI: (za) update the out of place restore spec. Tech debt ======= Container driver failures -------------------------------- The container driver tempest tests are perma-failing right now. We seem to have a problem with RBAC and pre-provisioned tempest credentials. AIs: (carloss) Report a tempest bug to track the issues; (gouthamr) will propose a change to switch back to using dynamic credentials in our testing. DockerHub rate limits ----------------------------- We are only building an image in manila-image-elements. It's more pulls than pushes. Pushes happen very rarely. The kolla team has moved away from DockerHub as well. Zach offered help in case we need another approach for registry. CERN has its own tool. AI: we will look into moving to quay.io "manila" CLI removal ---------------------------- We added the deprecation warning 6 releases ago and we should proceed with the removal. We will need an additional push to update all of our documentation examples and move to keystoneauth. We need more functional test coverage and we should have a hackathon just as we did some years ago. AI: carloss will schedule a hackathon for enabling more tests and send the removal email to openstack-discuss. We are targeting the removal to 2025.2 Flamingo. CI and testing ------------------ ZFSOnLinux job left on jammy: We created a bug for it and we can use it for tracking. IPv6 testing: The BGP software we were using (quagga) is now deprecated and everything was migrated to FRR. We will need help to fix it as unfortunately, things didn't have a 1x1 translation between the libraries. If someone has experience on this, it would be nice to collaborate to get this fixed. API ---- We are going to stop testing the v1 API and stop deploying it on DevStack test jobs. We'll update the install guide as well that we've stopped supporting it. It was deprecated in 2015 ("Liberty" release). That's a good code cleanup opportunity. V2 is an extension of v1 with microversions. If we stop supporting it, who is affected? Mostly people that have automations using it. What's the impact on manila-tempest-plugin? We have v1 and v2 tests. We have a lot of coverage for v2. If you don't have the v1 API in the cloud, the tests refuse to run. We will need to fix it. AIs: Work on the removal patches during the 2025.2 Flamingo release; (carloss) will send an announcement email to the ML, including operators tag. Manila UI ------------- We have been making progress in the Manila UI feature gap. Currently working on manage/unmanage share servers, manage share with dhss=true, filtering user messages on date, updating quotas table. Share limits view broke some time ago, code lives in horizon. We hit some issues using horizon's tox "runserver" environment, apparently more people ran into the same issue. We will talk to other impacted parties and check how to overcome this issue. AI: (carloss) will reach out to the horizon team and ask how we can re-introduce Manila limits to the overview tab. Enable share encryption at-rest (back-end) with secret refs stored on Barbican/Castellan. [8] ===================================================================== We merged a specification some time ago with an implementation architecture. That spec contemplated both Share encryption and Share server encryption. NetApp is now planning to work only on share server encryption. Encryption can be disabled per share, but shares exported via a share server cannot have a separate encryption key on ONTAP. We reached an agreement that when a new share creation is triggered, if there isn't a share server matching the provided key, a new share server will need to be spawned. We also agreed that we should allow using names for the secret reference for better user experience. 2025.2 Flamingo is the target release. AIs: (kpdev/Sai) The spec will be updated and only the DHSS=True scenario will be documented; The manila team will review the spec as soon as it is proposed Replication Improvements ==================== Back when we implemented replication, we didn't account for specific configurations that the storage backends can have, for example whether the backend could support zero RPO technologies or not. Zero RPO is is an important feature that allows data to be written simultaneously between the share and its replicas. We agreed that the way we should send the information to the backend is through a backend specific share type extra spec. Administrators will be able to define it in the share type and the backend will pick it up. Operator concerns / questions ======================= Where to put parameters that change behaviour only of one protocol (NFS in this case)? We agreed that we should have write once type of metadata and not allow the metadata to be updated afterwards. A configuration option can be introduced for this where the operator can determine what metadata will not be updated. AI: carthaca will propose a lite-spec for this Lustre FS Support for HPC Use Cases in OpenStack Is there any possibility for OpenStack to officially integrate or support parallel file systems like Lustre, either through Manila or other components? We've heard in the past as a request from the scientific-sig group. Building a driver should be straightforward and it does not necessarily need to be in-tree, and it would be easier to maintain. This is a very good use case. This discussion will continue with the scientific-sig group. Replica / Snapshot Retention / Expiration Policy While replicas in Manila are designed to be continuously in sync with the active share, certain use cases — such as disaster recovery (DR) replicas or manually created replicas that are no longer needed — could benefit from lifecycle management. Replicas are continuously synced with the source share, so if they're "unused", they're there for some reason is the assumption. We had a spec a while ago about automating snapshots (creation and deletion) on schedule. It would be preferable that an external automation tool is used to achieve such behavior. Maybe openstack/mistral can be a good approach (Support for manila snapshots already exists on Mistral) Affinity/Anti-affinity spec updates ========================= This feature allows users to create share groups with affinity policies, which determine the affinity relationship between shares within the group. There was an open question about strategies of locking. We came to an agreement that we can use tooz, database or oslo. AI: (chuanm) will update the spec. Force deleting subnets ================= This is a feature that follows the ability to add multiple subnets to a share server. We should also be able to remove them. This spec is under review. We agreed that we should also implement the "check" mechanism before deleting the subnet. AIs: (sylvanld) will update the spec Eventlet removal ============= Need to remove wsgi uses, use oslo service's new Threading based backend instead for the ProcessLauncher, periodic tasks. Neutron is doing some work around periodic tasks and we can benefit from their learning. AI: Work on this in Flamingo, aiming for completion in 2026.1 cycle. Manila/Nova Cross-project session: VirtioFS ================================= VirtioFS implementation is now complete and we are looking at the next steps. We currently don't have CI testing the feature and the Manila team is planning to work on it during the 2025.2 Flamingo release. The nova team intends to drive the remaining SDK and OSC patches to completion during the 2025.2 Flamingo release. We also discussed some possible enhancements: mem_fs support, online attach and detach and live migration. These will take some time and the Nova team will work on such features gradually. AIs: (carloss) will share the test scenarios with the Nova team and ask for reviews and the Manila team will work on the implementation of the tests. (rribaud) will work on the remaining SDK patch and work on mem_fd support. [0] https://www.youtube.com/watch?v=MLXkBRhViS0&list=PLnpzT0InFrqADxXi_dtPqfWLt… [1] https://openstack.biterg.io/app/dashboards#/view/Gerrit-Backlog?_g=(filters…:'Gerrit%20Backlog%20panel%20by%20Bitergia. ',filters:!(('$state':(store:appState),meta:(alias:'Changesets%20Only',disabled:!f,index:gerrit,key:type,negate:!f,params:(query:changeset),type:phrase),query:(match:(type:(query:changeset,type:phrase)))),('$state':(store:appState),meta:(alias:Bots,disabled:!f,index:gerrit,key:author_bot,negate:!t,params:(query:!t),type:phrase),query:(match:(author_bot:(query:!t,type:phrase)))),('$state':(store:appState),meta:(alias:!n,disabled:!f,index:gerrit,key:project,negate:!f,params:(query:manila),type:phrase),query:(match_phrase:(project:manila)))),fullScreenMode:!f,options:(darkTheme:!f,useMargins:!t),query:(language:lucene,query:(query_string:(analyze_wildcard:!t,default_field:'*',query:'*',time_zone:Europe%2FMadrid))),timeRestore:!f,title:'Gerrit%20Backlog',viewMode:view) [2] https://etherpad.opendev.org/p/flamingo-ptg-manila-cephfs [3] https://bugs.launchpad.net/manila/+bug/2049538 [4] https://github.com/nfs-ganesha/nfs-ganesha/issues/1227 [5] https://tracker.ceph.com/issues/69214 [6] https://tracker.ceph.com/issues/67323 [7] https://review.opendev.org/c/openstack/manila-specs/+/942694 [8] https://etherpad.opendev.org/p/share-encryption-with-barbican-secret-ref [9] https://etherpad.opendev.org/p/flamingo-ptg-manila Thank you everyone that participated on the PTG! Best regards, carloss

1 0

[trove-dashboard][designate-dashboard] Stuck translation proposal jobs
by Dmitry 17 Apr '25

17 Apr '25

Hello, team. Wanted to bring your attention for stuck translation proposal jobs for both trove-dashboard and designate-dashboard (https://zuul.opendev.org/t/openstack/build/e6849eafd29c4ee78c57fff6a8768ac6 ,https://zuul.opendev.org/t/openstack/build/3489b918e89642a4a607665edd6a5d41) As I have found out this behaviour is caused by jobs running on Ubuntu Focal with Python 3.8. Is there anything can be done to fix this issue? Thanks.

3 2

[barbican] Cancel Weekly Meeting
by Mauricio Harley 16 Apr '25

16 Apr '25

Hello, everyone. Barbican current's PTL here. We need to cancel the weekly meeting that would happen on Monday the 21st. This is necessary since this day will be a public holiday in many countries in Europe. Looking forward to meeting you all on the Monday following: April the 28th. Best regards, Mauricio

1 0

[trove-dashboard][designate-dashboard] Stuck translation proposal jobs
by dcu995＠gmail.com 16 Apr '25

16 Apr '25

Hello, team. Wanted to bring your attention for stuck translation proposal jobs for both trove-dashboard and designate-dashboard (https://zuul.opendev.org/t/openstack/build/e6849eafd29c4ee78c57fff6a8768ac6 ,https://zuul.opendev.org/t/openstack/build/3489b918e89642a4a607665edd6a5d41) As I have found out this behaviour is caused by jobs running on Ubuntu Focal with Python 3.8. Is there anything can be done to fix this issue? Thanks.

1 0

[kolla-ansible][dalmatian]Apply a patch to fix a bug
by Franck VEDEL (UGA) 16 Apr '25

16 Apr '25

Hello, and first sorry for coming back with my problem. After 3 days of trying to resolve it (applying a patch to fix a known bug in Horizon), it's still not working. No changes have been made to the problematic file (workflows.py). First question: This link discusses the topic (« Patching Customization") https://docs.openstack.org/kolla/latest/admin/image-building.html But not in the one for version 2024.2: https://docs.openstack.org/kolla/2024.2/admin/image-building.html So maybe the method doesn't apply to Dalmatian. Second question: what is wrong with what I’m doing: https://review.opendev.org/changes/openstack%2Fhorizon~938238/revisions/1/p… patch Archive ZIP · 409 octets The patch is a zip file We can download it: c2cce40.diff.zip I create the directory : /home/user/PATCH/horizon My /etc/kolla/kolla-build.conf file is these 2 lines [DEFAULT] patches_path = /home/user/PATCH In this directory, we can list files: (I tried with the zip and the unzip file, the diff file) (venv) user1@pc1:~$ ll /home/user/PATCH/horizon/ total 24 drwxrwxr-x 2 user1 user1 4096 avril 14 09:14 ./ drwxrwxr-x 3 user1 user1 4096 avril 11 08:24 ../ -rw-rw-r-- 1 user1 user1 1093 déc. 25 03:01 c2cce40.diff -rw-rw-r-- 1 user1 user1 716 avril 14 09:12 c2cce40.diff.zip -rw-rw-r-- 1 user1 user1 716 avril 14 09:12 c2cce40.zip -rw-rw-r-- 1 user1 user1 13 avril 14 09:14 series The series file (the try with the zip file): (venv) user1@pc1:~$ more /home/user1/PATCH/horizon/series c2cce40.zip I also tried Without the zip extension I modify the file: /home/user/venv/share/kolla-ansible/ansible/roles/horizon/defaults/main.yml #################### # Docker #################### #horizon_image: "{{ docker_registry ~ '/' if docker_registry else '' }}{{ docker_namespace }}/{{ docker_image_name_prefix }}horizon" #horizon_tag: "{{ openstack_tag }}" # #horizon_image_full: "{{ horizon_image }}:{{ horizon_tag }}" horizon_image_full: "kolla/horizon:19.4.0 » The next command create a new docker image (horizon:19.4.0) Kolla-build -b ubuntu horizon No problem… I have a new image named horizon:19.4.0. I copy the image on my second computer (2 nodes in my test cluster) Next: kolla-ansible reconfigure -I multinode Everything works , the new image is used to build horizon containers. But no modification in the file (venv) user1@pc1:~$ docker exec -it horizon bash (horizon)[root@pc1 /]# more ./var/lib/kolla/venv/lib/python3.12/site-packages/openstack_dashboard/dashboards/project/networks/ports/workflows.py class UpdatePortSecurityGroupAction(sg_base.BaseSecurityGroupsAction): def _get_initial_security_groups(self, context): port_id = context.get('port_id', '') port = api.neutron.port_get(self.request, port_id) return port.security_groups No modification on the container, in the workflows.py file. What is wrong ? There's something I'm not doing right, but what? Do you have any ideas? I'm definitely not managing it. Thank you, really, if you have any ideas. Franck

3 3

[neutron] ML2/OVN vs ML2/OVS
by Nguyễn Hữu Khôi 16 Apr '25

16 Apr '25

Hello. I am going to deploy an openstack network for a DC. I would like to have some advice on choosing between them. Could you show me some pros and cons between them? About OVN, I don't see many articles about it. And How can I check traffic routes via which GW, I can check this via ha_state with OVS Thank you very much. Nguyen Huu Khoi

4 8

[heat][ptg][ops] Flamingo PTG summary
by Takashi Kajinami 16 Apr '25

16 Apr '25

Hello, Last week during the PTG the heat team gathered to discuss a few topics. Thank you all who attended the session and the valuable discussions. The details can be found in https://etherpad.opendev.org/p/apr2025-ptg-heat but I'll leave some summary. There are a few plans about which we want to ask for any feedback from operators so I'm adding [ops] tag here. 1. Eventlet removal During the session we reviewed the current global plan to remove/replace eventlet and discussed the plan to follow it in heat. Our current idea is to remove/deprecate unmaintained code first so that we can shrink the scope. At this moment we aim to deprecate and remove the following items. - Standalone heat-api and heat-cfn-api - These are deprecated due to deprecation of WSGI server implementation from oslo.service, which depends on eventlet. Users can run api server by external server mechanism such as mod_wsgi or uwsgi. - heat-all service - This is deprecated due to deprecation of WSGI server implementation from oslo.service, which depends on eventlet. We expect this is not really used in production - legacy engine - This was deprecated in favor of convergence. Note that removing this means we no longer support adopt/abandon/check feature. Question to operators: Does anyone have concern about deprecating/removing these items ? Please be aware that the current heat team is quite small and we need actual help to replace eventlet for these features. 2. CFN API We discussed the current status of heat-cfntool which heavily depends on unmaintained boto library. However we also agreed that replacing boto by boto3 requires some effort due to the fact that boto3 does not allow overriding endpoint quite easily. While we aim to deprecate CFN api, we agreed that we still have to asses the impact because CFN API is used for signaling by default. Question to operators: Is anyone using CFN API in any other use case than signaling ? For the first topic, if we don't hear any objections, we'll follow the plan to move the removal work forward. Thank you, Takashi -- Takashi Kajinami irc: tkajinam github: https://github.com/kajinamit launchpad: https://launchpad.net/~kajinamit

1 0

[ironic][ptg] 2025.2 (Flamingo) PTG Summary
by Julia Kreger 16 Apr '25

16 Apr '25

Greetings everyone! Last week Ironic had a wildly successful PTG! We averaged around fifteen attendees most days, we drew upwards of 22 attendees for most of Wednesday while we discussed a number of related topics around networking. Overall, networking aspects seem to show the most current interest. This is the result in a change in market ecosystem where vendors are less focused on SDN integrations, and also deliberate limitations inside of ironic in order to limit scope creep and still attempt to meet the majority of infrastructure operator requirements when the original networking multi-tenancy effort was executed back in 2015-2016. Other major topics were Eventlet, some operator feedback on quarks of features, which highlighted some possible bugs and areas for improvement. We also got into some areas which have been a bit contentious in the past, but we reached some reasonable compromises which allowed us to find better paths forward. Monday: We largely discussed where we were at and where we were going. To highlight, ironic-lib has now been retired. Redfish based Graphical Console support merged and we identified some more work was likely needed. Bootable Container support *and* support for artifacts from an OCI container registry support was also viewed as completed during the cycle which ultimately improves options to infrastructure operators who are operating in mixed environments or with mixed requirements outside of the classical "everything is a VM in OpenStack" context. We've improved the linting across the majority of project repositories. Out of band inspection rules likely need more work around ensuring data structures are what we expect, but otherwise we are re-affirming our deprecation of ironic-inspector as a standalone project. Work to support Kea as a DHCP backend has paused for now. The plan exists, but realistically the contributor working in that area has a different focus at the moment which is okay! Container based IPA steps also didn't make it into the Epoxy cycle release, but are almost done already in Flamingo. Schema validation and OpenAPI work is also still underway and we broadly expect this to merge into Flamingo. In-band disk encryption as part of the ``direct`` deploy interface also didn't make any forward progress due to shifting contributor priorities. As a note, the bootable container work did extend this as a possible option, however it remains unclear if that will solve the overall need for the contributor who did propose adding support for encrypted volumes to the ``direct`` interface. Efforts to find an alternative to TinyCore usage in CI also stalled out. Turns out is less of a trivial problem to make a super-low memory ramdisk, and other fixes to the build jobs improved general reliability in the meantime so it is less pressing. We also didn't make any progress on Project Mercury as it was likely framed to try and keep too many options open for operators while we also lost contributor velocity due to some CVE work this past cycle. Having discussed what we achieved, this allowed us to focus on key aspects contributors know they needed to focus on this next cycle. Networking was the biggest topic in this area. Promptly followed by eventlet removal. There was also a consensus that we needed to ensure we're working together a bit better, but also don't explicitly block any one aspect, as there is power in user/operator choice as well. Some possible interest was also expressed around extending network device firmware upgrades, further delineating/improving metrics, possibly supporting more of a "push" firmware update model which more vendors are adopting. We promptly shifted to CI, and discussed challenges and path forward. Generally, there is some interest in trying to make some of our job executions a bit more selective, and also to dial back our reliance upon integration scenario jobs. Overall, it is a broad area of work which will require some further discussion to try and frame an ideal future state. In this we also discussed Centos Stream 10, python versions, and ultimately possible paths forward to at least highlighting other options which may enable maintenance activities to ensure these cases work. Afterwards, we shifted to CI knowledge sharing later in the day outside of the PTG schedule, to help spread overall context among newer members of the team. Tuesday! We started Tuesday with the topic of supporting a use case desired by some operators wishing to "allocate" baremetal nodes into a state which, to Ironic signifies the node has been deployed. The use case behind that is a bit odder, more for research and academic cases where other tools may be desired to meet very specific requirements. The discussion yielded an operator in the scientific space which could benefit, so some ideas and a possible path was identified. Then we got into the world of eventlet and a mini-retrospective of the challenges and identification of future steps. What we thought would be simple, turned out to be the hardest problem. Ironic Python Agent, originally identified as a good candidate for an early eventlet migration, has turned out to be extremely difficult due to it's need to spawn it's own WSGI server late in the process. Upon further reflection; Ironic itself has this issue as well, because we actually have two places a WSGI server might be spun up: ironic-api (obviously) and the conductor when using json-rpc. It was clear that solving that technical problem was the first step in our migration. We found some examples of gunicorn used in this way; that may be what we look to for an initial prototype. We then spoke about node / hardware monitoring patterns that operators are using and interested in. Redfish based hardware supports sending a notification to a web service on a threshold violation so we discussed adding a listener into Ironic that could receive these and integrate this into the current hardware event notifications. We agreed that a spec would be necessary and we would craft one and proceed from there. Further improvements around making it easier for operators to separate monitoring/events of the services from the hardware itself was discussed but oslo_messaging does not allow for this type of split routing today. We spoke about looking further into ironic-prometheus-exporter to see how it could be configured to potentially support this separation. To wrap up Tuesday, we drifted into discussion of the serial console support which Ironic has today. In essence, there is quite a bit of room for possible improvement there and some operators who are not using Nova wouldn't mind this area to see attention moving forward. The broad idea is we might explore creation of a new interface which enables SSH connections to be proxied through to the IPMI Serial-over-LAN capabilities in a BMC. This distinctly would require IPMI, since there really is not a great answer to serial console/interface access with Redfish. Ultimately this may also mean we extend redfish to support an IPMI interface as well, which seems weird, but discussion was in broad agreement that this space has unique challenges where this makes sense. Some initial ideas were entered into an spec document for discussion and refinement as some of the interested parties are also on the perimeter of the Ironic project. Wednesday! Wednesday was our deep dive into networking! Our very first topic was focused on improving the capabilities around the intentional limitations which were encoded in Ironic's early multi-tenant networking work. The early work was mainly focused on ensuring tenant level isolation on to separate L2 domains, such as VLANs. In large part, this boils down to the mapping, scheduling, and ultimately the dynamic assembly of a port grouping (bonded interfaces). We came into this session with a specification document from a discussion which occurred a few weeks prior and there was general consensus in this option and discussion highlighted a few other intertwined aspects which need to be accounted for. We then dove into ACL support for Networking Generic Switch. Overall, consensus resulted. This discussion also highlighted a number of aspects we also likely need to keep in mind, and potentially may start best be described as overall needs for additional documentation. There are also some further discussions which may need to be revisited networking wise. Ultimately, this is very much an "integrated" use case which was only appealing to about half of the attendees, which is typical given the variety of use cases Ironic solves and is able to support. Then we reached the topic of Standalone Switch management. This quickly became a retrospective into why we didn't make progress with Mercury, and then drove into what are the real minimal requirements which would need to be taken into account. Some of the discussion revolved around questions which were semi-answered in the mercury plan itself, to try and provide enough overlap to generally be usable in more than one use model/case while also enabling or preventing fragmentation. This discussion also crossed over into support of DPUs and how to support them, in large part because the overall model is very different. Some discussion also sort of shifted into maybe merging and tools together. Ultimately this topic requires much more discussion, and to make solid progress on networking aspects we need to enable ourselves to move together in two directions at once, while not blocking each other. With this in mind, we're forming up into two sub-teams which will focus on each area with their own advocates/champions. The goal being to report back to the community each week in a quick update style of engagement. Thursday! Thursday marked our final day of PTG for Ironic. We started by wrapping up some of the networking discussions, in large part the focus on how to make progress. We used this time to identify our high level organizational plans, determine broad interest levels and ultimately outreach. One key aspect which was highlighted, is the initial primary focus for some will likely be making progress on eventlet before shifting gears into networking. We then shifted gears to discussing interest and requirements of mapping storage volumes to overall hosts via DPU devices, which somewhat crossed over into the networking topics. The broad idea was presented with a potential need to frame compound drivers around facilitating broadly different configuration actions. For example, directly via SSH to invoke commands, or for example update a CRD in a distinct OpenShift cluster. Overall, the discussion yielded that maybe invoking a CRD update was not worthwhile given the flux those areas can experience along with competing requirements. Ultimately this is an area in early discussion and would require investment in time and hardware to move forward, but there were really no objections to doing so if we could model and extend what already exists in a useful and applicable way. We then drifted back into networking with our next topic, bridging distinctly different types of fabric together. This was raised much more as a question to see if there was an interest/need and/or requirement. In essence, this is similar to the original l2gw project. A huge highlight of embracing or extending into a more ideal model is the reality that if this existed, it might not be necessary for VXLAN to be considered on the physical side. Discussions then shifted to improving servicing interactions. Servicing functionality was added to Ironic during one of the recent past development cycles to enable firmware upgrades to take place on deployed nodes. In discussion, it was highlighted that in the current model this could take five or more reboots to facilitate the deployment as the current mechanism is largely modeled on the use of agent heartbeats. The discussion shifted to how we could avoid this. And the obvious answer was "add a periodic". Then concerns over adding more periodic queries and jobs shifted the discussion into how we can address that challenge. Ultimately, this may end up with us in a better place for tasks which need to follow-up on state changes in hardware and revisit the state before proceeding with the next step to execute. As the final topic, we dove into deploy steps. This really boiled down to "how do I know what will occur" when I ask Ironic to do something along with "how do I know what occurred". Consensus reached that largely the key aspect to highlight back to the user is "what was done" or "what do we expect to be done" in terms of steps. An idea was raised to record this into node history, which is a historical record list of actions/errors to a node which has existed in Ironic for a number of cycles now, but is most useful if you're trying to figure out prior events without going to logs. Consensus was that doing it this way would be a "quick win". At some point, Ironic contributors also sat down and reviewed jammed outside of the PTG schedule to review/discuss and merge existing items sitting awaiting reviews. Overall, the week was extremely productive! Thanks to everyone who took part. Additional thanks to everyone who collaborated on this summary, and everyone who also helped push our project priorities published for this work cycle[3]. Please remember if you have action items to follow-up. And onward to Flamingo! - The Ironic Team [0]: https://etherpad.opendev.org/p/ironic-ptg-april-2025 [1]: https://review.opendev.org/c/openstack/ironic-specs/+/945642 [2]: https://review.opendev.org/c/openstack/ironic-specs/+/946723 [3]: https://specs.openstack.org/openstack/ironic-specs/priorities/2025-2-workit…

1 0