-
Story
-
Resolution: Done
-
Undefined
-
None
The design describes a `complianceConfig` field: https://github.com/open-cluster-management-io/enhancements/tree/main/enhancements/sig-policy/89-operator-policy-kind#operatorpolicy-syntax
For example, consider a situations where an upgrade to an operator is available, but will not be automatically approved by the controller: some users might want the policy to become NonCompliant so that they are specially alerted to the situation, but other users might only want to log the issue in a status message.
Currently, the implementation has some sections where an initial decision has been made, basically for a "default" behavior in these cases, but those spots should be adjusted to allow for the user to configure the behavior.
| Operator conditions | Allowed spec.complianceConfig value | Related resources(objects) | Root policy compliance |
|---|---|---|---|
| catalogSourceUnhealthy | Compliant (default) | catalog source only | Compliant if other resources are available |
| NonCompliant | All | NonCompliant if catalog is unhealthy | |
| deploymentsUnavailable | Compliant | deployment of operator only | Compliant if other resources are available |
| NonCompliant (default) | All | NonCompliant if deployment of operator is not available | |
| upgradesAvailable | Compliant (default) | upgrade of operator only | Compliant if other resources are available |
| NonCompliant | All | NonCompliant if upgrade option is available | |
