Skip to content

Latest commit

 

History

History
219 lines (200 loc) · 8.58 KB

creating-manifest-file-customized-br-ex-bridge.adoc

File metadata and controls

219 lines (200 loc) · 8.58 KB

Creating a manifest object that includes a customized br-ex bridge

As an alternative to using the configure-ovs.sh shell script to set a br-ex bridge on a bare-metal platform, you can create a MachineConfig object that includes an NMState configuration file. The NMState configuration file creates a customized br-ex bridge network configuration on each node in your cluster.

Consider the following use cases for creating a manifest object that includes a customized br-ex bridge:

  • You want to make postinstallation changes to the bridge, such as changing the Open vSwitch (OVS) or OVN-Kubernetes br-ex bridge network. The configure-ovs.sh shell script does not support making postinstallation changes to the bridge.

  • You want to deploy the bridge on a different interface than the interface available on a host or server IP address.

  • You want to make advanced configurations to the bridge that are not possible with the configure-ovs.sh shell script. Using the script for these configurations might result in the bridge failing to connect multiple network interfaces and facilitating data forwarding between the interfaces.

Note

If you require an environment with a single network interface controller (NIC) and default network settings, use the configure-ovs.sh shell script.

After you install {op-system-first} and the system reboots, the Machine Config Operator injects Ignition configuration files into each node in your cluster, so that each node received the br-ex bridge network configuration. To prevent configuration conflicts, the configure-ovs.sh shell script receives a signal to not configure the br-ex bridge.

Prerequisites

  • Optional: You have installed the nmstate API so that you can validate the NMState configuration.

Procedure

  1. Create a NMState configuration file that has decoded base64 information for your customized br-ex bridge network:

    Example of an NMState configuration for a customized br-ex bridge network
    interfaces:
- name: enp2s0 (1)
  type: ethernet (2)
  state: up (3)
  ipv4:
    enabled: false (4)
  ipv6:
    enabled: false
- name: br-ex
  type: ovs-bridge
  state: up
  ipv4:
    enabled: false
    dhcp: false
  ipv6:
    enabled: false
    dhcp: false
  bridge:
    options:
      mcast-snooping-enable: true
    port:
    - name: enp2s0 (5)
    - name: br-ex
- name: br-ex
  type: ovs-interface
  state: up
  copy-mac-from: enp2s0
  ipv4:
    enabled: true
    dhcp: true
  ipv6:
    enabled: false
    dhcp: false
# ...

    1. Name of the interface.

    2. The type of ethernet.

    3. The requested state for the interface after creation.

    4. Disables IPv4 and IPv6 in this example.

    5. The node NIC to which the bridge attaches.

  2. Use the cat command to base64-encode the contents of the NMState configuration:

    $ cat <nmstate_configuration>.yaml | base64 (1)

    1. Replace <nmstate_configuration> with the name of your NMState resource YAML file.

  3. Create a MachineConfig manifest file and define a customized br-ex bridge network configuration analogous to the following example:

    apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: worker (1)
  name: 10-br-ex-worker (2)
spec:
  config:
    ignition:
      version: 3.2.0
    storage:
      files:
      - contents:
          source: data:text/plain;charset=utf-8;base64,<base64_encoded_nmstate_configuration> (3)
        mode: 0644
        overwrite: true
        path: /etc/nmstate/openshift/cluster.yml
# ...

    1. For each node in your cluster, specify the hostname path to your node and the base-64 encoded Ignition configuration file data for the machine type. If you have a single global configuration specified in an /etc/nmstate/openshift/cluster.yml configuration file that you want to apply to all nodes in your cluster, you do not need to specify the hostname path for each node. The worker role is the default role for nodes in your cluster. The .yaml extension does not work when specifying the hostname path for each node or all nodes in the MachineConfig manifest file.

    2. The name of the policy.

    3. Writes the encoded base64 information to the specified path.