A Differences Between OSM Cloud Native and OSM Traditional Deployments

If you are moving from a traditional deployment of OSM to a cloud native deployment, this section describes the differences between OSM cloud native and OSM traditional.

• Embedded LDAP

  You no longer need to create human users using the embedded LDAP capabilities of WebLogic Server.

  By default, OSM uses the WebLogic embedded LDAP as the authentication provider and all OSM system users are created in embedded LDAP during the creation of the instance. The OSM cloud native toolkit provides a sample configuration that uses OpenLDAP to demonstrate how to integrate with external LDAP server for human users.

  A sample script for populating users to OpenLDAP can be found at: $OSM_CNTK/samples/credentials/manage-cartridge-credentials.sh. See "Provisioning Cartridge User Accounts" for more details.

• Credential Store for Automation Code

  The existing Fusion MiddleWare Credential Store framework has been replaced with Kubernetes Secrets in OSM cloud native. See "Provisioning Cartridge User Accounts" for more details on configuration differences. However, the automation plugin code in your cartridges that accesses this information using the automation framework APIs continues to receive the credentials transparently.

• Credential Store for Custom Code

  If you use custom code that relies on the OPSS Keystore Service, then port the code. This mechanism is no longer supported. The recommended replacement is Kubernetes Secrets. Kubernetes Secrets can be specified as custom secrets in OSM cloud native and are mounted into the instance's pods for your code to use and access.

• XMLIE Operations

  The following operations are still available using XMLIE. However, these should not be used in OSM cloud native. See the following table that describes the replacement mechanism for using these operations.

  Table A-1 Replacement Mechanisms for XMLIE Operations

  Operation	Replacement Mechanism
  credStoreAdmin	Sample script in $OSM_CNTK/samples/credentials/manage-cartridge-credentials.sh. Use the secret option in the user text file. See "Provisioning Cartridge User Accounts" for more details.
  userAdmin	Sample script in $OSM_CNTK/samples/credentials/manage-cartridge-credentials.sh. Use the ldap option in the user text file. See "Provisioning Cartridge User Accounts" for more details.
  import	OSM DB Installer. Additionally, this operation relies on a pre-built par file, instead of an XML model file. It can use a local file or pull it from a remote repository. See "Working with Cartridges" for more details.
  fastUndeploy	OSM DB Installer. See "Working with Cartridges" for more details.

• WebLogic Domain Configuration

  In a traditional deployment of OSM, the WebLogic domain configuration is done using WLST or the WebLogic Admin Console. In OSM cloud native, domain configuration is done by providing WDT metadata in the instance creation process. See "Extending the WebLogic Server Deploy Tooling (WDT) Model" for details.

  Do not perform WebLogic administrative activities such as changing the configuration, shutting down and restarting the server directly on the WebLogic Server cluster of the OSM cloud native instance. The same applies to the activities done using WebLogic Server Admin Console, WLST invocation, or any mechanism, other than those supplied by the specification files for updating and upgrading the OSM cloud native instance.

• Incoming SAF and Outgoing SAF

  For incoming SAF agents, the originator must use T3 over HTTP tunneling.

  Outgoing SAF mechanism has not changed.

• OSM Solution Cartridges

  Your OSM cartridges work normally in OSM cloud native.

  For cartridges that might access a custom property file, this can be done by injecting custom files into the specifications. See "Injecting Custom Configuration Files" for details. An alternative is to use a database table instead. This has the advantage of becoming part of backups and replication automatically.

  Using custom tables or datasources needs to be declared by providing the necessary WDT extensions. See "Extending the WebLogic Server Deploy Tooling (WDT) Model" for details.

• OSM Workgroups: OSM Workgroups, including user and workgroup associations, are still managed through the orchestration UI.
• OSM User Interfaces: All OSM user interfaces are still available with both OSM traditional and OSM cloud native deployments. The UIs can be accessed using the default hostname: instance.project.osm.org and port 30305, which is the default but configurable and the path that is necessary for the specific UI. For example, to access the Order Management UI, use:

  http://instance.project.osm.org:30305/OrderManagement/Login.jsp

• OSM API: Accessing OSM through the traditional APIs such as the Web Services API, the REST API, and the XML API has not changed.
• Order Partitioning Realm Configuration: Runtime configuration of order partitioning realms is not supported. In traditional OSM deployments, this is specified in the oms-config.xml file as a set of files against the oracle.communications.ordermanagement.OrderPartitioningRealmConfigFileURLs parameter.
• OSM Runtime Parameters: Some OSM runtime parameters can be controlled using the oms-config.xml file. This configuration is still available in OSM cloud native, but is managed differently. See "Configuring OSM Runtime Parameters" for more details.
  • Operational Order Jeopardies: Configuration to support operational order jeopardies is specified in the oms-config.xml file as a set of files against the oracle.communications.ordermanagement.order.OperationalOverrideFileURLs parameter. These configuration files are custom files and must be injected properly. See "Injecting Custom Configuration Files" for details.
  • OACC Runtime Configuration: This is specified in the oms-config.xml file as a set of files against the AutomationConcurrencyModels parameter. These configuration files are custom files and must be injected properly. See "Injecting Custom Configuration Files" for details.