Develop Helm chart to manage LCM of NMState NodeNetworkConfigurationPolicy resources
In the context of [NMState unit introduction in Sylva](https://gitlab.com/sylva-projects/sylva-core/-/issues/1909), we need a custom Helm chart (similar to metallb-resources Sylva unit) to automate the lifecycle management of NMState resources — namely NodeNetworkConfigurationPolicy (NNCP) objects on workload clusters. The goal is to have this as part of the workload clusters values definition and apply changes to NMState resources by triggering an update with `./apply-workload-cluster.sh`.
The chart should:
- Create and update NMState resources based on Helm values (static routes, vlan interfaces on already created bonds or physical interfaces, bridge interfaces without IPs linked to vlans).
- Handle NMState resource cleanup gracefully, apply `state: absent` on NodeNetworkConfigurationPolicy objects and wait for successful removal of node network configuration before NodeNetworkConfigurationPolicy obkect deletion. Behavior documented [in NMState operator doc](https://nmstate.io/kubernetes-nmstate/user-guide/102-configuration.html#removing-interfaces).
### NMState resources to be handled for CAPO
(1) route
```yaml
apiVersion: nmstate.io/v1
kind: NodeNetworkConfigurationPolicy
metadata:
name: route-1
spec:
desiredState:
routes:
config:
- destination: 2.2.2.0/30
metric: 150
next-hop-address: 172.30.140.1
next-hop-interface: ens4
table-id: 254
```
(2) bridge
```yaml
---
apiVersion: nmstate.io/v1
kind: NodeNetworkConfigurationPolicy
metadata:
name: bridge-1
spec:
desiredState:
interfaces:
- name: br1
description: Linux bridge with ens4 as a port
type: linux-bridge
state: up
ipv4:
enabled: false
bridge:
options:
stp:
enabled: false
port:
- name: ens4
```
Note: don't permit configuring any bridge on primary ens3 interface since it will break the cluster.
### NMState resources to be handled for CAPM3
(1) route
```yaml
apiVersion: nmstate.io/v1
kind: NodeNetworkConfigurationPolicy
metadata:
name: route-1
spec:
desiredState:
routes:
config:
- destination: 2.2.2.0/30
metric: 150
next-hop-address: 172.30.140.1
next-hop-interface: bond0.2410
table-id: 254
```
(2) vlan
```yaml
apiVersion: nmstate.io/v1
kind: NodeNetworkConfigurationPolicy
metadata:
name: bond1-vlan1516
spec:
desiredState:
interfaces:
- name: bond1.1516
type: vlan
state: up
ipv4:
enabled: false
vlan:
base-iface: bond1
id: 1516
```
(3) bridge
```yaml
apiVersion: nmstate.io/v1
kind: NodeNetworkConfigurationPolicy
metadata:
name: bridge-br1516
spec:
desiredState:
interfaces:
- name: br1516
description: Linux bridge with bond1.1516 as a port
type: linux-bridge
state: up
ipv4:
enabled: false
bridge:
options:
stp:
enabled: false
port:
- name: bond1.1516
```
Note: don't permit configuring any bridge on primary node interface since it will break the cluster.
For CAPM3, schema values validation can be used to check that the values pushed by NMState are not conflicting with vlan and routes already configured inside:
- `cluster.capm3.networks`
- `cluster.control_plane.capm3.networks`
- `cluster.control_plane.network_interfaces`
- `cluster.machine_deployments.<md-name>.capm3.networks`
- `cluster.machine_deployments.<md-name>.network_interfaces`
issue