-
Feature
-
Resolution: Unresolved
-
Major
-
None
-
None
Feature Overview
- OLM 1.0 needs to allow extensions to specify constraints towards aspects of the running cluster and other currently installed or future extensions.
- Aspects of the running cluster should include software version, resource utilization, overall resource availability, and state of configuration settings.
- These constraints need to be evaluated when extensions are attempted to be installed or updated.
Goals
- Extension vendors and publishers can rely on OLM 1.0 to enforce a support matrix at runtime and disallow/discourage users from running into unsupported setups
- Users will enjoy more reliable extensions by only running in supported setups that extension authors actually test and support
- Quick resolution of issues by disabling constraint evaluation
Requirements
| Requirement | Notes | isMvp? |
|---|---|---|
| Constraints can be expressed against “cluster properties” of the running cluster | Cluster properties include:
|
YES |
| Constraints can be expressed against any property of the running cluster | A property can come from any API/object that can read, e.g., * (any fields of) node spec:
spec: taints: - key: node-role.kubernetes.io/master effect: NoSchedule * (any of) node metadata.labels metadata: labels: beta.kubernetes.io/os: linux failure-domain.beta.kubernetes.io/zone: us-west-1a node.kubernetes.io/instance-type: m6i.xlarge kubernetes.io/os: linux topology.kubernetes.io/zone: us-west-1a failure-domain.beta.kubernetes.io/region: us-west-1 node.openshift.io/os_id: rhcos node-role.kubernetes.io/master: '' beta.kubernetes.io/instance-type: m6i.xlarge kubernetes.io/hostname: ip-10-0-158-231.us-west-1.compute.internal topology.kubernetes.io/region: us-west-1 beta.kubernetes.io/arch: amd64 kubernetes.io/arch: amd64 topology.ebs.csi.aws.com/zone: us-west-1a node-role.kubernetes.io/control-plane: '' |
NO |
| Dependency Resolution - hard constraint: Constraints can be expressed against arbitrary properties of extensions that must be installed along with the current extension |
This is the classical dependency resolution. Upstream doc: https://olm.operatorframework.io/docs/concepts/olm-architecture/dependency-resolution/#declaring-dependencies |
NO |
| Dependency Resolution - optional/soft constraint constraint: Constraints can be expressed against arbitrary properties of extensions that can optionally be installed later |
This is useful for optional/soft dependencies, these constraints are only evaluated once the targeted extension is present | NO |
| Constraint evaluation can be disabled by a force override | Useful as an escape hatch | YES |
| Constraints are evaluated before installation and updates of extensions | see OCPPLAN-9690 (F6), no state should be changed if constraint evaluation fails as part of an update | YES |
| Evaluated/violated constraints need to be clearly reported in the context of the extension that expressed the constraints | proper UI and API-level representation | YES |
| Constraints honor extension update policy | if a constraint would cause OLM to update a dependency but the dependency does not allow automatic update, the constraint resolution should fail | YES |
| CI - MUST be running successfully with test automation | This is a requirement for ALL features. | YES |
| Release Technical Enablement | Provide necessary release enablement details and documents. | YES |
Use Cases
Main use cases:
- An extension A expresses a constraint on cluster properties, e.g. cluster version, amount of nodes, node spec, etc,... disallowing the cluster admin to install/update the extension in a cluster running an older version of the software stack
- An extension A expresses a hard constraint on an extension B in regards to arbitrary aspects of it, e.g. its minimum version, causing OLM 1.0 to automatically install B when A is installed and automatically update B once A gets updated and changes the constraints, e.g. bump the minimum version dependency on B
- An extension A expresses optional constraints on extension B that, when B is installed or updated, will be enforced but will not be enforced when B is not present or uninstalled
- An SRE can quickly resolve a situation where OLM 1.0 is blocking install or upgrade of an extension, by using a force override switch that disables constraint evaluation
Background, and strategic fit
This is part of a larger effort to re-design vital parts of the OLM APIs and conceptual models to fit the use case of OLM in managed service environments, GitOps-controlled infrastructure and restrictive self-managed deployments in Enterprise environments. You can learn more about it here: https://docs.google.com/document/d/1LX4dJMbSmuIMn98tCiBaONmTunWR6zdUJuH-8uZ8Cno/edit?usp=sharing
Assumptions
- Extensions are handled at the cluster level
Relevant upstream CNCF OLM engineering brief(s):
Documentation Considerations
- Users need to be aware of the fact that constraints are evaluated at all times
- Users need to know that as part of constraint resolution, OLM 1.0 may install/update certain other extensions that are dependencies of an extension that is about to be installed/updated
- relates to
-
-
- Accepted
-
- split from
-
-
- New
-
