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



    • Epic
    • Resolution: Done
    • 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
    • 100
    • 100% 100%
    • 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>


        Issue Links



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



                Time Tracking

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