kiali: Kiali 1.36 upgrade from 1.32 service selector incorrect
Issue Description We are noticing that when upgrading from 1.32 to 1.36 the service selectors seem to stick around:
selector:
app: kiali
app.kubernetes.io/instance: kiali
app.kubernetes.io/name: kiali
version: v1.32.0
This causes issues with hitting the service obviously. We are installing from the helm chart, so its possible this is related to the helm chart rather than the operator?
Versions used Kiali: 1.32.0 -> 1.36.0 Istio: 1.8.4 Kubernetes flavour and version: k3s version v1.20.4-k3s1
To Reproduce Steps to reproduce the behavior:
- Helm install the 1.32.0 operator + instance
- Helm upgrade to the 1.36.0 operator + instance
- Check the kiali service that has been created
- See the extra/wrong selectors.
Expected behavior The service should be updated on upgrades.
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Comments: 15
Commits related to this issue
- When upgrading from pre-v1.35 to 1.35-and-later, we have to make sure we remove app and version fields from the service selector, otherwise, upgrades are broken. fixes: https://github.com/kiali/kiali... — committed to jmazzitelli/kiali-operator by jmazzitelli 3 years ago
- When upgrading from pre-v1.35 to 1.35-and-later, we have to make sure we remove app and version fields from the service selector, otherwise, upgrades are broken. When we no longer support operator v1... — committed to jmazzitelli/kiali-operator by jmazzitelli 3 years ago
- When upgrading from pre-v1.35 to 1.35-and-later, we have to make sure we remove app and version fields from the service selector, otherwise, upgrades are broken. The code to do the lookup is simply to... — committed to jmazzitelli/kiali-operator by jmazzitelli 3 years ago
- When upgrading from pre-v1.35 to 1.35-and-later, we have to make sure we remove app and version fields from the service selector, otherwise, upgrades are broken. The code to do the lookup is simply to... — committed to jmazzitelli/kiali-operator by jmazzitelli 3 years ago
- When upgrading from pre-v1.35 to 1.35-and-later, we have to make sure we remove app and version fields from the service selector, otherwise, upgrades are broken. The code to do the lookup is simply to... — committed to jmazzitelli/kiali-operator by jmazzitelli 3 years ago
- When upgrading from pre-v1.35 to 1.35-and-later, we have to make sure we remove app and version fields from the service selector, otherwise, upgrades are broken. The code to do the lookup is simply to... — committed to jmazzitelli/kiali-operator by jmazzitelli 3 years ago
- When upgrading from pre-v1.35 to 1.35-and-later, we have to make sure we remove app and version fields from the service selector, otherwise, upgrades are broken. The code to do the lookup is simply to... — committed to kiali/kiali-operator by jmazzitelli 3 years ago
- When upgrading from pre-v1.35 to 1.35-and-later, we have to make sure we remove app and version fields from the service selector, otherwise, upgrades are broken. The code to do the lookup is simply to... — committed to kiali/kiali-operator by jmazzitelli 3 years ago
I want to more formally declare what the problem is.
The problem only shows up if:
(a) You have already installed Kiali server using operator v1.34 or earlier, and… (b) You have not deleted the Kiali CR (i.e. you have not uninstalled that Kiali server), and… © You upgrade the operator (and hence the existing Kiali server) to v1.35 or higher.
If you delete the Kiali CRs prior to upgrading the operator, this isn’t a problem.
If you are starting from v1.35 or higher (and, say, upgrade to v1.36.1) or if you are starting before v1.35 and are upgrading to before v1.35, this also isn’t a problem.
So, in short, upgrading an existing Kiali server from pre-v1.35 to 1.35+ is a problem.
OK. I know what this is. The “version” field has been removed from the selector (happened in this PR which went into Kiali v1.35.0). So this problem only happens if you upgrade from a pre-v1.35 operator to a v1.35-or-higher operator. Once you get past v1.35, this won’t happen.
It looks like Kubernetes patch is not removing that now-defunct “version” field when applied to an existing service that already had it.
There are two workarounds you can do for this.
or