Upgrading the Solution Designer Environment

6 Upgrading the Solution Designer Environment

This chapter describes the tasks you perform in order to apply a change or upgrade a component in your Solution Designer cloud native environment.

Before you upgrade your cloud native environment, you must compare the sample instance specification of the new toolkit with the sample from the current one and migrate your customizations to the new specification.

Solution Designer Upgrade Procedures

The Solution Designer cloud native owned upgrade procedures are:

Specification File Update
Database Schema upgrade
Solution Designer application upgrade

Change or upgrade procedures that are dictated by Solution Designer are applied using the scripts and the configuration provided in the toolkit.

Specification File Update

You can update the instance specification file for the changes in database schema and the Solution Designer application. Examples include updating the Solution Designer DB Installer image, changing an existing value, changing the Solution Designer images, or supplying something new such as a secret.

Edit the instance specification to set the container image location and tag in each microservice location. See "Configuring the Instance Specification" for more information on configuring the instance specification file.

Database Schema Upgrade Procedure

Changes impacting the database Schema can be found in any of the instance specification file.

To perform a database schema upgrade:

Scale down initiative-manager, workspace-manager, and landing-page-api.
```
$OCSCD_CNTK/scripts/scale-down.sh -i ocscd -s $SPEC_PATH -m im,wm,lpapi
```

Run the following command to install schema in database:

$OCSCD_CNTK/scripts/install-db.sh -i ocscd -s $SPEC_PATH -c 4

Solution Designer Application Upgrade

Changes impacting the Oracle Communications Service Catalog and Design - Solution Designer application can be found in any of the instance specification files.

Run the following command to upgrade the Solution Designer instance to push out the changes you just made to the running instance:

$OCSCD_CNTK/scripts/update-instance.sh -i ocscd -s $SPEC_PATH

Post-upgrade Tasks

When you upgrade from any earlier version of Service Catalog and Design to 8.3.0.1 or higher, run the following scripts to complete the upgrade process:

post_install.sh: Add the Type Launch for the external systems.
migrate_connections.sh: Migrate Connections to External Systems.

Adding Participant

When you upgrade from an earlier version of SCD to the version 8.3.0.1 or higher, you must run the post_install.sh script to add new participants (such as LAUNCH) and grant publish access. Run this script once per upgrade. Do not rerun it after it has completed successfully.

You can run the post_install.sh script from the workspace-manager container after all services are up and stable. The script is available in workspace-manager after all SCD services are running after the upgrade.

Run the following command to run the script:

sh post_install.sh

Note:

Do not run this script for a new installation.

Migrating Connections to External Systems

After upgrading to SCD 8.3.0.1 or later from earlier versions (8.3.0 or earlier) of Service Catalog and Design, existing Connections must be migrated to the new External Systems model. Run the migrate_connections.sh script located at ocscd-image-builder/staging/im once to complete this migration and ensure integrations continue to function.

Note:

The migrate_connections.sh script must be run only one time when you upgrade from earlier versions to SCD 8.3.0.1 or higher.

Prerequisites:

A Linux system to run the script (the script can be run from any Linux host with network access to the SCD instance).
The upgrade to SCD 8.3.0.1 or laterss is complete and all SCD services are up and running.
Access the Solution Designer application.
Your user account has the Service Catalog Admin role.
Set the following OIDC configuration as environment variables on the host where you run the script:
- export OIDC_CLIENT_ID= client_id
- export OIDC_CLIENT_SECRET=client_secret
- export OIDC_TOKEN_ENDPOINT=token_endpoint_url
- export SCD_BASE_URL=scd_base_url
You have administrator credentials for authentication during the migration.

Run the following commands in the shell to migrate connections to external systems:

cd ocscd-image-builder/staging/im
sh migrate_connections.sh

After you run the script, you receive a Connections migrated successfully message in the prompt. In case of failure, check the migrateConnectionsResponse.json file and perform necessary corrections. Re-run the script after all the corrections are done. You can also see SCD application logs for more information regarding the failure. Common causes of failure include:

Incorrect administrator credentials
Incorrect OIDC configuration values
Services not being fully started after upgrade
Network or connectivity issues

Note:

Do not re-run the script after a successful migration.

After you complete the migration successfully, you may remove the environment variables that you set.

Upgrades to Infrastructure

From the point of view of Solution Designer instances, upgrades to the cloud infrastructure is rolling upgrades.

Note:

All infrastructure upgrades must continue to meet the supported types and versions listed in the Service Catalog and Design documentation's certification statement.

Rolling upgrades are where, with proper high-availability planning (like anti-affinity rules), the instance as a whole remains available as parts of it undergo temporary outages. Examples of this are Kubernetes worker node OS upgrades, Kubernetes version upgrades.

Kubernetes Infrastructure Upgrades

Follow standard Kubernetes practices to upgrade these components. The impact at any point should be limited to one node - master (Kubernetes and OS) or worker (Kubernetes, and OS). If a worker node is going to be upgraded, drain and cordon the node first. This will result in all pods moving away to other worker nodes. This is assuming your cluster has the capacity for this - you may have to temporarily add a worker node or two. For Solution Designer instances, any pods on the cordoned worker will suffer an outage until they come up on other workers. As each worker undergoes this process in turn, pods continue to terminate and start up elsewhere, but as long as the instance has pods in both affected and unaffected nodes, it will continue to process orders.

Miscellaneous Upgrade Procedures

This section describes miscellaneous upgrade scenarios.

Network File System (NFS)

If an instance is created successfully, but a change to the NFS configuration is required, then the change cannot be made to a running Solution Designer instance. In this case, the procedure is as follows:

Stop the Solution Designer instance or specifically the uim-participant.
Update the nfs details in the instance specification.
Start the instance.