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

Support host-specific configurations at install time

XMLWordPrintable

    • Support host-specific configurations at install time
    • False
    • False
    • Green
    • Done
    • OCPPLAN-8150 - Agent-Based Installer GA
    • Impediment
    • OCPPLAN-8150Agent-Based Installer GA
    • 0% To Do, 0% In Progress, 100% Done
    • Hide
      You can configure the host name , network configuration in nmstate format, root device hints, and role in an Agent-based installation. For more information, see
      xref:../../installing/installing_with_agent_based_installer/preparing-to-install-with-agent-based-installer.adoc#root-device-hints_preparing-to-install-with-agent-based-installer[About root device hints].
      Show
      You can configure the host name , network configuration in nmstate format, root device hints, and role in an Agent-based installation. For more information, see xref:../../installing/installing_with_agent_based_installer/preparing-to-install-with-agent-based-installer.adoc#root-device-hints_preparing-to-install-with-agent-based-installer[About root device hints].
    • Feature
    • Done

      Epic Goal

      As an OpenShift infrastructure owner, I need to add host-specific configurations at install time, so that they are applied when the cluster installation is completed.

      Why is this important?

      Specially, but not restricted to on-prem deployments, hosts need specific configurations (beyond the individual host network configuration). Customers automating installs want to avoid day-2 configurations and node reboots, so applying configurations during the installation is a requirement for them. Examples of this are multipath and SCTP on bare metal nodes, where it's not always straightforward to do it on day-2 and reboots are required.

      Acceptance Criteria

      • An interface exists to pass host-specific configurations and it's documented
      • CI - MUST be running successfully with tests automated
      • Release Technical Enablement - Provide necessary release enablement details and documents.

      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>

              asegurap1@redhat.com Antoni Segura Puimedon
              racedoro@redhat.com Ramon Acedo
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

                Created:
                Updated:
                Resolved: