Uploaded image for project: 'OpenShift BuildConfig'
  1. OpenShift BuildConfig
  2. OCPBUILD-21

Make builds v1 api optional

XMLWordPrintable

    • Optional Builds v1 API
    • False
    • Hide

      None

      Show
      None
    • False
    • Not Selected
    • Done
    • OCPSTRAT-36 - OpenShift Optional Capabilities (Phase 4)
    • OCPSTRAT-36OpenShift Optional Capabilities (Phase 4)
    • 100
    • 100% 100%

      Epic Goal

      • Make it possible to disable the builds v1 api and associated controller logic

      Given the nature of this component (embedded into a shared api server and controller manager), this will likely require adding logic within those shared components to not enable specific bits of function when the build capability is disabled, and watching the enabled capability set so that the components enable the functionality when necessary.

       

      I would not expect us to split the components out of their existing location as part of this, though that is theoretically an option.

       

      Why is this important?

      • Reduces resource footprint and bug surface area for clusters that do not need to utilize the image building functionality, such as SNO and OKE.

      Acceptance Criteria (Mandatory)

      • CI - MUST be running successfully with tests automated (we have an existing CI job that runs a cluster with all optional capabilities disabled.  Passing that job will require disabling certain build tests when the cap is disabled)
      • Release Technical Enablement - Provide necessary release enablement details and documents.
      • ...

      Dependencies (internal and external)

      1. ...

      Previous Work (Optional):

      1. The optional cap architecture and guidance for adding a new capability is described here: https://github.com/openshift/enhancements/blob/master/enhancements/installer/component-selection.md

      Open questions::

      •  

      Done Checklist

      • Acceptance criteria are met
      • Non-functional properties of the Feature have been validated (such as performance, resource, UX, security or privacy aspects)
      • User Journey automation is delivered
      • Support and SRE teams are provided with enough skills to support the feature in production environment

            jchaloup@redhat.com Jan Chaloupka
            bparees@redhat.com Ben Parees
            Votes:
            0 Vote for this issue
            Watchers:
            7 Start watching this issue

              Created:
              Updated:
              Resolved: