Once WKO is installed in a Kubernetes cluster, it needs to know which namespaces will have OSM instances. Of interest are two mechanisms:

• List: WKO is given an explicit list of namespaces. This is done by upgrading the WKO helm chart to put in a new value for the list (one that takes the existing value and either adds a new namespace or removes one of the namespaces). This mechanism is supported in WKO 3.x and 4.x and is the mechanism in OSM 7.4.1 CNTK as well (upto 7.4.1.0.13). With this, the user needs RBAC access to the WKO namespace, which is likely administratively problematic in a large shared environment.
• Label: When WKO is installed, it is given a label to look for in namespaces. Any namespace in the cluster that has that label is monitored. Adding or removing that label from a namespace has the effect of adding or removing that namespace from WKO's monitoring. This mechanism is supported in WKO 4.x. With this, the user needs RBAC access only to the OSM project namespace and not to WKO namespace.

For OSM cloud native, the recommendation is to use the Label mechanism for WKO 4.x and especially for WKO 4.0.8 and newer.

Before starting with the procedure in this section, refer to OSM Compatibility Matrix for release 7.5.0 for the list of supported WKO versions. It is mandatory to have WKO installed with label-based monitoring mechanism for OSM 7.5.0.

If your existing WebLogic Kubernetes Operator satisfies the OSM 7.5.0 version requirements and uses the label-based monitoring mechanism, no action is required. Skip to the "Ingress Controller" section.

If you need to upgrade, it is recommended to install the new WKO into a new namespace. As individual namespaces are deregistered from old WKO and registered to new WKO, eventually, the old WKO will no longer be managing any namespaces. It can then be safely uninstalled.

• Refer to Weblogic Kubernetes Operator documentation for operator installation at: https://oracle.github.io/weblogic-kubernetes-operator/managing-operators/
• During installation, it is strongly recommended to choose a specific label that this version of WKO must look for, rather than relying on the default label. Relying on the default label causes problems when multiple WKOs need to be installed for any reason (such as during a phased WKO upgrade).
• To provide the custom label, use the domainNamespaceLabelSelector parameter as shown below.
• It is recommended that the custom label you select is descriptive and unique to this WKO. In the example below, this is achieved by specifying the full WKO version.

  # Eg: For installing WKO version 4.1.2 with a custom label wlsko412=enabled, use below after configuring the right helm repo
  $ helm install $WLSKO_NS \
   weblogic-operator/weblogic-operator \
   --namespace $WLSKO_NS \
   --version 4.1.2 \
   --set "domainNamespaceLabelSelector=wlsko412\=enabled"

Using your older CNTK, unregister your namespace forcefully with operator using "unregister-namespace.sh" script

# Set required variables with earlier CN values (before upgrade)
$ export OSM_CNTK=<osm_7.4.1_cntk>
$ export WLSKO_NS=<operator_namespace_before_upgrade>
$ export WLSKO_HOME=<path_for_operator_home>
$ $OSM_CNTK/scripts/unregister-namespace.sh -p $PROJECT -t wlsko -f

Install/upgrade your operator by following weblogic operator documentation.

Register OSM namespace with recent weblogic operator using "register-namespace.sh" script.

# Set required variables with OSM CN 7.5.0 values
$ export OSM_CNTK=<osm_7.5.0_cntk>
$ export WLSKO_NS=<operator_namespace_before_upgrade>
$ $OSM_CNTK/scripts/register-namespace.sh -p $PROJECT -t wlsko -l <custom-label>

This section describes the sections that you update in the project specification:

• OSM cloud native 7.5.0 adds new capabilities (such as OSMGW and RTUX microservices) for which there are corresponding sections in the project and instance specification files. See to "Creating OSM Cloud Native Images" for details.
• The default value for Ingress Controller has been set to GENERIC. If you wish to retain Traefik, change this to TRAEFIK.
• If you use GENERIC ingress controller, the required annotations need to be added to the "ingress" section. In the project specification file, ingress.annotations lists the required annotations if you are using Nginx ingress controller. Adjust the annotations based on the ingress controller that you use.
• In OSM 7.4.1 cloud native, there is a separate step to deploy WME WAR file to the instance as a custom archive. In 7.5.0 cloud native, WebLogic Monitoring Exporter can be enabled and disabled by changing the value of enabled in the instance.yaml. By default, it is set to true, which creates a sidecar container for WME using the default image for the version of WebLogic Operator in use. If you want to use a different image than the one that WKO uses, you have a provision to do that by updating WME in the project specification file.
• There are new capabilities added for deploying cartridges. OSM cloud native cartridge deployment supports container image built with par file. Either the url or the Image field should be populated for a particular cartridge but not both. See "Cartridge par Sources" for more details.
• Update the requiredTargetSystems section if your cartridge needs to integrate with external systems using REST API.
• Defining osmWLSTargetNodes restricts all OSM cloud native WebLogic pods and DB Installer pods to worker nodes, that match the label conditions and for these pods and it will take precedence over osmcnTargetNodes.
• The remaining sections for which there are no changes from OSM cloud native 7.4.1 need to be copied as-is to 7.5.0 based on your usage of the respective functionality in OSM cloud native 7.5.0.

This section describes the sections that you update in the instance specification:

• If you are planning to use log masking functionality, uncomment and use the logMaskingCustomRegexes section.
• OSM supports fine graining the log level for OSM core using the instance specification file. Uncomment and use the log section for overriding the default log level.
• WebLogic Monitoring Exporter can be enabled and disabled by changing the value of weblogicMonitoringExporter.enabled in the instance.yaml file. By default, this is set to true.
• You can use FluentD as a sidecar container for reading the logs from OSM Servers and DB Installer. Enable the fluentdLogging section for making use of this functionality. See "Configuring Fluentd Logging" for more details.
• The storage volume must specify "pvc" to be used for persistent storage or as "emptydir" to share with a custom sidecar which is enabled via "sidecar.enabled" in instance specification file.

  storageVolume:
    enabled: true
    type: pvc # Acceptable values are pvc and emptydir
    volumeName: storage-volume
    pvc: storage-pvc # Specify this only in case type is pvc

• If you want to enable a sidecar other than FluentD, make use of the section sidecar.enabled.
• For enabling SSL using generic Ingress, add the annotations required for OSM. The ssl.ingress.annotations section in the instance specification file lists the sample annotations required for OSM if you are using Nginx ingress controller. Add the annotations based on the ingress controller that you choose.
• In the 7.4.1 cloud native, the instance.yaml file contains the loadBalancerPort section. In OSM 7.5.0 cloud native, it is renamed to inboundGateway. As part of the inboundGateway section, you need to provide the host and port details of the actual ingress point or the loadbalancer.
• Using Host Aliases, you can achieve hostname resolution inside the pods. Refer to the hostAliases element and its comments in the instance specification for more details.
• Update the osm-gateway and osmRuntimeUX sections as per "Configuring Target Systems for Events and System Interactions".
• If you have defined targetSystems in the project specification file, provide the details of the respective target system in the instance specification file.
• Copy the remaining sections for which there are no changes from OSM cloud native 7.4.1 as-is to 7.5.0 based on your usage of the respective functionality in OSM cloud native 7.5.0.
• In earlier versions, to enable global trust, the configuration you needed to use was domainTrust.enabled. While this is still supported for backward compatibility, it is deprecated in favor of the configuration domainTrust.globalEnabled. If you are using an instance specification from older versions, consider updating it with this new configuration.

If you have a custom shape specification, identify the standard shape on which your custom shape is based. Make a copy of this standard shape from the OSM 7.5.0 CNTK and make your customization one-by-one to it.

Check OSM Compatibility Matrix for details about the required and supported versions of the pre-requisite software, before proceeding with the upgrade.

$OSM_CNTK/scripts/delete-instance.sh -p project -i instance

$OSM_CNTK/scripts/delete-ingress.sh -p project -i instance

$OSM_CNTK/scripts/unregister-namespace.sh -t traefik -p project

This section lists preparatory steps for the upgrade:

• Take a backup of the working OSM 7.4.1 project and instance specification files or rely on your source code management system to maintain versioning.
• Take the OSM 7.4.1 DB schema backup before the upgrade.
• Take a backup of the following secrets and also if there are any custom OSM secrets created for 7.4.1 cloud native before the upgrade.

  <project>-<instance>-database-credentials
  <project>-<instance>-embedded-ldap-credentials
  <project>-<instance>-weblogic-credentials
  <project>-<instance>-rcudb-credentials
  <project>-<instance>-opss-wallet-password-secret
  <project>-<instance>-runtime-encryption-secret
  <project>-<instance>-openldap-credentials
  <project>-<instance>-osmcn-cred-<user> (If you have this secret created. Ignore, if the secret do not exist.)
  <project>-<instance>-saf-<remote-system> (If you have this secret created. Ignore, if the secret do not exist.)

• Run the following command on each secret which would copy the output to the secret.yaml file. Maintain a separate file for each secret.

  kubectl get secret -n project secretName -o yaml > secret.yaml

• Set the $OSM_CNTK environment variable to point to the 7.5.0 cloud native toolkit.
• Copy the specification files updated in your earlier steps to your $SPEC_PATH location and rename them to match the same as existing 7.4.1 cloud native specification files (to match the existing project name and the instance name).
• (Optional) If you use a newer version of WKO, install the newer version WKO in a new namespace and register the project namespace with it.
• (Optional) If you replace Traefik with another ingress controller, install the new ingress controller.

GRANT execute on dbms_lob to _replace_this_text_with_admin_name_ with grant option;

REVOKE sysdba from _replace_this_text_with_admin_name_;

Make sure you have the updated specification files for OSM 7.5.0 in your $SPEC_PATH.

Run the following command to upgrade the existing OSM schema:

$OSM_CNTK/scripts/install-osmdb.sh -p project -i instance -s $SPEC_PATH -c 1

Make sure you have the updated specification files for OSM 7.5.0 in your $SPEC_PATH.

Run $OSM_CNTK/scripts/create-instance.sh to create an instance with OSM 7.5.0 cloud native artifacts.

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

Once the create-instance.sh script execution is completed, admin and managed server pods will be in the running state.

Create the ingress.

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