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