Uploaded image for project: 'Red Hat Advanced Cluster Management'
  1. Red Hat Advanced Cluster Management
  2. ACM-1683

Adding support for a strategic merge option in Configuration Policies

XMLWordPrintable

    • Icon: Feature Feature
    • Resolution: Unresolved
    • Icon: Major Major
    • ACM 2.14.0
    • None
    • GRC
    • False
    • None
    • False

      Epic Goal

      • From time to time we have the issue that we need to update a Kubernetes-Object without removing previous content. Most important usecase maybe OpenShift-Authentication. When using MustOnlyHave you can replace the whole object (this helps), but we would like to have a better approach
      • Let's take the following example: We need to find a way to add a second provider into the same OAuth-config

                 oc get oauth -yaml

      [...]
      oauthConfig:
      assetPublicURL: https://<console-URL>:8443/console/
      grantConfig:
      method: auto
      identityProviders:
      - name: "my_ldap_provider"
      challenge: true
      mappingMethod: add
      login: true
      provider:
        apiVersion: v1
        kind: LDAPPasswordIdentityProvider
        attributes:
          id:
          - dn
          email:
          - mail
          name:
          - cn
          preferredUsername:
          - uid
        bindDN: "uid=param1,ou=people,dc=pune,dc=example,dc=com"
        bindPassword: "param1"
        ca:
        insecure: true
        url: "ldap://URI:389/dc=pune,dc=example,dc=com?uid?sub"
      - name: "2nd Ldap"
      challenge: true
      mappingMethod: add
      login: true
      provider:
        apiVersion: v1
        kind: LDAPPasswordIdentityProvider
        attributes:
          id:
          - dn
          email:
          - mail
          name:
          - cn
          preferredUsername:
          - uid
        bindDN: "uid=newera1,ou=people,dc=example,dc=com"
        bindPassword: "q"
        ca: /root/new.pem
        insecure: false
        url: "ldap://<URI-2>:389/dc=example,dc=com?uid?sub"
      [...]
      • This is a typical advanced feature.

      Why is this important?

       

      Scenarios

      1. ...

      Acceptance Criteria

      • CI - MUST be running successfully with tests automated
      • Release Technical Enablement - Provide necessary release enablement details and documents.
      • ...

      Dependencies (internal and external)

      1. ...

      Previous Work (Optional):

      Open questions::

      1. PRIO should not be too high as workaround is acceptable

      Done Checklist

      • CI - CI is running, tests are automated and merged.
      • Release Enablement <link to Feature Enablement Presentation>
      • DEV - Upstream code and tests merged: <link to meaningful PR or GitHub Issue>
      • DEV - Upstream documentation merged: <link to meaningful PR or GitHub Issue>
      • DEV - Downstream build attached to advisory: <link to errata>
      • QE - Test plans in Polarion: <link or reference to Polarion>
      • QE - Automated tests merged: <link or reference to automated tests>
      • DOC - Downstream documentation merged: <link to meaningful PR>

              showeimer Sho Weimer
              rhn-support-cstark Christian Stark
              Gus Parvin Gus Parvin
              Sho Weimer Sho Weimer
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

                Created:
                Updated: