Uploaded image for project: 'Agent-based deployment for OpenShift Installer'
  1. Agent-based deployment for OpenShift Installer
  2. AGENT-385

Configure network interfaces interactively via the hardware console


    • Icon: Epic Epic
    • Resolution: Done
    • Icon: Critical Critical
    • openshift-4.13
    • None
    • None
    • None
    • Interactive Network Config
    • False
    • Not Selected
    • Done
    • OCPSTRAT-245 - Configure network interfaces interactively with agent-based installer
    • OCPSTRAT-245Configure network interfaces interactively with agent-based installer
    • 0% To Do, 0% In Progress, 100% Done
    • XL

      Epic Goal

      • Allow users to interactively adjust the network configuration for a host after booting the agent ISO, before starting processes that pull container images.

      Why is this important?

      • Configuring the network prior to booting a host is difficult and error-prone. Not only is the nmstate syntax fairly arcane, but the advent of 'predictable' interface names means that interfaces retain the same name across reboots but it is nearly impossible to predict what they will be. Applying configuration to the correct hosts requires correct knowledge and input of MAC addresses. All of these present opportunities for things to go wrong, and when they do the user is forced to return to the beginning of the process and generate a new ISO, then boot all of the hosts in the cluster with it again.


      1. The user has Static IPs, VLANs, and/or bonds to configure, but has no idea of the device names of the NICs. They don't enter any network config in agent-config.yaml. Instead they configure each host's network via the text console after it boots into the image.
      2. The user has Static IPs, VLANs, and/or bonds to configure, but makes an error entering the configuration in agent-config.yaml so that (at least) one host will not be able to pull container images from the release payload. They correct the configuration for that host via the text console before proceeding with the installation.

      Acceptance Criteria

      • CI - MUST be running successfully with tests automated
      • Release Technical Enablement - Provide necessary release enablement details and documents.
      • ...

      Dependencies (internal and external)

      1. ...

      Previous Work (Optional):

      Open questions::

      Done Checklist

      • CI - CI is running, tests are automated and merged.
      • Release Enablement <link to Feature Enablement Presentation>
      • DEV - Upstream code and tests merged: <link to meaningful PR or GitHub Issue>
      • DEV - Upstream documentation merged: <link to meaningful PR or GitHub Issue>
      • DEV - Downstream build attached to advisory: <link to errata>
      • QE - Test plans in Polarion: <link or reference to Polarion>
      • QE - Automated tests merged: <link or reference to automated tests>
      • DOC - Downstream documentation merged: <link to meaningful PR>

            afasano@redhat.com Andrea Fasano
            zabitter Zane Bitter
            zhenying niu zhenying niu
            0 Vote for this issue
            11 Start watching this issue


                Original Estimate - Not Specified
                Not Specified
                Remaining Estimate - 0 minutes
                Time Spent - 6 weeks