6.4 KiB
Upgrade migrations
Disclaimer
We do not offer support for upgrades before we reach openDesk 1.0.
Though we try to ease the pain when it comes to 0.x upgrades. That is what this document is for.
Limitations:
- We assume that the PV reclaim policy is set to
delete, so expect that PVs get deleted as soon as the related PVC was deleted and will cover an explicit delete for PVs.
Releases upgrades
From v0.9.0
Automated migrations
Updated IAM component Nubus
openDesk is integrating the latest Nubus development from Univention. The now redundant and scalable LDAP requires migration activities. These have been automated to avoid manual interaction. The run_2 of the openDesk
upgrade migrations executes the following steps:
- Stage PRE:
- Delete service
ums-keycloak, as it will be recreated headless. - Scale down
statefulset/ums-ldap-serverandstatefulset/ums-ldap-notifierin preparation or the next step: - Create two new PVCs
shared-data-ums-ldap-server-primary-0andshared-data-ums-ldap-server-primary-1for the new LDAP primary pods as copy from the existingshared-data-ums-ldap-server-0. The LDAP secondaries will sync from the primary nodes.
- Delete service
- Stage POST:
- Restart Keycloak.
Manual cleanup
Currently we do not execute possible cleanup steps as part of the migrations POST stage. So you might want to remove the no longer used PVCs after successful upgrade:
NAMESPACE=<your_namespace>
kubectl -n ${NAMESPACE} delete pvc shared-data-ums-ldap-server-0
kubectl -n ${NAMESPACE} delete pvc shared-run-ums-ldap-server-0
From v0.8.1
Updated cluster.networking.cidr
- Action:
cluster.networking.cidris now an array (was a string until 0.8.1), please update your setup accordingly if you explicitly set this value. - Reference:cluster.yaml
Updated customizable template attributes
- Action: Please ensure you update you custom deployment values according with the updated default value structure.
- References:
functional.prefix forauthentication.*,externalServices.*,admin.*andfilestore.*, see functional.yaml.debug.prefix forcleanup.*, see debug.yaml.monitoring.prefix forprometheus.*andgraphana.*, see monitoring.yaml.smtp.prefix forlocalpartNoReply, see smtp.yaml.
migrations S3 bucket
- Action: For self managed/external S3/object storages, please ensure you add a bucket
migrationsto your S3. - Reference:
objectstores.migrationsin objectstores.yaml
Related components and artefacts
openDesk comes with two upgrade steps as part of the deployment, they can be found in the folder /helmfile/apps as all other components:
migrations-pre: Is the very first app that gets deployed.migrations-post: Is the last app that gets deployed.
Both migrations have to be deployed exclusively at their first/last position and not in parallel with other components.
The status of the upgrade migrations is tracked in the ConfigMap migrations-status, more details can be found in the README.md of the related container image.
Development
When a new upgrade migration is required, ensure to address the following list:
- Update the generated release version file
global.generated.yamlat least on the patch level to test the upgrade in your feature branch as well as trigger it in thedevelopbranch after the feature branch was merged. The set value gets overwritten during the release process with the release's actual version number. - You have to implement the migration logic as a runner script in the
opendesk-migrationsimage. Please find more instructions in the linked repository. - You most likely have to update the
opendesk-migrationsHelm chart within therulessection of therole.yamlto provide the permissions required for the execution of your migration's logic. - You have to set the runner's ID you want to execute in the migrations.yaml.gotmpl. See also the
migrations.*section of the Helm chart's README.md. - Update the
charts.yamlandimages.yamlto reflect the newer releases of theopendesk-migrationsHelm chart and container image.