Installl Kiali specific version

[Tais P. Hansen]

Hi,

For some reason, the kiali operator has decided to force upgrade our Kiali deployment and I can't seem to figure out how to keep it at a specific version. I've tried deleting the whole thing, operator, configmaps, clusterroles etc. (where did --uninstall-mode go which the docs say should exist?) and then using below command to install again:

bash <(curl -L https://kiali.io/getLatestKialiOperator) --kiali-image-version v1.22.1 --operator-cluster-role-creator true --operator-install-kiali false --accessible-namespaces '**' --namespace 'ops'

This installs the operator, which then creates a kiali configmap in ops that dictates kiali version v1.26.1. Editing the configmap and replacing the version with ie. v1.22.1 gets overwritten shortly after with 1.26 again.

So how do I keep it at an earlier version?

[John Mazzitelli]

> For some reason, the kiali operator has decided to force upgrade our Kiali
> deployment and I can't seem to figure out how to keep it at a specific
> version. I've tried deleting the whole thing, operator, configmaps,
> clusterroles etc. (where did --uninstall-mode go which the docs say should
> exist?) and then using below command to install again:
>
> bash <(curl -L https://kiali.io/getLatestKialiOperator)
> --kiali-image-version v1.22.1 --operator-cluster-role-creator true
> --operator-install-kiali false --accessible-namespaces '**' --namespace
> 'ops'

Note that the bash command you are using is merely a convenience wrapper around helm (the script itself makes a note of this here: https://github.com/kiali/kiali-operator/blob/master/deploy/deploy-kiali-operator.sh#L7-L10). We actually do not document the usage of that command anymore in our install docs and will soon decommission that method of installation; instead, helm has replaced it and we recommend using helm if you wish to install via a CLI (as opposed to installing via OLM). See: https://kiali.io/documentation/latest/installation-guide/#_install_kiali_latest

>
> This installs the operator, which then creates a kiali configmap in ops
> that dictates kiali version v1.26.1. Editing the configmap and replacing
> the version with ie. v1.22.1 gets overwritten shortly after with 1.26 again.

When using the operator, you never directly edit the ConfigMap (or any resource that the operator creates) - the operator will ensure no one either accidentally or maliciously changes those resources (as you have noticed, the operator will revert those changes). Note that the docs I linked to earlier (https://kiali.io/documentation/latest/installation-guide/#_install_kiali_latest) explicitly says, "The Kiali ConfigMap will be managed by the Kiali Operator and should not be manually edited.")

But note that even if the operator did not revert back your ConfigMap, changing that deployment.image_version setting in the ConfigMap would be a no-op because at that point your Kiali Deployment and Pod are already created and running with the original container/image version definition. Thus, changing the ConfigMap in order to alter deployment.image_version won't do what you are expecting it to do.

> So how do I keep it at an earlier version?

You do this, not by changing the ConfigMap, but by changing the Kiali CR. So after you install the operator, you can tell it what kiali image version you want to deploy by setting spec.deployment.image_version in the Kiali CR. See: https://github.com/kiali/kiali-operator/blob/master/deploy/kiali/kiali_cr.yaml#L225-L239 -- The default is the operator will install the "last release" but you can set spec.deployment.image_version to peg the Kiali server image version to something specific that you want.

Hope this helps.

P.S. Read up more on how operators (not just Kiali operator, but operators in general) work and hopefully this will make more sense. For a quick primer, see: https://medium.com/@jmazzite/kubernetes-operators-a-very-brief-overview-270e75f3dfab

[Tais P. Hansen]

> For some reason, the kiali operator has decided to force upgrade our Kiali
> deployment and I can't seem to figure out how to keep it at a specific
> version. I've tried deleting the whole thing, operator, configmaps,
> clusterroles etc. (where did --uninstall-mode go which the docs say should
> exist?) and then using below command to install again:
>
> bash <(curl -L https://kiali.io/getLatestKialiOperator)
> --kiali-image-version v1.22.1 --operator-cluster-role-creator true
> --operator-install-kiali false --accessible-namespaces '**' --namespace
> 'ops'


Note that the bash command you are using is merely a convenience wrapper around helm (the script itself makes a note of this here: https://github.com/kiali/kiali-operator/blob/master/deploy/deploy-kiali-operator.sh#L7-L10). We actually do not document the usage of that command anymore in our install docs and will soon decommission that method of installation; instead, helm has replaced it and we recommend using helm if you wish to install via a CLI (as opposed to installing via OLM). See: https://kiali.io/documentation/latest/installation-guide/#_install_kiali_latest

We have our own internal set of Kiali (and other) install procedures documented and have not noticed that the bash install script method was no longer supported. Seems like it is time for an audit.

> This installs the operator, which then creates a kiali configmap in ops
> that dictates kiali version v1.26.1. Editing the configmap and replacing
> the version with ie. v1.22.1 gets overwritten shortly after with 1.26 again.

When using the operator, you never directly edit the ConfigMap (or any resource that the operator creates) - the operator will ensure no one either accidentally or maliciously changes those resources (as you have noticed, the operator will revert those changes). Note that the docs I linked to earlier (https://kiali.io/documentation/latest/installation-guide/#_install_kiali_latest) explicitly says, "The Kiali ConfigMap will be managed by the Kiali Operator and should not be manually edited.")

But note that even if the operator did not revert back your ConfigMap, changing that deployment.image_version setting in the ConfigMap would be a no-op because at that point your Kiali Deployment and Pod are already created and running with the original container/image version definition. Thus, changing the ConfigMap in order to alter deployment.image_version won't do what you are expecting it to do.

Ugh. You're right of course. I kept focusing on the configmap while it was the CR I had in mind. Setting the image_version in the CR works as it should.

Thank you for the help.

--

Mvh. Tais P. Hansen