• OSM will no longer support the management of LDAP server via OSM CNTK scripts (such as managing accounts, users and groups in the LDAP server).
• Support for OpenLDAP authentication provider out of the box through OSM has been deprecated.
• Support for Generic LDAP to adapt all supported directory services by weblogic which uses LDAP including OpenLDAP has been introduced.
• OSM will be providing functionality to users for other directory services via model extensions.

OSM provides two ways to integrate the LDAP service:

• Generic LDAP: It supports many of the LDAP vendors.
• Model Extensions: If a specific LDAP vendor is not compatible with Generic LDAP provider, a custom model extension can be used to configure a vendor-specific LDAP provider.

Secret Creation

• ldap-secret-creation

  $OSM_CNTK/samples/credentials/manage-osm-ldap-credentials.sh -p project -i instance -c create -l ldap

• After executing the above command, the script asks the host and domain node to get users and groups, user domain node and password to access the LDAP server.
• After providing all the credentials, the script creates project-instance-ldap-credentials secret which is used while creating an instance to import users from the LDAP server and assign respective groups.

Enabling LDAP in Project Specification

<project>.yaml

#External authentication
authentication:
# When enabled, kubernetes secret "project-instance-ldap-credentials"
# must exist  
ldap:    
   enabled: true

After above configurations, create the OSM cloud native instance. If it is already running, delete it and create it again.

Other LDAP Providers as listed by Weblogic can be used via model extensions.

• Add the custom model tpl file which has configurations for the LDAP provider to the $OSM_CNTK/samples/_custom-domain-model.tpl.

custom-ldapprovider.tpl

{{- if .Values.custom.jms }}
custom-jms-support.74.yaml: |+
  {{- include "osm.custom-jms-support" $root | nindent 2 }}
{{- end }}
custom-<ldap-provider>-support.76.yaml: |+
  {{- include "osm.custom-ldap-provider-support" $root | nindent 2}}

• Enable custom flag and add both custom-domain-model.tpl and custom-ldap-provider-support.tpl to wdtFiles in the project specification file.

project.yaml

# Sample WDT extensions can be enabled here. When enabled is true, then
# _custom-domain-model.tpl needs to be un-commented.  Custom template files can
# also be added.
custom:
  enabled: true
  application: false
  jdbc: false
  jms: false
  #wdtFiles: [] # This empty declaration should be removed if adding items here.
  wdtFiles:
  # - _myWDTFile1.tpl
  # - _myWDTFile2.tpl
   - _custom-domain-model.tpl
   - _custom-ldap-provider-support.tpl

• Create the OSM cloud native instance. If it is already running, delete it and create it again. Here custom-models-path refers to the directory where the wdtFiles exist.

create-instance

$OSM_CNTK/scripts/create-instance.sh -p project -i instance -s specpath -m custom-models-path

Sample LDAP Provider Model File

If the decision is made to use a vendor specific LDAP provider instead of Generic LDAP provider, to illustrate the model extension required a sample model extension for Active Directory is provided at $OSM_CNTK/samples/customExtensions/_custom-active_directory-support.tpl. Such extensions can be populated with direct values for the fields or by referencing a custom secret. If referencing a custom secret, the secret should contain referenced fields and the secret must be specified in the section for custom secrets in project specification.

<project>.yaml

#Custom secrets at Project level
# Any custom secrets that can be used within WDT metadata fragments specified
# above. Secrets used in instance specific WDT should be listed in the instance
# specification. More than one secret name can be provided
project:
 customSecrets:
   #secretNames: {} # This empty declaration should be removed if adding items here.
   secretNames:
    - ldap-provider-secret

To configure a vendor specific LDAP Provider, refer to the "WebLogic Server MBean Reference Document" for the WebLogic version in your image manifest file, under Configuration MBeans → Security MBeans. Alternatively, use the method described in the section "Displaying Valid Attributes and Child Attributes of a WDT Model".

Generic LDAP also supports OpenLDAP. In case you still want to use OpenLDAP Authentication Provider, you should follow the steps for "Using Generic LDAP" with minor changes.

To create the secret, replace ldap provided with -l option in the secret creation command with openldap.

openldap-secret-creation

$OSM_CNTK/samples/credentials/manage-osm-ldap-credentials.sh -p project -i instance -c create -l openldap

Enable "openldap" in project specification.

project.yaml

# When enabled, kubernetes secret "project-instance-openldap-credentials"
# must exist
  openldap: # Deprecated
    enabled: true

The OSM cloud native toolkit provides the following pre-configured shapes:

• charts/osm/shapes/dev.yaml. This can be used for development, QA and user acceptance testing (UAT) instances.
• charts/osm/shapes/devsmall.yaml. This can be used to reduce CPU requirements for small development instances.
• charts/osm/shapes/prod.yaml. This can be used for production, pre-production, and disaster recovery (DR) instances.
• charts/osm/shapes/prodlarge.yaml. This can be used for production, pre-production and disaster recovery (DR) instances that require more memory for OSM cartridges and order caches.
• charts/osm/shapes/prodsmall.yaml. This can be used to reduce CPU requirements for production, pre-production and disaster recovery (DR) instances. For example, it can be used to deploy a small production cluster with two managed servers when the order rate does not justify two managed servers configured with a prod or prodlarge shape. For production instances, Oracle recommends two or more managed servers. This provides increased resiliency to a single point of failure and can allow order processing to continue while failed managed servers are being recovered.
• charts/osm/shapes/prodxsmall.yaml. This shape is similar to prodsmall with the exception that the CPU resources are scaled down to accommodate instances with lower order workloads.

You can create custom shapes using the pre-configured shapes. See "Creating Custom Shapes" for details.

The pre-defined shapes come in standard sizes, which enables you to plan your Kubernetes cluster resource requirement and are available under directory charts/osm/shapes/ inside the toolkit.

The pre-defined shapes will have sizing requirements for the WebLogic pods (admin server and managed server), the microservice pods (OSM Gateway and RTUX) and for init (such as osm-gateway-init) as well as sidecar containers (wme, fluentd).

Based on the values (resource "request" and "limit") defined in the pre-defined shapes (or your custom shape), the Kubernetes scheduler attempts to find space for each pod in the worker nodes of the Kubernetes cluster.

To plan the cluster capacity requirement, consider the following:

• Number of development instances required to be running in parallel: D
• Number of managed servers expected across all the development instances: Md (Md will be equal to D if all the development instances are 1 MS instances)
• Number of OSM gateway microservices across all the development instances: Md (The number of gateway microservices will be always equal to the number of managed servers since we have 1:1 relationship)
• Number of RTUX microservices across all the development instances: D (RTUX microservice is always one per instance)
• Number of Fluentd containers across all the development instances (if enabled): D + Md
• Number of WME containers across all the development instances (unless disabled): D + Md
• Number of production (and production-like) instances required to be running in parallel: P
• Number of managed servers expected across all production instances: Mp
• Number of OSM gateway microservices across all the production instances: Mp
• Number of RTUX microservices across all the production instances: P
• Number of Fluentd containers across all the production instances (if enabled): P + Mp
• Number of WME containers across all the production instances (unless disabled): P + Mp
• Assume use of "dev" and "prod" shapes. The tables shown below are for example only. The real values will always come from the toolkit pre-defined shapes (or your custom shape).
• CPU requirement (CPUs) =D * 1 + Md * 2 + Md * 1 + D * 0.5 + D * 0.5 + Mp * 0.5 + D * 0.5 + Mp * 0.5 + P * 2 + Mp * 15 + Mp * 6 + P *2 + P * 0.5 + Md * 0.5 + P * 0.5 + Md * 0.5 = D * 2.5 + Md * 4 + P * 5 + Mp * 22
• Memory requirement (GB) = D * 4 + Md * 8 + Md * 2 + D * 1 + D * 1 + Md * 1 + D * 1 + Md * 1 + P * 8 + Mp * 48 + Mp * 12 + P * 4 + P * 1 + Mp * 1 + P * 1 + Mp * 1 = D * 7 + Md * 12 + P * 14 + Mp * 62

The shapes are pre-tuned for generic development and production environments. You can create an OSM instance with either of these shapes, by specifying the preferred one in the instance specification.

# Name of the shape. The OSM cloud nativeshapes are devsmall, dev, prodsmall, prod, and prodlarge.
# Alternatively, custom shape name can be specified (as the filename without the extension)

Sometimes, a solution cartridge may require access to a file on disk. A common example is for reading of property files or mapping rules.

A solution may also need to provide configuration files for reference via parameters in the oms-config.xml file for OSM use (for example, for operational order jeopardies and OACC runtime configuration).

When you run create-instance.sh or upgrade-instance.sh, provide the extension_directory in the "-m" command-line argument. In your oms-config.xml file or in your cartridge code, you can refer to these custom files as mountPath/filename, where mountPath comes from your project specification and filename comes from your custom-file-support.yaml contents. For example, if your custom-file-support.yaml file contains a file called properties.txt and you have a mount path of /mycompany/mysolution/config, then you can refer to this file in your cartridge or in the oms-config.xml file as /mycompany/mysolution/config/properties.txt.

To modify the contents of a custom file, update your custom-file-support.yaml file in your extension_directory and invoke upgrade-instance.sh. Changes to the contents of the existing files are immediately visible to the OSM pods. However, you may need to perform additional actions in order for these changes to take effect. For example, if you changed a property value in your custom file, that will only be read the next time your cartridge runs the appropriate logic.

By default, OSM cloud native has its pods scheduled on all worker nodes in the Kubernetes cluster in which it is installed. However, in some situations, you may want to choose a subset of nodes where pods are scheduled.

# If OSM cloud native instances must be targeted to a subset of worker nodes in the
# Kubernetes cluster, tag those nodes with a label name and value, and choose
# that label+value here.
#   key    : any node label key
#   values : list of values to choose the node.
#            If any of the values is found for the above label key, then that
#            node is included in the pod scheduling algorithm.
#
# This can be overridden in instance specification if required.
# osmWLSTargetNodes, if defined, restricts all OSM cloud native WebLogic pods and DB
# Installer pods to worker nodes that match the label conditions and for these
# pods, will take precedence over osmcnTargetNodes.
osmWLSTargetNodes: {} # This empty declaration should be removed if adding items here.
#osmWLSTargetNodes:
#  nodeLabel:
#    example.com/licensed-for-coherence  is just an indicative example; any label and its values can be used for choosing nodes.
#    key: example.com/licensed-for-coherence
#    values:
#      - true
 
# osmcnTargetNodes, if defined, restricts all OSM cloud native pods to worker nodes
# that match the label conditions. This value will be ignored for OSM cloud native
# WebLogic pods and DB Installer pods if osmWLSTargetNodes is also specified.
osmcnTargetNodes: {} # This empty declaration should be removed if adding items here.
#osmcnTargetNodes:
#  nodeLabel:
#    # example.com/use-for-osm is just an indicative example; any label and its values can be used for choosing nodes.
#    key: oracle.com/use-for-osm
#    values:
#      - true

A Kubernetes ingress is responsible for establishing access to back-end services. However, creating an ingress is not sufficient. An Ingress controller allows for the configurable exposure of back-end services to clients outside the Kubernetes cluster, via edge objects like NodePort services, Load Balancers, and so on. In OSM cloud native, an ingress controller can be selected and configured in the project specification.

OSM cloud native supports annotation-based "generic ingress" creation, which means the use of the standard Kubernetes Ingress API (as opposed to a proprietary ingress Custom Resource Definition), as verified by Kubernetes Conformance tests. The benefit of this is that it works for any Kubernetes certified ingress controller, provided that the ingress controller offers annotations (which are generally proprietary to the ingress controller) required for proper functioning of OSM.

Annotations applied to an Ingress resource allow you to use advanced features (like connection timeout, URL rewrite, retry, additional headers, redirects, sticky cookie services, and so on) and to fine-tune behavior for that Ingress resource. Different Ingress controllers support different annotations. For information about different Ingress controllers, see Kubernetes documentation at: https://kubernetes.io/docs/concepts/services-networking/ingress-controllers/ Review this documentation for your Ingress controller to confirm which annotations are supported.

Any Ingress Controller, which conforms to the standard Kubernetes ingress API and supports annotations needed by OSM should work, although Oracle does not certify individual Ingress controllers to confirm this "generic" compatibility.

See the documentation about Ingress NGINX Controller at: https://github.com/kubernetes/ingress-nginx/blob/main/README.md#readme

Also, make sure Ingress has annotation to handle large body size of client request, like large order payloads (during regular processing) or large cartridge par files (while deploying from Design Studio). For example, nginx.ingress.kubernetes.io/proxy-body-size: "50m

The configurations required in your project specification are as follows:

# valid values are TRAEFIK, GENERIC, OTHER
ingressController: "GENERIC"
 
# When ingressController is set to GENERIC, the actual ingress controller might require some annotations to be added to the Kubernetes
# Ingress object.  Place annotations that are must-have for such a controller and/or common to all instances here.  Instance specific
# annotations can be placed in the instance spec file.
ingress:
  # This annotation is required for nginx ingress controller.
  annotations:
     kubernetes.io/ingress.class: nginx
     nginx.ingress.kubernetes.io/proxy-body-size: "50m"
     nginx.ingress.kubernetes.io/affinity: 'cookie'
     nginx.ingress.kubernetes.io/session-cookie-name: 'sticky'
     nginx.ingress.kubernetes.io/affinity-mode: 'persistent'
  osmgw:
  # This annotation is required for nginx ingress controller for osm gateway.
   annotations:
         nginx.ingress.kubernetes.io/use-regex: "true"
         nginx.ingress.kubernetes.io/rewrite-target: /$1
  rtux:
  # This annotation is required for nginx ingress controller for rtux.
   annotations:
         nginx.ingress.kubernetes.io/use-regex: "true"
         nginx.ingress.kubernetes.io/rewrite-target: /orchestration-operations/$1

# SSL Configuration
ssl:
  incoming: true
 
  ingress:
    # These annotations are required if project spec ingressController is "GENERIC" and SSL enabled.
    # Different Ingress controller can have implementation specific annotations and can be added here.
    # Provided annotations below for nginx and openshift.
    # These annotations are required if project spec ingressController is "GENERIC"
    # and the actual ingress controller is nginx with wls custom request headers.
     annotations:
       nginx.ingress.kubernetes.io/configuration-snippet: |
         more_clear_input_headers "WL-Proxy-Client-IP" "WL-Proxy-SSL";
         more_set_input_headers "X-Forwarded-Proto: https";
         more_set_input_headers "WL-Proxy-SSL: true";
       nginx.ingress.kubernetes.io/ingress.allow-http: "false"

The nginx controller works by creating an operator in its own "nginx" (or other specified) namespace, and exposing this as a service outside of the Kubernetes cluster (NodePort, LoadBalancer, and so on). In order to accommodate all types of ingress controllers and exposure options, the instance.yaml file requires inboundGateway.host and inboundGateway.port to be specified.

Populate the values in the instance.yaml before invoking the create-instance.sh command to create an instance:

inboundGateway:
  # FQDN (recommended) or IP address of the actual ingress point/loadbalancer
  host:
  # uncomment and provide if different from default http/https ports
  port:

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

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

Oracle recommends leveraging standard Kubernetes ingress API, with any Ingress Controller that supports annotations for the configurations described here.

# valid values are TRAEFIK, GENERIC, OTHER
ingressController: "TRAEFIK"

By default, OSM cloud native supports standard Kubernetes ingress API and provides sample files for integration. If your desired ingress controller does not support one or more configurations via annotations on generic ingress, or you wish to use your ingress controller's CRD instead, you can choose "OTHER".

By choosing this option, OSM cloud native does not create or manage any ingress required for accessing the OSM cloud native services. However, you may choose to create your own ingress objects based on the service and port details mentioned in the tables that follow. The toolkit uses an ingress Helm chart ($OSM_CNTK/samples/charts/ingress-per-domain/templates/generic-ingress.yaml) and scripts for creating the ingress objects. These samples can be used as a reference to make copies and customize as necessary.

The actual ingress controller might require some annotations to be added to the kubernetes ingress object. The toolkit has provided all those annotations in the sample project and instance spec files in the CNTK. These can be used as a reference to make copies and customize as necessary.

# 
ingress:
  annotations: {} # This empty declaration should be removed if adding items here.
  # This annotation is required for nginx ingress controller.
  #annotations:
  #  kubernetes.io/ingress.class: nginx
  #  nginx.ingress.kubernetes.io/proxy-body-size: "50m"
  #  nginx.ingress.kubernetes.io/affinity: 'cookie'
  #  nginx.ingress.kubernetes.io/session-cookie-name: 'sticky'
  #  nginx.ingress.kubernetes.io/affinity-mode: 'persistent'

For SSL with terminate-at-ingress, refer to NGINX ingress specific annotations provided in $OSM_CNTK/samples/instance.yaml. Similar annotations for other ingress controller should be added. Here weblogic custom request headers "X-Forwarded-Proto: https" and "WL-Proxy-SSL: true" need to be added as annotations.

 ingress:
    # These annotations are required if project spec ingressController is "GENERIC" and SSL enabled.
    # Different Ingress controller can have implementation specific annotations and can be added here.
    # Provided annotations below for nginx and openshift.
    annotations: {} # This empty declaration should be removed if adding items here.
    # These annotations are required if project spec ingressController is "GENERIC"
    # and the actual ingress controller is nginx with wls custom request headers.
    #annotations:
    #  nginx.ingress.kubernetes.io/configuration-snippet: |
    #    more_clear_input_headers "WL-Proxy-Client-IP" "WL-Proxy-SSL";
    #    more_set_input_headers "X-Forwarded-Proto: https";
    #    more_set_input_headers "WL-Proxy-SSL: true";
    #  nginx.ingress.kubernetes.io/ingress.allow-http: "false"

The host-based rules and the corresponding back-end Kubernetes service mapping are provided using the clusterName definition, which is the name of the cluster in lowercase. Replace any hyphens with underscores. The default, unless overridden, is c1.

The following table lists the service name and service ports for Ingress rules. All services require ingress session stickiness to be turned on so that once authenticated, all subsequent requests reach the same endpoint. All these services can be addressed within the Kubernetes cluster using the standard Kubernetes DNS for services.

The path-based rules and the corresponding back-end Kubernetes service mapping are provided using the following definitions. All these services can be addressed within the Kubernetes cluster using the standard Kubernetes DNS for services.

The following table lists the service name and service ports for Ingress rules:

Ingresses need to be created for each of the above rules per the following guidelines:

• Before running create-instance.sh, ingress must be created.
• After running delete-instance.sh, ingress must be deleted.

You can develop your own code to handle your ingress controller or copy the sample ingress-per-domain chart and add additional template files for your ingress controller with a new value for the type.

• The reference sample for creation is: $OSM_CNTK/scripts/config-ingress.sh
• The reference sample for deletion is: $OSM_CNTK/scripts/delete-ingress.sh

To achieve a highly available database service with automatic failover and role interchange you must adopt a role based approach utilizing both primary and standby databases. This configuration ensures that the service always connects to the active database. In the event of a failover or switchover, roles are automatically interchanged and the connection is rerouted to the new active database.

Preconfigure the service at the PDB level using the command below. The default service created during PDB creation cannot be used.

srvctl add service -d database_Uniquename -s servicename -pdb pdb_name -l PRIMARY -e SESSION
      -m BASIC -w 10 -z 10

Example:  srvctl add service -d database_name -s service_name -pdb pdbname -l PRIMARY -e
      SESSION -m BASIC -w failover_delay -z failback_delay

In order to know more, refer to Appendix F Oracle Database Clusterware Administration and Deployment Guide.

When an OSM instance is deleted, the state of the database remains unaffected, which makes it available for re-use. This is common in the following scenarios:

• When an instance is deleted and the same instance is re-created using the same project and the instance names, the database state is unaffected. For example, consider a performance instance that does not need to be up and running all the time, consuming resources. When it is no longer actively being used, its specification files and PDB can be saved and the instance can be deleted. When it is needed again, the instance can be rebuilt using the saved specifications and the saved PDB. Another common scenario is when developers delete and re-create the same instance multiple times while configuration is being developed and tested.
• When a new instance is created to point to the data of another instance with a new project and instance names, the database state is unaffected. A developer, who might want to create a development instance with the data from a test instance in order to investigate a reported issue, is likely to use their own instance specification and the OSM data from PDB of the test instance.

OSM cloud native can be configured to use a Kubernetes Persistent Volume to store data that needs to be retained even after a pod is terminated. This data includes application logs, JFR recordings and DB Installer logs, but does not include any sort of OSM state data. When an instance is re-created, the same persistent volume need not be available. When persistent storage is enabled in the instance specification, these data files, which are written inside a pod are re-directed to the persistent volume.

Data from all instances in a project may be persisted, but each instance does not need a unique location for logging. Data is written to a project-instance folder, so multiple instances can share the same end location without destroying data from other instances.

The final location for this data should be one that is directly visible to the users of OSM cloud native. The development instances may simply direct data to a shared file system for analysis and debugging by cartridge developers. Whereas, formal test and production instances may need the data to be scraped by a logging toolchain such as EFK, that can then process the data and make it available in various forms. The recommendation therefore is to create a PV-PVC pair for each class of destination within a project. In this example, one for developers to access and one that feeds into a toolchain.

A PV-PVC pair would be created for each of these "destinations", that multiple instances can then share. A single PVC can be used by multiple OSM domains. The management of the PV and PVC lifecycles is beyond the scope of OSM cloud native.

The OSM cloud native infrastructure administrator is responsible for creating and deleting PVs or for setting up dynamic volume provisioning.

The OSM cloud native project administrator is responsible for creating and deleting PVCs as per the standard documentation in a manner such that they consume the pre-created PVs or trigger the dynamic volume provisioning. The specific technology supporting the PV is also beyond the scope of OSM cloud native. However, samples for PV supported by NFS are provided.

Creating a PV-PVC Pair

The technology supporting the Kubernetes PV-PVC is not dictated by OSM cloud native. Samples have been provided for NFS and can either be used as is, or as a reference for other implementations.

To create a PV-PVC pair supported by NFS:

1. Edit the sample PV and PVC yaml files and update entries with enclosing brackets

   Note:

   PVCs need to be ReadWriteMany.

   vi $OSM_CNTK/samples/nfs/pv.yaml
     vi $OSM_CNTK/samples/nfs/pvc.yaml

2. Create the Kubernetes PV and PVC.

   kubectl create -f $OSM_CNTK/samples/nfs/pv.yaml
   kubectl create -f $OSM_CNTK/samples/nfs/pvc.yaml

# The storage volume must specify the PVC to be used for persistent storage.
storageVolume:
  enabled: true
  pvc: storage-pvc

[oracle@localhost project-instance]$ dir
db-installer  logs  performance

As part of the setup of a highly performant database for OSM, it is necessary to set up database optimizer statistics. OSM DB Installer can be used to set up the database partition statistics, which ensures a consistent source of statistics for new partitions so that the database generates optimal execution plans for queries in those partitions.

About the Default Partition Statistics

The OSM DB Installer comes with a set of default partition statistics. These statistics come from an OSM system running a large number of orders (over 400,000) for a cartridge of reasonable complexity. These partition statistics are usable as-is for production.

Setting Up Database Partition Statistics

To use the provided default partition statistics, no additional input, in terms of specification files, secrets or other runtime aspects, is required for the OSM cloud native DB Installer.

The OSM cloud native DB Installer is invoked during the OSM instance creation, to either create or update the OSM schema. The installer is configured to automatically populate the default partition statistics (to all partitions) for a newly created OSM schema when the "prod", "prodsmall", or "prodlarge" (Production) shape is declared in the instance specification. The statistics.loadPartitionStatistics field within these shape files is set to true to enable the loading.

If you want to load partition statistics for a non-production shape, or if you want to reload statistics due to a DB or schema upgrade, use the command with 11 to load the statistics to all existing partitions in the OSM schema:

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

$OSM_CNTK/scripts/install-osmdb.sh -p project -i instance -s $SPEC_PATH -b the_newly_created_partition_1,the_newly_created_partition_2 -c 11

$OSM_CNTK/scripts/install-osmdb.sh -p project -i instance -s $SPEC_PATH -a existing_partition_name -b the_newly_created_partition_1,the_newly_created_partition_2 -c 11

If you are using a RAC database for your OSM cloud native instance, by default, OSM uses WebLogic Multi-DataSource (MDS) configurations to connect to the database.

If you are licensed to use Oracle WebLogic Server Active GridLink (AGL) separately from your OSM license (consult any additional WebLogic licenses you possess that may apply), you can configure OSM cloud native to use AGL configurations where possible. This will better distribute load across RAC nodes.

db: 
  aglLicensed: true

OSM cloud native generates traditional textual logs. By default, these log files are generated in the managed server pod, but can be re-directed to a Persistent Volume Claim (PVC) supported by the underlying technology that you choose. See "Setting Up Persistent Storage" for details.

# The storage volume must specify the PVC to be used for persistent storage. If enabled, the log, metric and JFR data will be directed here.
storageVolume:
  enabled: true
  pvc: storage-pvc

• The OSM application logs can be found at: pv-directory/project-instance/logs
• The OSM DB Installer logs can be found at: pv_directory/project-instance/db-installer
• The OSM Gateway logs can be found at: pv_directory/project-instance/osm-gateway
• The OSM Runtime UX logs can be found at: pv_directory/project-instance/osm-runtime-ux-server

All managed server pods running OSM cloud native carry annotations added by WebLogic Operator and an additional annotation by OSM cloud native.

osmcn.metricspath: /OrderManagement/metrics
osmcn.metricsport: 8001
prometheus.io/scrape: true

By default, the OSM Gateway pod and the RTUX pod expose metrics to Prometheus (or any other compliant tool) scrape. This is controlled by the instance specification as follows:

#  # Prometheus monitoring is enabled by default.
#  prometheus:
#    enabled: true

To disable this behavior, set prometheus.enabled to false.

OSM cloud native deployment provides an integrated Prometheus-compatible exporter of metrics from all WebLogic Server pods using WebLogic Monitoring Exporter (WME). WME runs as a sidecar container within each of the WebLogic Server pods (admin server and managed servers). This section describes a sample integration for OSM pods that run WebLogic Server.