Project: Kubewarden (Provisioning / Security & Compliance)
File: RELEASE_NOTES_v0.2.0.md

The `v0.2.0` release of kubewarden-controller introduces a new version of the `ClusterAdmissionPolicy` custom resource. Starting from this release, only `ClusterAdmissionPolicy` of version `v1alpha2` are going to be reconciled by the controller. This section describes how to migrate a kubewarden deployment from `v0.1.4` to `v0.2.0`. You must port the `v1alpha1` definitions to the `v1alpha2` format. We don't offer an automated process for that, but the operation is pretty straightforward. The `apiGroups`, `apiVersions`, `resources` and `operations` are no longer top-level attributes, but rather items under the new `rules` attribute. Consider the following `v1alpha1` resource definition: ```yaml apiVersion: policies.kubewarden.io/v1alpha1 kind: ClusterAdmissionPolicy metadata: name: psp-capabilities spec: module: registry://ghcr.io/kubewarden/policies/psp-capabilities:v0.1.3 resources: pods operations: CREATE UPDATE mutating: true settings: allowed_capabilities: CHOWN requireddropcapabilities: NET_ADMIN ``` The `v1alpha2` equivalent would be: ```yaml apiVersion: policies.kubewarden.io/v1alpha2 kind: ClusterAdmissionPolicy metadata: name: psp-capabilities spec: module: registry://ghcr.io/kubewarden/policies/psp-capabilities:v0.1.3 rules: apiGroups: [""] apiVersions: ["v1"] resources: ["pods"] operations: CREATE UPDATE mutating: true settings: allowed_capabilities: CHOWN requireddropcapabilities: NET_ADMIN ``` Some considerations worth of note: With `v1alpha1`, `apiGroups`, `apiVersions`, `resources` were optional* string attributes. Now they are array of strings that must have at least one element. With `v1alpha1`, `apiGroups`, `apiVersions`, `resources` were optional* string attributes. When left empty they would default to the `"*"` value. This is reflected in the example above, as you can see the `v1alpha2` resource explicitly defines all these attributes. This is a list of steps to perform the upgrade to the `v0.2.0` release. We assume the deployment of Kubewarden has been done using our official helm charts inside of the `kubewarden` Namespace. As a first step, start by deleting the current `kubewarden-controller` deployment. This can be done with the following command: ```console kubectl delete deployment --namespace kubewarden kubewarden-controller ``` Note well: Existing policies will continue to work as expected, even while the controller is not running. Removal, creation and update of policies won't be reconciled until the controller is restarted. To install the new CRD definition execute the following commnad: ```console kubectl apply -f https://raw.githubusercontent.com/kubewarden/helm-charts/kubewarden-controller-0.1.12/charts/kubewarden-controller/crds/clusteradmissionpolicies.yaml ```` Upgrade all the currently defined `ClusterAdmissionPolicy` resources to use the `v1alpha2` version. This can be done via: ```console kubectl apply -f <upgrade-policy.yaml> ``` It's time to upgrade the helm release, this can be done via: ```console helm upgrade kubewarden-controller --version 0.1.12 kubewarden/kubewarden-controller ``` Once this is done, the new version of the `kubewarden-controller` will be running on our cluster. The `policy-server` instance will keep operating as expected during the whole time. It won't even be restarted, unless you changed some details about the `ClusterAdmissionPolicy` resource apart from the version itself.