Uploaded image for project: 'OpenShift Workloads'
  1. OpenShift Workloads
  2. WRKLDS-695

Make DeploymentConfig and BuildConfig apis optional

    XMLWordPrintable

Details

    • Optional DeploymentConfig and Build API
    • False
    • None
    • False
    • Not Selected
    • To Do
    • OCPSTRAT-118 - Deprecated deploymentconfig to deployments
    • OCPSTRAT-118Deprecated deploymentconfig to deployments
    • 100
    • 100% 100%
    • Workloads Sprint 236, Workloads Sprint 237, Workloads Sprint 238, Workloads Sprint 239, Workloads Sprint 240, Workloads Sprint 241, Workloads Sprint 242, Workloads Sprint 243, Workloads Sprint 244, Workloads Sprint 245, Workloads Sprint 246, Workloads Sprint 247, Workloads Sprint 248, Workloads Sprint 249

    Description

      Epic Goal

      • Make it possible to disable the DeploymentConfig and BuildConfig APIs, 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 or DeploymentConfig 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 DeploymentConfig or BuildConfig 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 deploymentconfig tests when the cap is disabled)
      • Release Technical Enablement - Provide necessary release enablement details and documents.
      • ...

      Dependencies (internal and external)

      1. Cluster install capabilities

      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::

      None

      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
              Rama Kasturi Narra Rama Kasturi Narra
              Votes:
              1 Vote for this issue
              Watchers:
              12 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: