Skip to main content

Migrating to 1.6.0

Migration Guide​

Here you can find the needed steps to upgrade your current Witboost installation to v1.6.0. Please refer to the release notes for a detailed list of changes and improvements. This guide is intended for users who are currently running Witboost version 1.5.0 or earlier and wish to upgrade to version 1.6.0.

Follow these steps to migrate from the previous version to Witboost version 1.6.0:

Backup Your Data​

Before starting the migration, ensure you have a complete backup of your database and configuration files.

Update Dependencies​

Ensure all the dependencies in the Helm files are updated to their compatible versions for 1.6.0. Refer to the published Helm chart for details.

Upgrade Steps​

Core​

This release brings some new notifications. To let the System Fix Needed and System Operations Impact notifications work, you should indicate the trigger environments in your app-config:

notifications:
   systemFixNeeded:
      triggerEnvironments: ['production'] # this means: send a notification when a policy fails for a resource published in the production environment
   systemOpsImpact:
      triggerEnvironments: ['production'] # same meaning as above
   systemUpdate:
      triggerEnvironments: ['production'] # this means: send a notification when a system has been updated in the production environment
   newSystem:
      triggerEnvironments: ['production'] # same meaning as above

Make sure the environments specified here match one of the configured witboost environments.

To continue using the email notification service, or to use the new EmailChannel for the new notifications, you should set the following configuration:

notifications:
   emailConfig:
      enabled: true

Otherwise, you can set it to false if you want to disable email sending.

Coordinator​

The default behavior for config provisioning-coordinator.supported-kinds has been modified. This is a list of supported deployment unit kinds (kind property in the descriptor).

  • Before: If not provided, only dataproduct and system kinds were supported
  • Now: If not provided, all kinds are supported (suggested configuration)

This release brings events generation on the coordinator and computational governance platform. Those events will be forwarded to the UI that will react accordingly e.g. produce a notification. To enable events generation you will need to add two sections:

computational-governance-platform {
    events = {
        enabled = true
        events-backend-base-url = "http://localhost:7007/api/events"
        events-backend-base-url = ${?EVENTS_BACKEND_BASE_URL}
        runtime-policy-failed-topic = "governance.runtime-policy-failed"
    }

   # you should already have the following section in place. this is just to make sure.
   notification = {
      secret = "" # insert the secret token from app-config.yaml in the UI project
      secret = ${?NOTIFICATION_SECRET}
   }
}

provisioning-coordinator {
   events = {
      events-backend-base-url = "http://localhost:7007/api/events"
      events-backend-base-url = ${?EVENTS_BACKEND_BASE_URL} # Insert the UI URL followed by `/api/events`
      system-deployed-topic = "coordinator.system-deployed"
      secret = ${?EVENTS_SECRET} # insert the secret token from app-config.yaml in the UI project
      is-enabled = true
   }
}