Open shnoru1 opened 2 years ago
Hi @shnoru1,
Thank you for opening this issue -- this feature request makes sense and is a reasonable ask. The default OLM behavior is to move through all versions in the catalog to the latest version based on semver, and this behavior has been standard through all releases of OLM. A feature that limits automatic updates only based on minor or patch versions would be interesting but would have to be opt-in to not break existing OLM users.
That being said, providing more flexible UX for users around installation is part of the goal of developing the new OLM v2 APIs.
An alternative that Keycloak could implement: Add separate channels per major version. Their git repo for this is here.
They could have:
alpha-v15
alpha-v16
alpha-v17
alpha
This gives the consumer the option to PIN to a specific major version, allowing automatic minor and patch upgrades within that major version.
Your subscription would look like this:
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
name: keycloak-operator
namespace: keycloak
spec:
channel: v16
name: keycloak-operator
source: operatorhubio-catalog
sourceNamespace: olm
installPlanApproval: Automatic
Feature Request
Is your feature request related to a problem? Please describe. I had an issue with Keycloak deployment in the morning. There was a problem when the Keycloak operator was upgraded automatically from version
16.1.0
to version17.0.0
. After investigation, it was not the problem of Keycloak itself, but there was an incompatibility issue between Keycloak and a third party plugin (keycloak-metrics-spi
in my case). Here is my environment setup.Subscription
with the following yaml.Keycloak
instance with the following yaml.17.0.0
, thekeycloak-metrics-spi
plugin (with version2.3.1
) complained about the method compatibility and made the wholeKeycloak
deployment crash.Subscription
with changes ininstallPlanApproval
andstartingCSV
to solve compatibility problems.Describe the solution you'd like I'd like to suggest the default behavior of the
Subscription
to upgrade automatically withinminor
orpatch
versions but not tomajor
versions. I think the major versions are considered to have incompatible API changes, and almost all services follow the semver notation with their versions. I suggest the type ofinstallPlanApproval
field be divided toAutomaticPatch
,AutomaticMinor
,AutomaticMajor
, and the originalAutomatic
can be an alias ofAutomaticMinor
andAutomaticPatch
.