Helm Chart Breaking Changes from 0.1.0 to 0.3.0

[mmattel]

Are there any breaking changes in the Helm Chart between version 0.1.0 and 0.3.0, see: Breaking Changes. Note that 0.2.0 was an intermediate release necessary for 3.0.alpha

If not, we just need to mention that,
if yes, we need to provide the changes.

Note that there will most likely be a 0.4.0 release soon so we can do the work only once...

[wkloucek]

I updated the release notes for the 0.3.0 release: https://github.com/owncloud/ocis-charts/releases/tag/v0.3.0

It now includes: "Upgrading from version 0.1.0 is not supported and will result in data loss, depending on your PersistentVolume deletion policies."

This is not because of a breaking change between 0.2.0 and 0.3.0, but because of a breaking change between 0.1.0 and 0.2.0, that wasn't mentioned in the 0.2.0 release notes (https://github.com/owncloud/ocis-charts/releases/tag/v0.2.0).

When I upgrade from 0.1.0 to 0.2.0 I see this among other things:

ocis, storage-system-data, PersistentVolumeClaim (v1) has been removed:
- # Source: ocis/templates/storage-system/pvc.yaml
- apiVersion: v1
- kind: PersistentVolumeClaim
- metadata:
-   name: storage-system-data
-   namespace: ocis
-   labels:
-     helm.sh/chart: ocis-0.1.0
-     app.kubernetes.io/name: ocis
-     app.kubernetes.io/instance: ocis
-     app.kubernetes.io/version: "2.0.0"
-     app.kubernetes.io/managed-by: Helm
-   finalizers:
-     - kubernetes.io/pvc-protection
- spec:
-   accessModes:
-     - "ReadWriteMany"
-   resources:
-     requests:
-       storage: "5Gi"

ocis, storage-users-data, PersistentVolumeClaim (v1) has been removed:
- # Source: ocis/templates/storage-users/pvc.yaml
- apiVersion: v1
- kind: PersistentVolumeClaim
- metadata:
-   name: storage-users-data
-   namespace: ocis
-   labels:
-     helm.sh/chart: ocis-0.1.0
-     app.kubernetes.io/name: ocis
-     app.kubernetes.io/instance: ocis
-     app.kubernetes.io/version: "2.0.0"
-     app.kubernetes.io/managed-by: Helm
-   finalizers:
-     - kubernetes.io/pvc-protection
- spec:
-   accessModes:
-     - "ReadWriteMany"
-   resources:
-     requests:
-       storage: "50Gi"

ocis, storagesystem-data, PersistentVolumeClaim (v1) has been added:
- 
+ # Source: ocis/templates/storagesystem/pvc.yaml
+ apiVersion: v1
+ kind: PersistentVolumeClaim
+ metadata:
+   name: storagesystem-data
+   namespace: ocis
+   labels:
+     helm.sh/chart: ocis-0.2.0
+     app.kubernetes.io/name: ocis
+     app.kubernetes.io/instance: ocis
+     app.kubernetes.io/version: "3.0.0-alpha.1"
+     app.kubernetes.io/managed-by: Helm
+   finalizers:
+     - kubernetes.io/pvc-protection
+ spec:
+   accessModes:
+     - "ReadWriteMany"
+   resources:
+     requests:
+       storage: "5Gi"

ocis, storageusers-data, PersistentVolumeClaim (v1) has been added:
- 
+ # Source: ocis/templates/storageusers/pvc.yaml
+ apiVersion: v1
+ kind: PersistentVolumeClaim
+ metadata:
+   name: storageusers-data
+   namespace: ocis
+   labels:
+     helm.sh/chart: ocis-0.2.0
+     app.kubernetes.io/name: ocis
+     app.kubernetes.io/instance: ocis
+     app.kubernetes.io/version: "3.0.0-alpha.1"
+     app.kubernetes.io/managed-by: Helm
+   finalizers:
+     - kubernetes.io/pvc-protection
+ spec:
+   accessModes:
+     - "ReadWriteMany"
+   resources:
+     requests:
+       storage: "50Gi"

If the PeristentVolume policy is set to reclaim (via the StorageClass), this upgrade could lead to data loss. The same applies to an upgrade 0.1.0 -> 0.3.0

[wkloucek]

One can not just remove the Helm related tags from the PVCs and reference it via the existingClaims options, because Helmm will still remove the PVCs.

[wkloucek]

after #305 this patch would be possible to be compatible to 0.1.0:

diff --git a/charts/ocis/templates/_common/_tplvalues.tpl b/charts/ocis/templates/_common/_tplvalues.tpl
index d225154..f84fbf3 100644
--- a/charts/ocis/templates/_common/_tplvalues.tpl
+++ b/charts/ocis/templates/_common/_tplvalues.tpl
@@ -264,7 +264,14 @@ automountServiceAccountToken: true
 oCIS persistence dataVolumeName
 */}}
 {{- define "ocis.persistence.dataVolumeName" -}}
-{{ printf "%s-data" .appName }}
+{{ $appName := .appName -}}
+{{- if eq $appName "storageusers" -}}
+{{ $appName = "storage-users" -}}
+{{- end -}}
+{{- if eq $appName "storagesystem" -}}
+{{ $appName = "storage-system" -}}
+{{- end -}}
+{{ printf "%s-data" $appName }}
 {{- end -}}
 

[wkloucek]

#306 (in combination with #305) introduces a way to allow an upgrade from 0.1.0 to 0.3.0:

one has to set this values for the 0.3.0 installation:

• services.storagesystem.persistence.claimName = storage-system-data
• services.storageusers.persistence.claimName = storage-users-data

[wkloucek]

Other changes:

• services.storageusers.storageBackend.driverConfig.s3ng.secretKey and services.storageusers.storageBackend.driverConfig.s3ng.accessKey have been deprecated. Please set them via the secretRefs.s3CredentialsSecretRef secret instead.
• If you had set services.web.config.disableFeedbackLink = true, then you need to replace it by services.web.config.feedbackLink.enabled = false
• In order to persist the instance logo, that can changed via Web UI, services.web.persistence.enabled must be set to true. In prior releases Web didn't have any persistence.

[mmattel]

• Are you going to make a 0.3.1 post merging 305/306 ? (or dump 0.3.0 and recreate it)
• I would care about 030->031 in docs
• I will add the above to the breaking changes list

[mmattel]

In order to persist the instance logo, that can changed via Web UI, services.web.persistence.enabled must be set to false.

According the values yaml description of 0.3.0
Enables persistence. Is recommended to be enabled on production installations.

It defaults to false according to the values yaml description and sounds conflicting with the statements given. I also do not get it why this is a breaking change.

[mmattel]

Noticeable change to be mentioned: Add secret generation to main helm chart.