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

Identify common interface for builder backends

XMLWordPrintable

    • Icon: Story Story
    • Resolution: Done
    • Icon: Normal Normal
    • None
    • None
    • None
    • 5
    • False
    • None
    • False
    • OCPSTRAT-35 - Layering ON Cluster Build: Dev Preview
    • 0
    • 0.000

      For maximum flexibility across a wide range of OpenShift cluster setups, the part of the Machine OS Builder which performs the actual OS image build will require multiple implementations. For example, in clusters which have the OpenShift Build API available, there should be an implementation which uses that. For clusters which do not have this capability available, there will be the need to manage our own build pod. To that end, we need a common interface between these OS image build backends so that one implementation can easily replace another.

       

      This card aims to handle figuring out what the necessary inputs are and defining a basic Go interface which can handle these cases. Here's an idea of what it could look like:

      // Holds info about a given container image such as where to pull / push it to / from as well as the pull secret to use.
      type ImageInfo struct {
          Pullspec       string
          PullSecretName string
      }
      
      // Holds the basic inputs needed to perform an OS image build.
      type OSBuildInput struct {
          Dockerfile            string
          BaseImage             ImageInfo
          FinalImage            ImageInfo
          EntitlementSecretName string
      }
      
      type BuildStatus string
      
      const (
          BuildStatusSuccess BuildStatus = "success"
          BuildStatusFailure BuildStatus = "failure"
          BuildStatusError   BuildStatus = "error"
      )
      
      // Holds info about the build status and outcome as well as a reference to the pod that is performing / performed the build.
      type OSBuildStatus struct {
          Status       BuildStatus
          Err          error
          PodReference *metav1.ObjectReference
      }
      
      // The interface to implement
      type MachineOSBuilderBackend interface {
          Build(*OSBuildInput) error
          Status() (*OSBuildStatus, error)
      }
      
      // A backend that uses OpenShift Builds
      type OpenshiftBuildBackend struct{}func (o *OpenshiftBuildBackend) Build(i *OSBuildInput) error {
          // Implement me!
          return nil
      }
      
      func (o *OpenshiftBuildBackend) Status() (*OSBuildStatus, error) {
          // Implement me!
          return nil, nil
      }
      
      // A backend that uses custom Pods.
      type CustomBuildBackend struct{}func (c *CustomBuildBackend) Build(i *OSBuildInput) error {
          // Implement me!
          return nil
      }
      
      func (c *CustomBuildBackend) Status() (*OSBuildStatus, error) {
          // Implement me!
          return nil, nil
      }
      
      // A backend that is optimized for single-node OpenShift
      type SingleNodeBuildBackend struct{}func (s *SingleNodeBuildBackend) Build(i *OSBuildInput) error {
          // Implement me!
          return nil
      }
      
      func (s *SingleNodeBuildBackend) Status() (*OSBuildStatus, error) {
          // Implement me!
          return nil, nil
      }
      
      // A dynamic way to detect which backend should be used.
      func GetBackend() MachineOSBuilderBackend {
          if isSNO() {
              return &SingleNodeBuildBackend{}
          }    if hasOpenshiftBuildCapability() {
              return &OpenshiftBuildBackend{}
          }    return &CustomBuildBackend{}
      }
       

       

      Done When:

      • We have a basic interface defined for interchangeable builder backends. Providing an implementation is out-of-scope for this card.
      • All new code is unit-tested using a FakeClient, where needed.
      • This has been merged into the master branch of the MCO. Note: Merging this as-is does not imply that it will be in the MCO's current execution path. However, tests will be executed in CI.

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

                Created:
                Updated:
                Resolved: