Add enhancement proposal for cluster constraints and properties #96
Conversation
|
|
||
| ## Summary | ||
|
|
||
| The dependency resolution in OLM needs to work with cluster constraints in order to effectively install operators that will work properly in the cluster at runtime. Plus, OLM needs to support cluster properties which reflects the runtime information that the cluster may provide and allows operators to depend on those properties if needed to ensure proper installation and operation. |
There was a problem hiding this comment.
At this point, we don't know what a "cluster constraint" is. Could we define it up front?
This enhancement introduces a new mechanism for admins to provide cluster information as constraints and properties. Signed-off-by: Vu Dinh <[email protected]>
dinhxuanvu
force-pushed
the
provide-constraint
branch
from
5266c74 to
3a85fd6
Compare
| metadata: | ||
| name: cluster-constraints | ||
| spec: | ||
| constraints: '[{"type":"olm.constraint","value":{"evaluator":{"id":"cel"},"rule":"properties.exists(p, p.type == \"certified\")","message":"require to have certified property","action":{"id":"require"}}}]' |
There was a problem hiding this comment.
why a string and not a typed array?
|
|
||
| ### Cluster restriction | ||
|
|
||
| The cluster itself can impose certain restriction to which operators can be installed in the cluster via the properties associated with the operators. For example, the cluster imposes a minumum kubernetes version all for installable operators. A constraint can be constructed for a specific cluster restriction and then will be resolved during dependency resolution to ensure only operators with corresponding property with a satisfiable value. |
There was a problem hiding this comment.
I think it is more a "wording" thing but it is not the cluster itself that "imposes a minimum kubernetes version". It is the operator author that requires it for the operator to work.
I think it is important in the context of "cluster constraints" to have a clear separation:
- The cluster has properties
- Operators may have constraints on these properties
|
|
||
| ## Proposal | ||
|
|
||
| A new constraint API provides an effective away for cluster administrators to create custom resources (CR) to contain cluster information such as cluster constraints and properties. |
There was a problem hiding this comment.
I don't think it is the role of cluster-administrators to create CR to surface cluster information. This can't be done consistently across clusters owned by different companies having totally different requirements, environments, operational processes, etc.
Operator authors that are unaware of these specific clusters need:
- either a known finite set of properties they can leverage for their constraints
- or a mechanism to run generic predefined queries to retrieve the information needed by the constraints they specify. Examples:
- HW architecture
- number of nodes
- presence of an API
- HA cluster or not
|
|
||
| A new constraint API provides an effective away for cluster administrators to create custom resources (CR) to contain cluster information such as cluster constraints and properties. | ||
|
|
||
| OLM resolver will retrieve the cluster constraints and properties from the CR(s) and the information can be used during resolution. |
There was a problem hiding this comment.
I am not sure whether this is what you have in mind but I would expect to have constraints and properties captured by different CRDs
|
|
||
| OLM resolver will retrieve the cluster constraints and properties from the CR(s) and the information can be used during resolution. | ||
|
|
||
| The cluster constraints and properties are presented as a virtual cluster-scoped operator that is installed in the namespace. For all incoming operators that are intended to run the namespace, they must satisfy all constraints that are associated with this cluster-scoped operator. At the same time, the installable operators can depend on the properties that are provided by this virtual operator. |
There was a problem hiding this comment.
I am not sure of the interest of having something namespaced. Have you concrete examples in mind? It feels like it goes against "the operator descoping" idea
|
|
||
| #### Cluster constraints | ||
|
|
||
| As a cluster admin, I would like to specify constraints that are specified to the cluster and they that will be applied to all operators. As a result, only operators that satisfy these constraints to be installable in the cluster. |
There was a problem hiding this comment.
As per my comment above. As a cluster-admin I would like primarily that operators get only installed on clusters where they can work on without me needing to do extra things for it. Do you have a concrete example of a scenario where a cluster-admin would want to define what I would call "reverse constraints"? Today they can leverage catalogs to make operators available or not on specific clusters.
| } | ||
| ``` | ||
|
|
||
| The `properties` field is a list of properties that are specific to the cluster at the runtime. Each property is specified using the following syntax: |
There was a problem hiding this comment.
Will be able to work with ranges? If yes, could add an example?
Also, what happens when is not possible to install because of the constrain? could we:
a) Ensure that for any predefined type we will have a good and nice msg to output in order to make it easier for the consumer to know why the operator was not installed?
b) If I properly understood, in the EP: #91 we are able to create generic rules. What message we will show in this case? WDYT about the operator author also providing the msg?
|
|
||
| ```yaml= | ||
| apiVersion: operators.coreos.com/v2 | ||
| kind: Constraint |
There was a problem hiding this comment.
Can we make this PropertySet or something? Isn't a constraint just a specifial form of property?
| The CRD is cluster-scoped as the CR(s) are representing cluster information. The cluster administrators have RBAC permission to create CustomResource (CR) that will contain cluster constraints and properties. For example: | ||
|
|
||
| ```yaml= | ||
| apiVersion: operators.coreos.com/v2 |
There was a problem hiding this comment.
Is this actually part of deppy or rukpak?
This enhancement introduces a new mechanism for admins to provide
cluster information as constraints and properties.
Signed-off-by: Vu Dinh [email protected]