Skip to main content
Version: V1-Next

Direct Upgrade Paths

Upgrading from CIVITAS/CORE v1.1 to v1.5

While a direct upgrade from CIVITAS/CORE v1.1 to v1.5 is generally possible, a few things need to be taken into account. While the remarks below sum up the main concerns for a direct upgrade path, all of the notes in the Upgrade Guide are relevant to the direct upgrade path as well and should be reviewed carefully.

warning

Before upgrading your installation, make sure you have backed up everything before you start the upgrade process. For production systems, we highly encourage to try an upgrade in a sandbox/test environment before.

Backup of APISIX Routes

For major changes in the APISIX Helm charts, the Helm chart needs to be manually deleted during the upgrade process. A separate backup of the APISIX API routes is therefore required and can be taken using its API.

Software Component Updates and Version Pinning

Before upgrading, an exhaustive list of software dependencies including their current and target versions should be created. The default software versions as well as image sources for many platform components have changed. Some of the changes are non-optional.

Due to license changes in the latest versions of Bitnami Helm charts and container images, mirrors have been created to reflect their most recent compatible versions. Switching the image source is non-optional as the corresponding tags have already been removed from their original registries.

For optional image updates, make sure to version-pin to the current versions from your inventory to isolate their upgrade and defer to a later step. This is the case for PostgreSQL operator and the Masterportal (for which the upgrade requires configuration changes).

Inventory Upgrade

Update your inventory to the v1.5 schema.

  • replacement of inv_access.group by inv_access.open_data_dataspace (see here)
  • introduction of PostgreSQL Operator configuration (see here)
  • Keycloak configuration restructuring (see here)
  • optional introduction of tenant sections for multi-tenant scenarios (see here)
  • restructuring of the Masterportal configuration section
    • move the Geostack components from inv_cm to inv_gd (as seen in the new structure here)
    • make sure to pin the image tags to your current versions if necessary (see here)
  • update NGSI-LD configuration to the new dataspace configuration if necessary (see here)
  • update the Superset configuration to use the Alpha role permissions for the public role, if the v1.1 behaviour should remain unchanged (see here)

Inventory Validation

After upgrading to the new inventory schema, validate the inventory against the most recent schema version. Common tools and IDEs automatically run the validation if the header is included in your inventory.

# yaml-language-server: $schema=https://gitlab.com/civitas-connect/civitas-core/civitas-core/-/raw/main/core_platform/inventory_schema.json

Upgrade

Perform the upgrade by

  • backing up the APISIX routes (see above)
  • removing the APISIX Helm chart (see here)
  • running the deployment

Cleanup

After the deployment has been successfully run and all software components have been verified, the remaining unused components for APISIX (PV and PVC, see here) can be removed. Depending on your setup, the upgrade of the Masterportal also leaves unused deployments behind that refer to the single-instance Masterportal used until v1.4.1. They can be removed, too.