Consideration of support of users not upgrading to the latest version

It has become known that one end-user has been maintaining their camel-k installation on older versions for a time-period after the release of newer versions. They have also been able to spin up new clusters with the same older version by using a technique known to the Operator-Lifecycle-Manager system but not readily obvious or promoted in the OCP console. [1]

The reasoning for the customer conducting their upgrades in this fashion, is understood to allow them to set their own upgrade cycles for their integrations and allow updates to their own unit testing.

This information highlights an issue that requires further investigation and clarification. The OLM install console in OCP, does not make installation of older versions possible but the existence of the older versions in the OLM channel version chains does make it feasible for users to commonly act in this fashion. Unless, older versions are purposefully hidden using skip properties, the ability for users to return to old versions is always possible.

Note: This also applies to existing version channels like camel-k's 1.4.x, which should arguably be removed but remains available in OLM due to the older bundle images residing in the channel chains.

Therefore, questions to consider:

• Is this simply a single user who is conducting their OLM upgrades in an abnormal process or is this a widespread phenomenon?
• Since the installation of older versions is a fact, what steps should be taken to either support users in this regard or inform users that acting in this regard is unsupportable and should be discouraged?
• To encourage "latest-version-takeup", should efforts be put in place to purge OLM channels of older versions [2], in order to discourage users installing versions that are no longer in support forcing upgrade to supported versions?

              +
+

[1] The technique crafts a yaml resource of an OLM subscription and specifies the version to be installed using the startingCSV property. By also setting the property installPlanApproval to "Manual", automatic upgrading is turned off and the older version can be installed, eg.

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
labels:
operators.coreos.com/camel-k.openshift-operators: ""
name: red-hat-camel-k
namespace: openshift-operators
spec:
name: red-hat-camel-k
source: redhat-operators
sourceNamespace: openshift-marketplace
channel: stable
installPlanApproval: Manual
startingCSV: red-hat-camel-k-operator.v1.6.7

[2] A function of the building of the catalog-index of operators is that the channel chains of operator versions is actually built backwards from the newest to oldest. If a bundle is found to include a skip property then applicable versions residing within its range are purged from the channel entirely. Therefore, by specifying a range of '<1.6' on the 1.6.x channel, it should be possible to only have a chain that includes 1.6+ and dropping all 1.4 versions (testing required to confirm documentation).