Offline changes are defined as those requiring OSM to be shutdown before the change can be applied.

All offline upgrades must start with a Scale Down procedure and end with a Scale Up procedure. You can find the explicit steps to perform these activities in Running Operational Procedures.

Once the cluster has been scaled down, you will need to perform either an external procedure (referencing documentation for the component) or follow an OSM cloud native owned procedure. See "OSM Cloud Native Upgrade Procedures" for details.

Figure 11-1 Offline Change Upgrade Paths

Description of "Figure 11-1 Offline Change Upgrade Paths"

As an example, if your use case is to re-deploy an existing cartridge version, then the upgrade path would be "Offline change, offline cartridge deployment", the second flow in the above flow chart. The actual steps involve the following:

• Scale Down
  • Edit the instance specification file to set cluster size to 0.
  • Run upgrade-instance.sh.
• Offline cartridge deployment
  • Edit the project specification file to change the cartridge version.
  • Run manage-cartridges.sh with option sync.
• Scale Up
  • Edit the instance specification file to return cluster size to original (1-18).
  • Run upgrade-instance.sh.

Online changes are changes for which OSM can remain running while the component upgrade is performed. There is, therefore, no operational procedure at the start of the flow, but some paths include a rolling restart after the upgrade procedure is performed.

The component upgrade will either be an external procedure (referencing documentation for the component) or follow an OSM cloud native owned procedure described in "OSM Cloud Native Upgrade Procedures".

If explicit post-upgrade operational activities are required, you can find details in "Running Operational Procedures".

The following flowchart illustrates online change upgrade paths:

Figure 11-2 Online Change Upgrade Paths

Description of "Figure 11-2 Online Change Upgrade Paths"

Changes impacting the PDB can be found in any of the specification files - project, instance or shape.

Examples include updating the OSM DB Installer image.

To perform a PDB upgrade procedure:

1. Make the necessary modifications in your specification files.
2. Invoke $OSM_CNTK/scripts/install-osmdb.sh with the command appropriate for your use case.

   To see a list of options, invoke with -h.

Changes impacting the OSM application can be found in any of the specification files - project, instance or shape.

Examples include changing an existing value, changing the OSM image or supplying something new such as a secret or a new WDT extension.

To perform OSM application upgrade:

1. Make the necessary modifications in your specification files.
2. Invoke $OSM_CNTK/scripts/upgrade-instance.sh to push out the changes you just made to the running instance. This also triggers introspection for upgrade paths where introspection is required.
3. In upgrade paths where a manual restart is required, restart the instance. See "Restarting the Instance" for details.

Offline deployment mode supports deployment of new cartridges, deployment of new versions of existing cartridges, fast undeploy and re-deployment of existing cartridge versions with changes.

Changes impacting the cartridges can be found in the project specification file.

In order to perform an offline deployment, you must not have managed servers running.

To perform an offline cartridge deployment:

1. Scale down your managed server count. See “Scaling Down the Cluster” for more details.
2. Deploy the cartridges:
   • Make the necessary modifications in your project specification.
   • Run the following command:

     $OSM_CNTK/scripts/manage-cartridges.sh -p project -i instance -s spec_Path –c sync

3. Scale up your managed server count. See “Scaling Up the Cluster” for more details.

Online deployment mode supports deployment of new cartridges, deployment of new versions of existing cartridges and fast undeploy. It does not support re-deployment of existing cartridges.

The changes impacting the cartridges can be found in the project specification file.

In order to perform an online deployment, you must have a minimum of two managed servers running.

To perform an online cartridge deployment:

1. If necessary, scale up your managed server count (2 or more). See “Scaling Up the Cluster” for more details.
2. Deploy the cartridges:
   • Make the necessary modifications in your project specification.
   • Invoke the following script:

     $OSM_CNTK/scripts/manage-cartridges.sh -p project -i instance -s spec_Path -c sync -o

When any of the specification files have changed, invoke the upgrade-instance.sh script to trigger the operator's introspector to examine the change and apply it to the running instance.

The scaling down procedure described here is only in the context of the upgrade flow diagram. Hence, scaling down is down to 0 managed servers. A generalized scaling can change the cluster size down to a value between 0 and 18 (both inclusive) in any desired increment or decrement.

To scale down the cluster, edit the instance specification and change the clusterSize parameter to 0. This terminates all the managed server pods, but leaves the admin server up and running.

$OSM_CNTK/scripts/upgrade-instance.sh -p project -i instance -s $SPEC_PATH

The scaling up procedure described here is only in the context of the upgrade flow diagram. Hence, scaling up is up to the initial cluster size. A generalized scaling can change the cluster size up to a value between 0 and 18 (both inclusive) in any desired increment or decrement.

To scale up the cluster, edit the instance specification and change the value of the clusterSize parameter to its original value to return the cluster to its previous operational state.

$OSM_CNTK/scripts/upgrade-instance.sh -p project -i instance -s $SPEC_PATH

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

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

restart-instance.sh parameters
      -p projectName : mandatory
      -i instanceName : mandatory
      -s specPath : mandatory; locations of specification files
      -m customExtPath : optional; locations of custom extension files
      -r restartType : mandatory; what kind of restart is requested
    # specPath and customExtPath take a colon(:) delimited list of directories
    # restartType can take the following values:
      * full: Restarts the whole instance (rolling restart)
      * admin: Restarts the WebLogic Admin Server only
      * ms: Restarts all the Managed Servers (rolling restart)

    # or just -h for help

$OSM_CNTK/scripts/restart-instance.sh -p project -i instance -s $SPEC_PATH -r full

When the entire domain, including the admin server, needs to be taken offline, then the full shutdown and full startup procedures follow. This can be used to perform a "fast delete" or "dehydration" of the domain, instead of a full delete-instance operation where you may have to be concerned about the secrets and other pre-requisites being deleted. To quickly restore the domain, simply perform the startup procedure.

Shutting Down the Cluster

# Operational control parameters 
# scope - domain or cluster 
serverStartPolicy: NEVER 

$OSM_CNTK/scripts/upgrade-instance.sh -p project -i instance -s $SPEC_PATH

Starting Up the Cluster

# Operational control parameters 
# scope - domain or cluster 
serverStartPolicy: IF_NEEDED 

$OSM_CNTK/scripts/upgrade-instance.sh -p project -i instance -s $SPEC_PATH