Uploaded image for project: 'Docs for Red Hat Developers'
  1. Docs for Red Hat Developers
  2. RHDEVDOCS-5980

DOC: Ability to manage metadata on targetNamespace

XMLWordPrintable

    • devex docs #255 Apr 15-May 6, devex docs #256 May 6-May 27
    • 5
    • Documentation (Ref Guide, User Guide, etc.), User Experience
    • ---
    • ---

      1. Proposed title of this feature request
      Ability to manage metadata on targetNamespace

      2. What is the nature and description of the request?
      In OpenShift Container Platform 4, everything is API driven and therefore management via OpenShift GitOps approach is desired. Yet OpenShift Pipelines are owning and reconciling lots of items in .spec.targetNamespace making it hard to add custom information to the metadata for .spec.targetNamespace. Given that OpenShift GitOps does require labels and potentially annotation to be added and to keep them in place, it key that either OpenShift Pipelines stops reconciling those changes or does offer a way to manage custom metadata for .spec.targetNamespace.

      If custom metadata could me managed via .spec.targetNamespace it would allow to specify the same via TektonConfig and then have OpenShift Pipelines reconcile all changes and hence achieve the desired state.

      An alternative is to exclude metadata from the OpenShift Pipelines - Operator reconcile loop so that customization can be added and won't get reconciled and hence removed.

      3. Why does the customer need this? (List the business requirements here)
      In order to use OpenShift GitOps (or similar tooling) to manage OpenShift Container Platform 4, it's require to be able and customize metadata for namespaces and other objects. Therefore, even if OpenShift Pipelines - Operator assumes ownership of objects, it should allow custom metadata to be added to help with customization and integration of 3rd party tooling.

      For OpenShift GitOps to work, it's key that certain labels are applied on the namespace so permissions are being granted to the respective ArgoCD instance. Depending of the level of automation, additional metadata may be required to then apply the correct set of manifest respectively configuration.

      4. List any affected packages or components.
      OpenShift Pipelines

              mramendi Mikhail Ramendik
              mramendi Mikhail Ramendik
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

                Created:
                Updated:
                Resolved: