upgrade path described in the documentation leads to built-in extensions disabled

we are testing and supporting only one upgrade method, which is described in our document. According to this method, users should update CRDs, RBAC, and then operator.

It contradicts to the statement:

So, we should update a documentation to something: while the newer operator could work with old CRD, major changes could break the upgrade process.

Also we should make --server-side note and explain how important it is for crd.

, we are testing and supporting only one upgrade method, which is described in our document. According to this method, users should update CRDs, RBAC, and then operator.

extensions issue is pretty unexpected especially after “The Operator supports last 3 versions of the CRD, so it is technically possible to skip upgrading the CRD and just upgrade the Operator.”

but in our doc, we have kubectl apply --server-side. Maybe we can add additional manual steps to check extensions before and after the update. Like step to verify if everything is ok.

the problem is hidden at kubectl -n pgo apply -f crd.yaml without --server-side existing extensions disappear. Same problem happens with helm, because helm is not updating it automatically. At least this behavior should be documented or better if we don’t have extensions in CRD, we should install extensions enabled before 2.3.x