# After installation of 1.13.0 - existing installation don't work anymore

**URL:** <https://forums.percona.com/t/after-installation-of-1-13-0-existing-installation-dont-work-anymore/17659>\
**Category:** Percona Operator for MongoDB\
**Created:** [September 26, 2022, 7:54am UTC](https://forums.percona.com/t/after-installation-of-1-13-0-existing-installation-dont-work-anymore/17659 "2022-09-26T07:54:03Z")\
**Posts on this page:** 10\
**Page:** 1

<div class="post-metadata">

**Author:** ![jamoser](https://avatars.discourse-cdn.com/v4/letter/j/b2d939/32.png) [@jamoser](https://forums.percona.com/u/jamoser)\
**Post date:** [September 26, 2022, 7:54am UTC](https://forums.percona.com/t/after-installation-of-1-13-0-existing-installation-dont-work-anymore/17659/1 "2022-09-26T07:54:04Z")

</div>

Dear all

Looks like with the new “numbering” there is a problem with existing installations (on GKE):

no matches for kind “PerconaServerMongoDB” in version “[psmdb.percona.com/v1-XYZ-0](http://psmdb.percona.com/v1-XYZ-0)”

Regards  
John

---

<div class="post-metadata">

**Author:** ![Sergey\_Pronin](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/sergey_pronin/32/14887_2.png) [@Sergey\_Pronin](https://forums.percona.com/u/Sergey_Pronin)\
**Post date:** [September 26, 2022, 7:55am UTC](https://forums.percona.com/t/after-installation-of-1-13-0-existing-installation-dont-work-anymore/17659/2 "2022-09-26T07:55:32Z")

</div>

Hello @jamoser ,

what are the steps to reproduce? You upgraded from 1.12 to 1.13?

---

<div class="post-metadata">

**Author:** ![jamoser](https://avatars.discourse-cdn.com/v4/letter/j/b2d939/32.png) [@jamoser](https://forums.percona.com/u/jamoser)\
**Post date:** [September 26, 2022, 8:08am UTC](https://forums.percona.com/t/after-installation-of-1-13-0-existing-installation-dont-work-anymore/17659/3 "2022-09-26T08:08:01Z")

</div>

Hi @Sergey_Pronin

No … I have an installation of 1.9.0 on the GKE cluster which gets shutdown overnight. I installed 1.13.0 which was ok. But when we tried to turn on 1.9.0 by applying the cr.yaml, then we get the above error.

imho - it’s a no-go. You can’t expect a live system to be migrated to 1.13.0 “on the fly”.

Regards  
John

---

<div class="post-metadata">

**Author:** ![Ege\_Gunes](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/ege_gunes/32/4595_2.png) [@Ege\_Gunes](https://forums.percona.com/u/Ege_Gunes)\
**Post date:** [September 26, 2022, 8:15am UTC](https://forums.percona.com/t/after-installation-of-1-13-0-existing-installation-dont-work-anymore/17659/4 "2022-09-26T08:15:44Z")

</div>

Hi @jamoser, each release supports only last three versions. We don’t guarantee version 1.9.0 will work with 1.13.0. Also, you should upgrade to nearest minor release (1.10 in your case), not to the latest version.

Please see [upgrade docs](https://docs.percona.com/percona-operator-for-mongodb/update.html).

Any reason you stay on 1.9.0? What blocks you from upgrading?

---

<div class="post-metadata">

**Author:** ![jamoser](https://avatars.discourse-cdn.com/v4/letter/j/b2d939/32.png) [@jamoser](https://forums.percona.com/u/jamoser)\
**Post date:** [September 26, 2022, 8:21am UTC](https://forums.percona.com/t/after-installation-of-1-13-0-existing-installation-dont-work-anymore/17659/5 "2022-09-26T08:21:39Z")

</div>

May be it’s a little bit difficult to understand 🙂

We have an installation 1.9.0

and now I’ve installed 1.13.0

Until 1.12.0 the rbac/crd/whatever had all the versions.

Looks like with 1.13.0 deployed it overwrites them.

So after installing 1.13.0 all other version get killed.

And possibly you are not aware that we talk of PROD - there is no “hey it’s a lovely day and I am going to convert all the mongodb clusters to the new operator version”.

---

<div class="post-metadata">

**Author:** ![Sergey\_Pronin](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/sergey_pronin/32/14887_2.png) [@Sergey\_Pronin](https://forums.percona.com/u/Sergey_Pronin)\
**Post date:** [September 26, 2022, 8:39am UTC](https://forums.percona.com/t/after-installation-of-1-13-0-existing-installation-dont-work-anymore/17659/6 "2022-09-26T08:39:42Z")

</div>

@jamoser what is the goal of installing 1.13.0? Upgrade?

As Ege said - the intended and documented upgrade process is 1 version at a time.  
So if you have 1.9.0, please install 1.10.0 first, upgrade both Operator and databases.  
Then go with 1.11, and so on.

This way you will have a smooth upgrade experience.

You are correct about that 1.12.0 had all the versions. In 1.13.0 we changed this and you can see it in the release notes:

- [K8SPSMDB-715](https://jira.percona.com/browse/K8SPSMDB-715) Starting from now, the Opearator changed its API version to v1 instead of having a separate API version for each release. Three last API version are supported in addition to `v1`, which substantially reduces the size of Custom Resource Definition to prevent reaching the etcd limit

Please let me know if I misunderstood something here.

---

<div class="post-metadata">

**Author:** ![Ege\_Gunes](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/ege_gunes/32/4595_2.png) [@Ege\_Gunes](https://forums.percona.com/u/Ege_Gunes)\
**Post date:** [September 26, 2022, 8:51am UTC](https://forums.percona.com/t/after-installation-of-1-13-0-existing-installation-dont-work-anymore/17659/7 "2022-09-26T08:51:26Z")

</div>

CRD is a cluster wide object, all operators uses the same CRD no matter which version they’re running. If you have a operator running version 1.9.0, you shouldn’t apply the CRD from 1.13.0 before upgrading your operator to 1.10 at least.

Please correct me if I’m wrong but your running cluster shouldn’t be terminated, since CRD is there and it still has the version in it. v1.13.0 simply set v1.9.0 to `served: false` so Kubernetes API will throw not found if you try to use this API version. Although it’s not terminated, your old operator will fail to reconcile cluster because it’ll also get not found errors from API.

---

<div class="post-metadata">

**Author:** ![jamoser](https://avatars.discourse-cdn.com/v4/letter/j/b2d939/32.png) [@jamoser](https://forums.percona.com/u/jamoser)\
**Post date:** [September 26, 2022, 1:26pm UTC](https://forums.percona.com/t/after-installation-of-1-13-0-existing-installation-dont-work-anymore/17659/8 "2022-09-26T13:26:37Z")

</div>

> > Please correct me if I’m wrong but your running cluster shouldn’t be terminated, since CRD is there and it still has the version in it.

Again : GKE cluster X running 1.9.0, which gets “restarted” every night. The day before 1.13.0 installed with rbac, crd, etc. Today 1.9.0 does not restart when applying its cr.yaml

Bottom line : you can’t have parallel operation of a 1.x.0 and 1.13.0 cluster on a GKE cluster (even if the mongodb cluster/operators run on different namespaces).

---

<div class="post-metadata">

**Author:** ![jamoser](https://avatars.discourse-cdn.com/v4/letter/j/b2d939/32.png) [@jamoser](https://forums.percona.com/u/jamoser)\
**Post date:** [September 27, 2022, 1:13pm UTC](https://forums.percona.com/t/after-installation-of-1-13-0-existing-installation-dont-work-anymore/17659/9 "2022-09-27T13:13:58Z")

</div>

Addendum:

In GKE you can have

project

- clusters (for ex. PROD, TEST, DEV)  
– namespaces (for ex. my-psmdb-cluster-09, my-psmdb-cluster-12, my-psmdb-cluster-13)

So if you deploy a CRD then it’s valid for the whole “project” and will affect any cluster. That is why it is not possible for -\>us\< to have operator 1.13 deployed - it will just overwrite the existing CRD for up to 1.12.

---

<div class="post-metadata">

**Author:** ![Ege\_Gunes](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/ege_gunes/32/4595_2.png) [@Ege\_Gunes](https://forums.percona.com/u/Ege_Gunes)\
**Post date:** [September 27, 2022, 3:35pm UTC](https://forums.percona.com/t/after-installation-of-1-13-0-existing-installation-dont-work-anymore/17659/10 "2022-09-27T15:35:18Z")

</div>

Yes, CRDs are not namespaced and used in cluster scope. Thank you for explaining it clearly. We should put it in our documentation for operator upgrades.
