Enhancement proposal for supporting feature gates in OLM #119
Conversation
Signed-off-by: Frederic Giloux <fgiloux@redhat.com>
|
|
||
| #### Feature gate | ||
|
|
||
| The feature gate implementation will leverage existing [Kubernetes libraries](https://pkg.go.dev/k8s.io/component-base/featuregate). |
There was a problem hiding this comment.
Does this imply that all OLM sub-projects need to take a direct dependency on the k8s.io/component-base package?
|
|
||
| #### OLMConfig | ||
|
|
||
| A new version v2alpha1 of the OLMConfig API will be created and supported along v1. This version will introduce a list named `gates` for activation and deactivation of features: |
There was a problem hiding this comment.
Should we add a field to the olmConfig.status that communicates the status of the enabled/disabled feature?
There was a problem hiding this comment.
An immediate instance where this may be useful is handling the legacy disableCopiedCSVs feature toggle, in which conflicting values between the old and new api can result in an error.
There was a problem hiding this comment.
Some features may also take time to configure, so this could communicate feature state.
|
|
||
| #### DisableCopiedCSVs | ||
|
|
||
| As DisableCopiedCSVs already exists. As a first class field its support needs to be guaranteed. As such the API field will be kept and deprecated but the implementation will convert it to the map key/value pair and will handle it in a way consistent with the other feature gates. |
There was a problem hiding this comment.
Should we surface this behavior/context in the open api description for this field to help improve local UX?
| type: string | ||
| value: | ||
| description: value is a boolean that specifies whether the feature is activated or not. | ||
| type: boolean |
There was a problem hiding this comment.
i think api review is going to tell you to use an ENUM with "enabled" and "disabled" as the initial valid values
|
|
||
| #### OLMConfig | ||
|
|
||
| A new version v2alpha1 of the OLMConfig API will be created and supported along v1. This version will introduce a list named `gates` for activation and deactivation of features: |
There was a problem hiding this comment.
why do we need a new api version to add these fields?
|
|
||
| This enhancement proposal aims at bringing the following benefits to OLM: | ||
|
|
||
| - A more phased approach of releasing features. |
There was a problem hiding this comment.
Nothing in this EP really addresses the implications of a user turning on an alpha/beta/techpreview feature. This is why OCP has the concept of "Techpreviewnoupgrade" among other things, in order to:
- make it abundantly clear to the admin that the feature they are turning on is techpreview (you can also achieve this by naming your featuregates appropriately)
- make it clear they will not be able to upgrade the cluster (And then enforcing that constraint). It is somewhat up to OLM if they want a similar enforcement, but there are many many subtleties to deal with if you allow upgrades after a techpreview feature has defined some APIs and stored resources using that api. I think it is preferable if you can tie the enablement of TP features to blocking cluster upgrades (of course that is an OCP-specific aspect, so it may not belong in upstream OLM)
One option might be for downstream OLM to override/disable any featuregates that are techpreview, unless the OCP techpreviewnoupgrade featuregate is enabled at the cluster level.
In any case, i'd like to see more discussion of how alpha/beta/techpreview featuregates will be managed/expressed.
There was a problem hiding this comment.
(I assume you're familiar, but in case you're not: https://docs.openshift.com/container-platform/4.10/nodes/clusters/nodes-cluster-enabling-features.html)
As part of the optional manifest implementation for OLM it was highlighted that it would be best introduced behind a feature gate. As there is currently no flexible feature gate mechanism in OLM this enhancement proposal details an approach for introducing one. The approach is strongly inspired by what has been done in Kubernetes.
Signed-off-by: Frederic Giloux fgiloux@redhat.com