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.

Rolling Restart

Occasionally, you may need to restart microservices in a rolling fashion, one at a time. This does not result in downtime, but only reduced capacity for a limited period. A rolling restart can be triggered by invoking the restart-instance.sh script. This script can restart the whole instance in a rolling fashion, or only the admin server or all the managed servers in a rolling fashion. Some operations may automatically trigger rolling restart. These include changes such as image updates, parameter changes, and so on pushed via the upgrade-instance.sh script.

Solution Designer Upgrade Procedures

The Solution Designer cloud native owned upgrade procedures are:

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.

Database Schema Upgrade Procedure

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

Examples include updating the Solution Designer DB Installer image.

To perform a DB Schema upgrade procedure:

Make the necessary modifications in your specification files.
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

Scale up the initiative-manager and workspace-manager back to their settings in the specification file.
```
$OCSCD_CNTK/scripts/update-instance.sh -i ocscd -s $SPEC_PATH
```

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 file.

Examples include changing an existing value, changing the Solution Designer images or supplying something new such as a secret.

To perform the Solution Designer application upgrade:

Make the necessary modifications in your specification files.
Run the following command to upgrade the instance to push out the changes you just made to the running instance:
```
$OCSCD_CNTK/scripts/update-instance.sh -i ocscd -s $SPEC_PATH
```

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 and Docker version upgrades.

Kubernetes and Docker Infrastructure Upgrades

Follow standard Kubernetes and Docker practices to upgrade these components. The impact at any point should be limited to one node - master (Kubernetes and OS) or worker (Kubernetes, OS, and Docker). 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 pr specifically the uim-participant.
Update the nfs details in the instance specification.
Start the instance.

Running Operational Procedures

This section describes the tasks you perform for a planned upgrade to the Solution Designer cloud native environment. You must consider if the change in the environment fundamentally affects the processing to the extent that Solution Designer should not run when the upgrade is applied or Solution Designer can run during the upgrade but must be restarted to properly process the change.

The operational procedures are performed using the Solution Designer cloud native specification files and scripts.

The operational procedures you perform for upgrading your cloud environment are:

Scaling down the instance
Scaling up the instance
Restarting the instance

Scaling Down the instance

The scaling down is bringing down to 0 microservices. This does not include any of the third party services running in the cluster like Opensearch, Kafka, and Relying party.

Scale down using the following command:

$OCSCD_CNTK/scripts/scale-down.sh -m full

Scaling Up the instance

Scaling up is up to the initial replica count. A generalized scaling can change the number of replicas up to a value between 0 and 1.

To scale up the instance, run the update instance script:

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

Restarting the Instance

The Solution Designer cloud native toolkit provides a script (restart-instance.sh) that you can use to perform different flavors of restarts on a running instance of Solution Designer cloud native.

Following is the usage of the restart-instance.sh script

restart-instance.sh parameters
      -i instanceName : mandatory
      -s specPath : mandatory; locations of specification files
      -r restartType : mandatory; what kind of restart is requested
    # restartType can take the following values:
      * full        - Restart the whole instance (rolling restart)
      * lpapi       - Restart all the Landing Page API Servers (rolling restart)
      * im          - Restart all the Initiative Manager Servers (rolling restart)
      * wm          - Restart all the Workspace Manager Servers (rolling restart)
      * ocscdui     - Restart all the OCSCD UI Servers (rolling restart)
      * up          - Restart all the UIM Participant Servers (rolling restart)
      * router      - Restart all the ocscd-router Servers (rolling restart)

    # or just -h for help

For example, to restart a complete instance, run the following command:

$OCSCD_CNTK/scripts/restart-instance.sh -i ocscd -s $SPEC_PATH -r full

Rotating Secrets

Rotating secrets and passwords is an important part of securing your instance. To perform credential update, run the following:

Update the password or secret in the system that is being updated For example, OIDC secret in your IDP.
Run the following command to update the secret into SCD.
```
$OCSCD_CNTK/scripts/manage-instance-credentials.sh -i ocscd update <secrets> 
```
Choose one or more of the following as needed:
- ocscd-oidc: OIDC client ID and secret
- s3: access key and secret
- db-schema: Database schema passwords
- db: Administrator user password
Restart Solution Designer for the microservices to uptake the new secrets. See "Restarting the Instance" on how to restart the instances.