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:

  1. Specification File Update
  2. Database Schema upgrade
  3. 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:

  1. 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
  2. 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

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:

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