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

Make the BuildController respect OSImageURLs on MachineConfigs

XMLWordPrintable

    • Icon: Story Story
    • Resolution: Unresolved
    • Icon: Undefined Undefined
    • None
    • None
    • None
    • False
    • Hide

      None

      Show
      None
    • False
    • Not Selected
    • MCO Sprint 280
    • 0

      When Image Mode OpenShift was developed, we made the decision not to consume the OSImageURL and BaseOSExtensionsContainerImage fields from the given rendered MachineConfig, instead, we consume them directly from the machine-config-osimageurl ConfigMap. I don’t remember what the reason for this decision was, but nevertheless, it has created some technical debt that is finally coming due. This card aims to discuss the problem as well as potential solutions to remediate the issue.

      The Problem:

      The way the Build Controller currently determines what base OS and extensions it should use are that it reads the machine-config-osimageurl ConfigMap by way of the OSImageURLConfig object. This means that if one were to set the osImageURL field on a MachineConfig object, it will not be recognized by the Build Controller and will not be consumed. This same situation also applies to the BaseOSExtensionsContainerImage field. This also means that depending on how we implement dual-stream support, we may be unable to consume this field as well.

      The Solution:

      In this mode, the Build Controller will ignore the machine-config-osimageurl ConfigMap entirely. It will consume the values directly from the MachineConfig field. This comes with the benefit that we can remove all of the code from the Build Controller that reads this ConfigMap and can potentially reevaluate the helpers we wrote for it. However, this comes with the downside that the MachineOSBuild hash values will change because we consider the OSImageURLConfig object as a whole instead of the two fields that we care about the most. However, this could likely be worked around fairly easily.

      Other Thoughts:

      An assumption that the solution makes, especially for dual-stream support, is that the OSImageURL and BaseOSExtensionsContainerImage fields on the MachineConfig will be changed whenever a pool changes from one OS stream to another. Assuming this is the case, then Image Mode OpenShift will be able to seamlessly support dual-stream. If that is not the case, then the solution will require modification in order to support dual-stream.

              Unassigned Unassigned
              zzlotnik@redhat.com Zack Zlotnik
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

                Created:
                Updated: