Uploaded image for project: 'Machine Config Operator'
  1. Machine Config Operator
  2. MCO-364

Hypershift future improvements

XMLWordPrintable

    • Icon: Epic Epic
    • Resolution: Unresolved
    • Icon: Normal Normal
    • None
    • None
    • Hypershift-MCO Improvements
    • False
    • None
    • False
    • Not Selected
    • To Do
    • 77% To Do, 8% In Progress, 15% Done
    • 0
    • 0

      This aims to track all cards not needed for 4.12 GA of Hypershift with upgrade in place, mostly improvements/enhancements on the minimal MVP.

       

      As of 4.13, the future plans is roughly as follows:

      1. getting HyperShift off bootstrap mode of operations for MCC and MCS
        1. This is relatively low gain for high effort, but will be eventually needed if we either a) implement layering or b) want to remove the MCS altogether
        2. Would require the MCO to have expanded support for regular operations
      2. implementing another way to rotate certs
        1. In Hypershift right now, the certs on-disk for the kubelet aren't rotated at all, so this isn't urgent (see https://issues.redhat.com/browse/HOSTEDCP-457)
        2. In the MCO, we want to move it out of the files path (see https://issues.redhat.com/browse/MCO-467)
      3. moving the Hypershift workflow closer to self-driving, via MCO-358 and others below
      4. implementing layering for Hypershift
        1. this is probably the heaviest changes if we want to make this happen
        2. for Hypershift, this would mean that the Hypershift operator would manage an image registry and builds/imagestreams for each of the hostedclusters it operates
        3. this would build from the base OS image shipped for each hostedcluster, and then build in all the base templates from that release for the environment, then any user customizations (MCs, KCs, CRCs via configmaps)
        4. the cluster admin could also override this if they wished
        5. the MCS would be reduced to a pull secret and the image to pivot to, replace upgrades would replace into the new image, inplace upgrades would leverage MCD/rpm-ostree to perform a direct pivot
        6. in the future, if we can boot directly into the container image instead, that would be ideal
        7. ideally if we want to move forward with this, we would want to do so in 4.15

              jerzhang@redhat.com Yu Qi Zhang
              jerzhang@redhat.com Yu Qi Zhang
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

                Created:
                Updated: