User Story:

As an admin, I want to be able to:

• Provide 1 or more NMState configurations for the nodes

so that I can achieve

• All the nodes having persistent network interface configuration match the provided NMState Config

The agent based installation for Zero Touch provisioning has a Custom Resource Defined to configure the static networking of the nodes that will be provisioned. E.g:

apiVersion: agent-install.openshift.io/v1beta1
kind: NMStateConfig
metadata:
  name: mgmt-spoke1
  namespace: mgmt-spoke1
  labels:
    cluster-name: mgmt-spoke1
spec:
  config:
    interfaces:
      - name: bond0
        type: bond
        link-aggregation:
          mode: active-backup
          options:
            miimon: "140"
          slaves:
            - eth0
            - eth1
        state: up
        ipv4:
          enabled: true
          address:
            - ip: 192.168.123.151
              prefix-length: 24
          dhcp: false
        ipv6:
          enabled: false
    dns-resolver:
      config:
        server:
          - 192.168.1.1
    routes:
      config:
        - destination: 0.0.0.0/0
          next-hop-address: 192.168.1.1
          next-hop-interface: bond0
          table-id: 254
  interfaces:
    - name: "eth0"
      macAddress: "00:00:00:00:00:00"
    - name: "eth1"
      macAddress: "00:00:00:00:00:11"

NMState team is currently working on a rust library that includes the gc command that assisted service uses to generate all the configs and then load the one that matches the interfaces. We should reach out to ncarboni@redhat.com to check on assisted-service progress in integrating the new library and leverage the same code to make sure our ISO can use the same network configuration mechanism

Acceptance Criteria:

Description of criteria:

• Upstream documentation
• ZTP network config (NMStateConfig) can be passed to the CLI tool and ends up in the right nodes
• Test coverage for providing NMStateConfig for all nodes
• Test coverage for providing NMStateConfig for just the ephemeral provisioning service node.

(optional) Out of Scope:

Detail about what is specifically not being delivered in the story

Engineering Details:

• (optional) https://github/com/link.to.enhancement/
• (optional) https://issues.redhat.com/link.to.spike
• Engineering detail 1
• Engineering detail 2

This requires/does not require a design proposal.
This requires/does not require a feature gate.