Feature Overview

Today, the ConfigurationPolicy only allows for two complianceTypes:  musthave and mustonlyhave.  This Feature is to explore and enable additional complianceTypes to allow for further flexibility and address some odd behaviors with the existing types.

Further information can be found:

• https://github.com/open-cluster-management-io/enhancements/pull/131/files 
• https://github.com/JustinKuli/ocm-enhancements/blob/more-policy-compliance-types/enhancements/sig-policy/130-policy-merge-compliancetypes/README.md 
• https://gist.github.com/JustinKuli/bf9f97bb3916ac9b694f2e77bcecc5a0 

Goals

This Section: Provide high-level goal statement, providing user context
and expected user outcome(s) for this feature

Requirements

This Section: A list of specific needs or objectives that a Feature must
deliver to satisfy the Feature.. Some requirements will be flagged as MVP.
If an MVP gets shifted, the feature shifts. If a non MVP requirement slips,
it does not shift the feature.

(Optional) Use Cases

This Section:

Questions to answer

• ...

Out of Scope

• …

Background, and strategic fit

This Section: What does the person writing code, testing, documenting
need to know? What context can be provided to frame this feature?

Assumptions

• ...

Customer Considerations

• ...

Documentation Considerations

Questions to be addressed:

• What educational or reference material (docs) is required to support this
  product feature? For users/admins? Other functions (security officers, etc)?
• Does this feature have a doc impact?
• New Content, Updates to existing content, Release Note, or No Doc Impact
• If unsure and no Technical Writer is available, please contact Content
  Strategy.
• What concepts do customers need to understand to be successful in
  [action]?
• How do we expect customers will use the feature? For what purpose(s)?
• What reference material might a customer want/need to complete [action]?
• Is there source material that can be used as reference for the Technical
  Writer in writing the content? If yes, please link if available.
• What is the doc impact (New Content, Updates to existing content, or
  Release Note)?

-------------

Previous content:
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):

1. …

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>