Kiali: Cannot install specific kiali version v.18.2 after operator-only installation

[jwurm]

Affects: Kiali-Operator: 1.19.0

Reproduction:
After doing an operator-only installation like this:
bash <(curl -L https://kiali.io/getLatestKialiOperator) --operator-install-kiali false
Then try to install Kiali in a specific version using the "version" parameter in the kiali custom resource

See playbooks/default-supported-images.yml

Could someone add other supported versions there, such as v1.18.2, or add another configuration option to choose a kiali version = operator version, as it used to be available?

Being able to specifically choose a version to install would be very important for production use.

Thanks!

PS: Another minor issue: the --version parameter of the operator install script currently does nothing at all.

[jmazzitelli]

PS: Another minor issue: the --version parameter of the operator install script currently does nothing at all.

This is not accurate. It currently dictates what value to populate the "spec.version" field in the Kiali CR. Because it affects the Kiali CR created by the script, therefore this only does something if you tell the script to install Kiali (i.e. create a Kiali CR) as well as the operator. But since you are passing in --operator-install-kiali false that value does not appear to do anything.

This is why the --version option is documented within the --help output under the section titled "Valid options for Kiali installation (if Kiali is to be installed):" - please see here and here.

[jmazzitelli]

add another configuration option to choose a kiali version = operator version, as it used to be available?

This no longer makes sense because (unlike previous releases) the operator and the kiali server are no longer in lock step. In other words, previously, the Operator and the Server would be released under the same exactly version (e.g. 1.10.0). However, they have now been decoupled and no longer are necessarily in lock step (i.e. their versions no longer need to be paired together.).

[jmazzitelli]

Being able to specifically choose a version to install would be very important for production use.

Note that this is still possible. You simply provide a spec.deployment.image_version in your Kiali CR such as "v1.18.2".

The spec.version value's main purpose is to declare which set of Ansible deployment scripts should be used when installing Kiali. "default" means use the latest. The secondary purpose of this spec.version is to define a default Kiali image to use if you do not specify one in Kiali CR's spec.deployment.image_version. But you always have the option to declare explicitly what version of Kiali you want to use (thus overriding the default images found in playbooks/default-supported-images.yml.

[jwurm]

Wow, thanks for your help! :-)

You're right, the version flag does work, i hadn't seen it being used in the install script but didn't check further downstream playbooks. My bad!

Isn't the spec.version attribute in the kiali custom resource kinda deprecated then? One would never change its value unless one wants to go back v.1.12 or older. If one wants to go such an old version, one probably also can use that other method with image_version.

Otherwise, with the spec.version in the custom resource in place, wouldn't it still make sense to maintain a list of supported versions in default-supported-images.yml, to provide information to the user that this version of the operator is still compatible to those versions of kiali?

Right now, with spec.image_version, the documentation implies risk of incompatibility, whereas the very old versions available by spec.version are implied to be explicitly supported.

[jmazzitelli]

Isn't the spec.version attribute in the kiali custom resource kinda deprecated then? One would never change its value unless one wants to go back v.1.12 or older.

It isn't deprecated (it is actually a relatively new feature). But you are correct, you would never change its value unless you want to use a set of older versions of the operator playbooks. The name of the config option probably could have been better named - perhaps "playbook_version" or something. The default value (i.e. if you do not set it in your Kiali CR, its default is, again for lack of creativity, default) means it will use the latest-n-greatest playbook. But if you want to install an older version of Kiali Server (today we support two - v1.0 and v1.12) those Kiali Server versions needed older versions of the playbook to be installed correctly - they won't install correctly if you use the latest-n-greatest playbook. Thus the need to support spec.version values of v1.0 and v1.12.

The entire reason why this spec.version exists is to have the very important operator feature of being able to install multiple versions of Kiali Server (thus we only need to have one operator per cluster running, and we do not need to release the operator from different forks of the Kiali Operator - we have a single stream of operator releases that can now support installing and managing multiple versions of Kiali Server. This is especially helpful when the operator itself is managed by OLM aka Operator Lifecycle Manager).

This brings up the point that there is another way of using the operator (that is, an alternative to the deploy .sh script) - and that is to use OLM. You can then use OLM to update the operator for you. See: https://operatorhub.io/operator/kiali where we have 1.19.0 as the latest release of Kiali operator via OperatorHub.

As a side note, we recommend production users consider managing their Kiali Operator with Operator Lifecycle Manager (which is how you "officially" install and upgrade any and all Kubernetes Operators installed in your cluster). If on OpenShift, you already have OLM, but you can install OLM in any Kubernetes cluster. OLM has access to all the operators found on OperatorHub.io. The Kiali team will maintain versions of the Kiali Operator available on OperatorHub.io.

If one wants to go such an old version, one probably also can use that other method with image_version.

No, it won't work. As I state above, the latest-n-greatest playbooks won't correctly install the old images.

Otherwise, with the spec.version in the custom resource in place, wouldn't it still make sense to maintain a list of supported versions in default-supported-images.yml, to provide information to the user that this version of the operator is still compatible to those versions of kiali?

Right now, with spec.image_version, the documentation implies risk of incompatibility, whereas the very old versions available by spec.version are implied to be explicitly supported.

Yes. Herein lies some give-and-take. If we supported EVERY released version in the default-supported-images.yml, that list would grow very large, very fast. But that isn't really the problem... the problem is for every supported image, we need a full copy of all the yamls in the roles (remember, spec.version mainly indicates the version of the playbook that is to be used) - you can see that here: https://github.com/kiali/kiali-operator/tree/master/roles ... look inside each of those three supported version directories and you'll see the full set of Ansible yaml files for the different roles - one set of roles per supported version. We are trying to limit the amount of files here for maintenance reasons. BUT! We also want to be able to support installing and managing SOME older versions (this is important, for example, for the Maistra project - which is a downstream Istio implementation).

So what we will do is periodically "snapshot" an explicit supported version and add it to the supported-images list (which also means copying the current playbook's role files). This will be done if, for example, we know future changes to the default playbook won't work with current versions of the Kiali Server image.

It is correct that the "documentation implies risk of incompatibility", however, the "default" supported-version will always ensure the default playbook will support the latest release of Kiali and we try to at least have it support the previous version, if not more versions back. I suspect you will find that the default playbook today supports going back multiple Kiali versions. But if you want to upgrade Kiali Server and not have this risk of incompatibility, then you should upgrade to the latest Kiali Operator and let it install the latest release of the Kiali Server without you having to specify any versions (this is one reason why using OLM is nice - let it handle the upgrades).

This also allows bugs to be fixed in the operator playbook itself without having to force users to bump up the spec.version in their Kiali CRs to pick up the changes. If you want to use a specific Kiali Server (that is, you don't want to update to newer Kiali servers), you would already be using spec.deployment.image_version - and by updating the operator, you'll get those operator fixes without updating your Kiali Server itself. But this is probably not a normal use case - when upgrading the operator, you normally really want to upgrade to the latest Kiali Server (though there could be cases where an operator playbook bug will require an update to the operator but you can still stay back to an older Kiali Server version - that is one use case that this system allows us to support).

Pretty soon, we are going to take another snapshot of a supported Kiali version. Probably in the v1.20 or v.21 timeframe (but that isn't fixed in stone yet).

[israel-hdez]

Looks like this was a question and was solved. So, I'm closing.
Feel free to re-open if there is still an issue.