Upgrade procedure needed about website

[chipzoller]

Yeah, it's a good point. So I'll be sure to document the upgrade process using Helm to both "development" releases and also "production" releases. Otherwise with straight YAML, it's just a re-apply the latest manifest. If you can think of anything else that may be special, please let me know. I'll write up what we've got so far if not.

[chipzoller]

Input needed, please. I'll self-assign once it's ready to document.

[realshuting]

Yes, the upgrade of Kyverno is fairly simple, it just needs to apply the latest manifest from this file: https://github.com/kyverno/kyverno/blob/main/definitions/release/install.yaml

[chipzoller]

I think there needs to be some guidance on how to remove the older CRDs so there isn't an alias collision with the new ones. Here's what happens when that doesn't happen and you just repave Kyverno with a newer manifest.

$ k api-resources | egrep report
clusterreportchangerequests                          kyverno.io                     false        ClusterReportChangeRequest
reportchangerequests                                 kyverno.io                     true         ReportChangeRequest
clusterpolicyreports              cpolr              policy.k8s.io                  true         ClusterPolicyReport
policyreports                     polr               policy.k8s.io                  true         PolicyReport
clusterpolicyreports              cpolr              wgpolicyk8s.io                 false        ClusterPolicyReport
policyreports                     polr               wgpolicyk8s.io                 true         PolicyReport

[realshuting]

Ok, I see. I think you installed an early release candidate of 1.3.0 and later upgraded to the latest version. For now you can just remove clusterpolicyreports and policyreports in policy.k8s.io.

I would suggest cleaning up older CRDs by Kyverno automatically rather than adding more steps when upgrading Kyverno.

Will submit a PR to fix it.

[chipzoller]

Yeah, I have been using each RC for 1.3.0 as they've been cut, but I wasn't sure when the new CRDs came in. Agree it'd be better for Kyverno to clean them up.

So is the official best practice for upgrading to just apply the new manifest or use Helm as usual? No special procedures or considerations?

[realshuting]

With kubectl, all it needs is to run kubectl apply -f https://github.com/kyverno/kyverno/blob/main/definitions/release/install.yaml.

With Helm, I think it first needs to upgrade Charts, and then upgrade Kyverno application? I'm now so sure, will have to check the exact command.

[chipzoller]

If the new chart is published, users would have to helm repo update to pull in the new definitions and then do a helm upgrade specifying that new version. Or were you saying there's more than that?

[realshuting]

It'd be all when upgrading to an official release. When dealing with a release candidate, seems like Helm "hides" release candidates by default.

For example, only if I do helm search repo --devel kyverno, it shows the release candidate, otherwise, it just displays the latest official one. See Install via Helm on this page. When installing / upgrade, it needs a specific version by --version.

[chipzoller]

Yes, I'm familiar with the release vs RC/dev ones. Just asking if it's a "normal" upgrade process with Helm. Mainly asking because users will want to make sure nothing is going to happen to their policies or reports.

[realshuting]

I was not aware of that until I tested RC install, so just wanted to bring that up.

For the normal upgrade, what you've described would be all:

users would have to helm repo update to pull in the new definitions and then do a helm upgrade specifying that new version.

[chipzoller]

Closing via 9684ca3