Feature Request Overview: What user goal or problem do you need to solve?
 
The current implementation of the OpenStackDataPlaneNodeSet CR assumes the control plane network, defined by the ctlplaneInterface parameter, is mapped to a single physical or virtual network interface controller (NIC/vNIC). Consequently, the operator automatically generates a networkData secret based on this single-interface assumption.
 
This design presents a significant limitation in environments requiring network high availability (HA). To configure a bonded interface for the control plane, a standard practice for production deployments. The workaround consists in pre-creating the networkData secret with the correct bond configuration. This manual intervention breaks the declarative infrastructure-as-code model, introduces a high potential for human error, and is not a scalable solution for deployments involving a large number of nodes.
 

Business justification and customer impact: How would this feature benefit the customer? 

• Enhanced Operational Efficiency: Automating bond configuration eliminates manual, error-prone steps during initial deployment and future scaling operations. This directly reduces deployment time and lowers the operational expenditure (OpEx) associated with managing the data plane.
• Improved Reliability and Resilience: The control plane network is a critical component for node management. Enabling native support for bonded interfaces aligns with industry best practices for network resilience, ensuring control plane connectivity is maintained in the event of a single link or switch port failure.
• Meeting Telco-Grade Requirements: This feature is a critical requirement for telecommunications customers deploying Red Hat OpenStack for telco workloads (e.g., vRAN, 5G Core). These deployments adhere to strict reference architectures, such as the Telco Network Cloud (TNC) Reference Architecture, which mandate bonded interfaces for control and management networks to guarantee carrier-grade uptime and robustness. The absence of this feature creates a significant adoption barrier for these key customers.
   

Functional requirements: What do you want the result of this feature to be? Add as many requirements as needed.
 
The OpenStackDataPlaneNodeSet CRD schema should be extended to declaratively manage a bonded interface for the control plane. This would likely involve introducing new fields within the spec that allow for defining a bond's configuration.

Functional Requirements: 

• Declarative Bond Configuration: The OpenStackDataPlaneNodeSet CR must allow a user to specify that the control plane interface is a bond.
• Bond Member Specification: The user must be able to define two or more member interfaces that will constitute the bond.
• Bonding Parameterization: The user must be able to configure essential bonding parameters, including, but not limited to:
  • Bonding mode (e.g., active-backup, 802.3ad)
  • Link monitoring configuration (e.g., miimon, arp_interval)
  • LACP rate
• Automated Secret Generation: The openstack-operator must be able to parse this bond configuration from the CR and automatically generate the correct, corresponding networkData secret that is then applied to the target nodes. The process should be fully automated, requiring no manual secret manipulation.

Secret data example:
# networkData
links:
- name: eno12399
id: eno12399
type: phy
ethernet_mac_address: "30:3E:A7:02:F6:00"
- name: eno12409
id: eno12409
type: phy
ethernet_mac_address: "30:3E:A7:02:F6:01"
- name: eno12419
id: eno12419
type: phy
ethernet_mac_address: "30:3E:A7:02:F6:02"
- name: eno12429
id: eno12429
type: phy
ethernet_mac_address: "30:3E:A7:02:F6:03"
- name: bond0
id: bond0
type: bond
bond_mode: 802.3ad
bond_links:
- eno12399
- eno12409
networks:
- link: bond0
id: bond0
type: ipv4
ip_address: 10.62.62.101
netmask: "255.255.255.0"
routes:
- network: 0.0.0.0
netmask: 0.0.0.0
gateway: 10.62.62.1
services:
- type: dns-nameserver
address:
- 10.62.62.85
search:
- ctlplane.osp.virtcwl.npss.bos2.lab

Feature Overview (mandatory - Complete while in New status)
An elevator pitch (value statement) that describes the Feature in a clear, concise way. ie: Executive Summary of the user goal or problem that is being solved, why does this matter to the user? The “What & Why”... 
<your text here>

Goals (mandatory - Complete while in New status)
Provide high-level goal statement, providing user context and expected user outcome(s) for this Feature

• Who benefits from this Feature, and how? 
• What is the difference between today’s current state and a world with this Feature?
  <your text here>

Requirements (mandatory -_ Complete while in Refinement status):
A list of specific needs, capabilities, or objectives that a Feature must deliver to satisfy the Feature. Some requirements will be flagged as MVP. If an MVP gets shifted, the Feature shifts. If a non MVP requirement slips, it does not shift the feature.

 
Done - Acceptance Criteria (mandatory - Complete while in Refinement status):
Acceptance Criteria articulates and defines the value proposition - what is required to meet the goal and intent of this Feature. The Acceptance Criteria provides a detailed definition of scope and the expected outcomes - from a users point of view
…
<your text here>
Use Cases - i.e. User Experience & Workflow: (Initial completion while in Refinement status):
Include use case diagrams, main success scenarios, alternative flow scenarios.
<your text here>
Out of Scope _ _(Initial completion while in Refinement status):
High-level list of items or persona’s that are out of scope.
<your text here>
Documentation Considerations _ _(Initial completion while in Refinement status):
Provide information that needs to be considered and planned so that documentation will meet customer needs. If the feature extends existing functionality, provide a link to its current documentation..
<your text here>
 
Questions to Answer _ _(Initial completion while in Refinement status):
Include a list of refinement / architectural questions that may need to be answered before coding can begin.
<your text here>
Background and Strategic Fit (Initial completion while in Refinement status):
Provide any additional context is needed to frame the feature.
<your text here>
Customer Considerations _ _(Initial completion while in Refinement status):
Provide any additional customer-specific considerations that must be made when designing and delivering the Feature.
<your text here>
Team Sign Off (Completion while in Planning status)

• All required Epics (known at the time) are linked to the this Feature
• All required Stories, Tasks (known at the time) for the most immediate Epics have been created and estimated
• Add - Reviewers name, Team Name
• Acceptance == Feature as “Ready” - well understood and scope is clear - Acceptance Criteria (scope) is elaborated, well defined, and understood
• Note: Only set FixVersion/s: on a Feature if the delivery team agrees they have the capacity and have committed that capability for that milestone

  Reviewed By	Team Name	Accepted	Notes