Uploaded image for project: 'OpenShift Builds'
  1. OpenShift Builds
  2. BUILD-565

Make builds v1 api optional

    XMLWordPrintable

Details

    • Optional Builds v1 API
    • False
    • None
    • False
    • OCPSTRAT-36OpenShift Optional Capabilities (Phase 4)
    • Not Selected
    • Done
    • OCPSTRAT-36 - OpenShift Optional Capabilities (Phase 4)
    • 100
    • 100% 100%
    • L

    Description

      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

      Attachments

        Issue Links

          Activity

            People

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

              Dates

                Created:
                Updated:
                Resolved: