Uploaded image for project: 'OpenShift Container Platform (OCP) Strategy'
  1. OpenShift Container Platform (OCP) Strategy
  2. OCPSTRAT-748

On Cluster Layering: Phase 2 (tech preview)

    XMLWordPrintable

Details

    • Feature
    • Resolution: Unresolved
    • Critical
    • None
    • None
    • OS
    • False
    • Hide

      None

      Show
      None
    • False
    • Impediment
    • 49
    • 49% 49%
    • 0
    • 0
    • Program Call

    Description

      Note: phase 2 target is tech preview.

      Feature Overview

      In the initial delivery of CoreOS Layering, it is required that administrators provide their own build environment to customize RHCOS images. That could be a traditional RHEL environment or potentially an enterprising administrator with some knowledge of OCP Builds could set theirs up on-cluster.

      The primary virtue of an on-cluster build path is to continue using the cluster to manage the cluster. No external dependency, batteries-included.

      On-cluster, automated RHCOS Layering builds are important for multiple reasons:

      • One-click/one-command upgrades of OCP are very popular. Many customers may want to make one or just a few customizations but also want to keep that simplified upgrade experience. 
      • Customers who only need to customize RHCOS temporarily (hotfix, driver test package, etc) will find off-cluster builds to be too much friction for one driver.
      • One of OCP's virtues is that the platform and OS are developed, tested, and versioned together. Off-cluster building breaks that connection and leaves it up to the user to keep the OS up-to-date with the platform containers. We must make it easy for customers to add what they need and keep the OS image matched to the platform containers.

      Goals & Requirements

      • The goal of this feature is primarily to bring the 4.14 progress (OCPSTRAT-35) to a Tech Preview or GA level of support.
      • Customers should be able to specify a Containerfile with their customizations and "forget it" as long as the automated builds succeed. If they fail, the admin should be alerted and pointed to the logs from the failed build.
        • The admin should then be able to correct the build and resume the upgrade.
      • Intersect with the Custom Boot Images such that a required custom software component can be present on every boot of every node throughout the installation process including the bootstrap node sequence (example: out-of-box storage driver needed for root disk).
      • Users can return a pool to an unmodified image easily.
      • RHEL entitlements should be wired in or at least simple to set up (once).
      • Parity with current features – including the current drain/reboot suppression list, CoreOS Extensions, and config drift monitoring.

      Attachments

        Issue Links

          Activity

            People

              rhn-support-mrussell Mark Russell
              mkrejci-1 Michelle Krejci
              Charlie Doern, Colin Walters, Dalia Khater, David Joshy, John Kyros, Sinny Kumari, Zack Zlotnik
              Cheng Zhang Cheng Zhang
              Matthew Werner Matthew Werner
              Mrunal Patel Mrunal Patel
              Derrick Ornelas Derrick Ornelas
              Votes:
              0 Vote for this issue
              Watchers:
              12 Start watching this issue

              Dates

                Created:
                Updated: