Upgrade Notes
Release 3.2.0
Contents:
- Action Required: Upgrade scenarios which require action before upgrading
- Informative: Information about changes/events which you can expect to observe during/after an upgrade to Cloud Control 3.2
Action Required
Upgrading Cloud Control deployments may require action if your deployment satisfies any of the following criteria:
Authoritative Server with LUA records
Authoritative Server 5.1 introduces a new configuration item enable-lua-record-updates which defaults to no to disallow updating LUA records as part of AXFR/IXFR, DNS Update or API operations. This is a change in default behaviour and will impact any Cloud Control users who upgrade to 3.2 while making use of LUA record modifications.
To retain the ability to modify LUA records in the Authoritative Server in Cloud Control 3.2, the new parameter enableLuaRecordUpdates must be set to true for any Authoritative Server instance sets on which you want to retain this functionality. This new parameter is documented on the Authoritative Server Configuration Reference.
Upgrading from Cloud Control 2.2.2 (or earlier)
Upgrading from Cloud Control 2.2.2 (or earlier) to Cloud Control 3.2 requires upgrading to a Cloud Control 3.1 release as an intermediary step, if the deployment makes use of the following:
- Authoritative Server with Lightning Stream as backend
This is due to the simplification of the Lightning Stream migrator built into Cloud Control as per release 3.2, to facilitate improved future development & maintenance of the involved components.
Informative
Authoritative Server with Lightning Stream
Authoritative Server has been upgraded to 5.1, which includes schema changes for the LMDB backend used when Authoritative Server is combined with Lightning Stream. If you are upgrading to Cloud Control 3.2 and have Lightning Stream included in your deployment, there will be a migration performed by the Migrator.
NATS StatefulSet & Pods renamed
To facilitate the removal of Helm's client-side features, the NATS StatefulSet & Pod objects have been renamed. This is done to avoid requiring manual intervention due to Kubernetes restrictions on modifications to specific parameters on the StatefulSet used by NATS. Previously these had their names prefixed by nats and now use the prefix nats-cc. Associated objects such as Services & Secrets have not been modified to ensure this change has no impact on existing configurations.
Secrets Manager transition
Cloud Control 3.2 introduces a new module on the operator, the Secrets Manager. This module facilitates the transition towards generating secret values within the Kubernetes cluster (server-side), instead of directly via Helm (client-side). The functionality of the Secrets Manager is explained in detail here.
To ensure this transition can occur without existing Cloud Control deployments regenerating important secret values, a 2 stage approach will be followed:
Stage 1
Cloud Control 3.2 has a Legacy feature in the Secrets Manager, which will ensure the secret values previously generated by Helm in CC 3.1 (or earlier) are cloned into the new Secrets Manager controlled Secret objects. For example, generated values in a legacy Secret named auth-testauth will remain in CC 3.2, but will also be cloned to the new Secrets Manager equivalent Secret named auth-testauth-ccsm.
The -ccsm version of this Secret will be used by Cloud Control components which need to reference the values contained within it.
If you have any automation which makes use of these Secret objects, you should transition to the -ccsm version after upgrading to Cloud Control 3.2.
Stage 2
Cloud Control 3.3 will have a requirement that only upgrades from CC 3.2 are supported if generated Secret values are to be retained. This allows us to remove the legacy Secrets and complete the transition towards the Secrets Manager controlled Secret objects. For example, the auth-testauth Secret will no longer be present and only the auth-testauth-ccsm Secret will remain.