idm_23.4.2_release (#183)

Author: manjunathdhegde-2910

docs-source/content/idm-products/oam/create-oam-domains/_index.md

@@ -7,7 +7,6 @@ description=  "Create or update an Oracle Access Management (OAM) container imag
 
 As described in [Prepare Your Environment](../prepare-your-environment) you can create your own OAM container image. If you have access to the My Oracle Support (MOS), and there is a need to build a new image with an interim or one off patch, it is recommended to use the WebLogic Image Tool to build an Oracle Access Management image for production deployments.
 
-
 ### Create or update an Oracle Access Management image using the WebLogic Image Tool
 
 Using the WebLogic Image Tool, you can [create](../create-or-update-image/#create-an-image) a new Oracle Access Management image with PSU's and interim patches or [update](../create-or-update-image/#update-an-image) an existing image with one or more interim patches.

docs-source/content/idm-products/oam/create-oam-domains/create-oam-domains-using-wdt-models.md

@@ -8,7 +8,11 @@ description: "The WebLogic Kubernetes Operator supports deployment of Oracle Acc
 The WebLogic Kubernetes Operator supports deployment of Oracle Access Management (OAM).
 
 In this release, OAM domains are supported using the “domain on a persistent volume”
-[model](https://oracle.github.io/weblogic-kubernetes-operator/userguide/managing-domains/choosing-a-model/) only, where the domain home is located in a persistent volume (PV).
+[model](https://oracle.github.io/weblogic-kubernetes-operator/managing-domains/choosing-a-model/) only, where the domain home is located in a persistent volume (PV).
+
+Domain on persistent volume (Domain on PV) is an operator [domain home source type](https://oracle.github.io/weblogic-kubernetes-operator/managing-domains/choosing-a-model/), which requires that the domain home exists on a persistent volume. The domain home can be created either using the Weblogic Scripting Tool (WLST) scripts or Weblogic Deploy Tooling (WDT) model files by specifying the section domain.spec.configuration.initializeDomainOnPV, in the domain resource YAML file. The initial domain topology and resources are described using [WebLogic Deploy Tooling (WDT) models](https://oracle.github.io/weblogic-kubernetes-operator/managing-domains/domain-on-pv/overview/#weblogic-deploy-tooling-models).
+
+NOTE: The initializeDomainOnPV section provides a one time only domain home initialization. The operator creates the domain when the domain resource is first deployed. After the domain is created, this section is ignored. Subsequent domain lifecycle updates must be controlled by the WebLogic Server Administration Console, the WebLogic Remote Console, WebLogic Scripting Tool (WLST), or other mechanisms.
 
 The WebLogic Kubernetes Operator has several key features to assist you with deploying and managing Oracle Access Management domains in a Kubernetes
 environment. You can:
@@ -21,9 +25,19 @@ environment. You can:
 * Publish operator and WebLogic Server logs into Elasticsearch and interact with them in Kibana.
 * Monitor the OAM instance using Prometheus and Grafana.
 
+### Weblogic Deploy Tooling Models
+
+Weblogic Deploy Tooling (WDT) models are a convenient and simple alternative to WLST configuration scripts. They compactly define a WebLogic domain using model files, variable properties files, and application archive files. For more information about the model format and its integration, see [Usage](https://oracle.github.io/weblogic-kubernetes-operator/managing-domains/domain-on-pv/usage/) and [Working With WDT Model Files](https://oracle.github.io/weblogic-kubernetes-operator/managing-domains/domain-on-pv/model-files/). The WDT model format is fully described in the open source, [WebLogic Deploy Tooling GitHub project](https://oracle.github.io/weblogic-deploy-tooling/).
+
+The main benefits of WDT are:
+
+   + A set of single-purpose tools supporting Weblogic domain configuration lifecycle operations.
+   + All tools work off of a shared, declarative model, eliminating the need to maintain specialized WLST scripts.
+   + WDT knowledge base understands the MBeans, attributes, and WLST capabilities/bugs across WLS versions.
+
 ### Current production release
 
-The current production release for the Oracle Access Management domain deployment on Kubernetes is [23.4.1](https://github.com/oracle/fmw-kubernetes/releases). This release uses the WebLogic Kubernetes Operator version 4.1.2.
+The current production release for the Oracle Access Management domain deployment on Kubernetes is [23.4.2](https://github.com/oracle/fmw-kubernetes/releases). This release uses the WebLogic Kubernetes Operator version 4.1.2.
 
 For 4.0.X WebLogic Kubernetes Operator refer to [Version 23.3.1](https://oracle.github.io/fmw-kubernetes/23.3.1/idm-products/oam/)
 
@@ -55,6 +69,7 @@ Please note, you also have the option to follow the Enterprise Deployment Guide
 
 To view documentation for an earlier release, see:
 
+* [Version 23.4.1](https://oracle.github.io/fmw-kubernetes/23.3.1/idm-products/oam/)
 * [Version 23.3.1](https://oracle.github.io/fmw-kubernetes/23.3.1/idm-products/oam/)
 * [Version 23.2.1](https://oracle.github.io/fmw-kubernetes/23.2.1/idm-products/oam/)
 * [Version 23.1.1](https://oracle.github.io/fmw-kubernetes/23.1.1/idm-products/oam/)

docs-source/content/idm-products/oam/create-oam-domains/create-oam-domains-using-wlst.md

@@ -122,12 +122,42 @@ You will also need the BASE64 version of the Certificate Authority (CA) certific
    $ kubectl describe domains accessdomain -n oamns | grep "Mount Path"
    ```
 
-   The output will look similar to the following:
+   If you deployed OAM using WLST, the output will look similar to the following:
 
    ```
    Mount Path:  /u01/oracle/user_projects/domains
    ```
 
+   If you deployed OAM using WDT, the output will look similar to the following:
+   
+   ```
+   Mount Path:  /u01/oracle/user_projects
+   ```
+
+#### Find the Domain Home and Log Home details
+
+1. Run the following command to get the `Domain Home` and `Log Home` of your domain:
+
+   ```bash
+	$ kubectl describe domains <domain_uid> -n <domain_namespace> | egrep "Domain Home: | Log Home:"
+	```
+	
+	For example:
+	
+	```bash
+	$ kubectl describe domains accessdomain -n oamns  | egrep "Domain Home: | Log Home:"
+	```
+	
+	The output will look similar to the following:
+	
+	```
+	Domain Home:                     /u01/oracle/user_projects/domains/accessdomain
+   Http Access Log In Log Home:     true
+   Log Home:                           /u01/oracle/user_projects/domains/logs/accessdomain
+   ```
+	
+	
+   
 #### Find the persistentVolumeClaim details
 
 1. Run the following command to get the OAM domain persistence volume details:
@@ -189,32 +219,32 @@ You will also need the BASE64 version of the Certificate Authority (CA) certific
      logstash-config.conf: |
        input {
         file {
-           path => "/u01/oracle/user_projects/domains/logs/accessdomain/AdminServer*.log"
+           path => "<Log Home>/**/logs/AdminServer*.log"
            tags => "Adminserver_log"
            start_position => beginning
          }
          file {
-           path => "/u01/oracle/user_projects/domains/logs/accessdomain/oam_policy_mgr*.log"
+           path => "<Log Home>/**/logs/oam_policy_mgr*.log"
            tags => "Policymanager_log"
            start_position => beginning
          }
          file {
-           path => "/u01/oracle/user_projects/domains/logs/accessdomain/oam_server*.log"
+           path => "<Log Home>/**/logs/oam_server*.log"
            tags => "Oamserver_log"
            start_position => beginning
          }
          file {
-           path => "/u01/oracle/user_projects/domains/accessdomain/servers/AdminServer/logs/AdminServer-diagnostic.log"
+           path => <Domain Home>/servers/AdminServer/logs/AdminServer-diagnostic.log"
            tags => "Adminserver_diagnostic"
            start_position => beginning
          }
          file {
-           path => "/u01/oracle/user_projects/domains/accessdomain/servers/**/logs/oam_policy_mgr*-diagnostic.log"
+           path => "<Domain Home>/servers/**/logs/oam_policy_mgr*-diagnostic.log"
            tags => "Policy_diagnostic"
            start_position => beginning
          }
          file {
-         path => "/u01/oracle/user_projects/domains/accessdomain/servers/AdminServer/logs/auditlogs/OAM/audit.log"
+         path => <Domain Home>/servers/AdminServer/logs/auditlogs/OAM/audit.log"
          tags => "Audit_logs"
          start_position => beginning
          }
@@ -246,7 +276,7 @@ You will also need the BASE64 version of the Certificate Authority (CA) certific
    Change the values in the above file as follows:
 
    + Change the `<ELKNS>`, `<ELK_HOSTS>`, `<ELK_SSL>`, and `<ELK_USER>` to match the values for your environment.
-   + Change `/u01/oracle/user_projects/domains` to match the `mountPath` returned earlier
+	+ Change `<Log Home>` and `<Domain Home>` to match the Log Home and Domain Home returned earlier.
    + If your domainUID is anything other than `accessdomain`, change each instance of `accessdomain` to your domainUID.
    + If using API KEY for your ELK authentication, delete the `user` and `password` lines.
    + If using a password for ELK authentication, delete the `api_key` line.
@@ -259,29 +289,29 @@ You will also need the BASE64 version of the Certificate Authority (CA) certific
    kind: ConfigMap
    metadata:
      name: oam-logstash-configmap
-     namespace: oamns
+     namespace: <ELKNS>
    data:
      logstash.yml: |
      #http.host: "0.0.0.0"
      logstash-config.conf: |
        input {
         file {
-           path => "/u01/oracle/user_projects/domains/logs/accessdomain/AdminServer*.log"
+           path => "/u01/oracle/user_projects/domains/logs/accessdomain/**/logs/AdminServer*.log"
            tags => "Adminserver_log"
            start_position => beginning
          }
          file {
-           path => "/u01/oracle/user_projects/domains/logs/accessdomain/oam_policy_mgr*.log"
+           path => "/u01/oracle/user_projects/domains/logs/accessdomain/**/logs/oam_policy_mgr*.log"
            tags => "Policymanager_log"
            start_position => beginning
          }
          file {
-           path => "/u01/oracle/user_projects/domains/logs/accessdomain/oam_server*.log"
+           path => "/u01/oracle/user_projects/domains/logs/accessdomain/**/logs/oam_server*.log"
            tags => "Oamserver_log"
            start_position => beginning
          }
          file {
-           path => "/u01/oracle/user_projects/domains/accessdomain/servers/AdminServer/logs/AdminServer-diagnostic.log"
+           path => /u01/oracle/user_projects/domains/accessdomain/servers/AdminServer/logs/AdminServer-diagnostic.log"
            tags => "Adminserver_diagnostic"
            start_position => beginning
          }
@@ -371,7 +401,7 @@ You will also need the BASE64 version of the Certificate Authority (CA) certific
            - containerPort: 5044
              name: logstash
            volumeMounts:
-           - mountPath: /u01/oracle/user_projects
+           - mountPath: <mountPath>
              name: weblogic-domain-storage-volume
            - name: shared-logs
              mountPath: /shared-logs
@@ -411,8 +441,8 @@ You will also need the BASE64 version of the Certificate Authority (CA) certific
            emptyDir: {}
    ```
 
-   + Change the `<ELKNS>`, `<ELK_VER>` to match the values for your environment.
-   + Change `/u01/oracle/user_projects/domains` to match the `mountPath` returned earlier
+   + Change the `<ELKNS>`, `<ELK_VER>` to match the values for your environment
+   + Change `<mountPath>` to match the `mountPath` returned earlier
    + Change the `claimName` value to match the `claimName` returned earlier
    + If your Kubernetes environment does not allow access to the internet to pull the logstash image, you must load the logstash image in your own container registry and change `image: logstash:<ELK_VER>` to the location of the image in your container registry e.g: `container-registry.example.com/logstash:8.3.1`
 

docs-source/content/idm-products/oam/create-or-update-image/_index.md

@@ -82,6 +82,9 @@ For usage details execute `./setup-monitoring.sh -h`.
    # Name of the Kubernetes secret for the Admin Server's username and password
    weblogicCredentialsSecretName: accessdomain-credentials
    ```
+	
+	**Note**: For WDT domains, `weblogicCredentialsSecretName` should be set to `accessdomain-weblogic-credentials`.
+	
    **Note**: If your cluster does not have access to the internet to pull external images, such as grafana or prometheus, you must load the images in a local container registry. You must then set  `additionalParamForKubePrometheusStack` to set the location of the image in your local container registry, for example:
 
    ```

docs-source/content/idm-products/oam/introduction/_index.md

@@ -18,10 +18,18 @@ Follow these post install configuration steps.
 
 1. Navigate to the following directory:
 
+   For OAM domains created with WLST:
+   
    ```bash
    $ cd $WORKDIR/kubernetes/create-access-domain/domain-home-on-pv/output/weblogic-domains/accessdomain
    ```
 
+   For OAM domains created with WDT:
+   
+   ```bash
+   $ cd $WORKDIR/kubernetes/create-access-domain/domain-home-on-pv/
+   ```
+   
 1. Create a `setUserOverrides.sh` with the following contents:
 
    ```

docs-source/content/idm-products/oam/manage-oam-domains/logging-and-visualization.md

@@ -609,7 +609,9 @@ Before following the steps in this section, make sure that the database and list
 
 ### Preparing the environment for domain creation
 
-In this section you prepare the environment for the OAM domain creation. This involves the following steps:
+**Note**: If you want to create an OAM domain using WDT models, skip the steps below and continue from [Create OAM Domains Using WDT Models](../create-oam-domains/create-oam-domains-using-wdt-models).
+
+In this section you prepare the environment for the OAM domain creation using WLST scripts. This involves the following steps:
 
    a. [Creating Kubernetes secrets for the domain and RCU](#creating-kubernetes-secrets-for-the-domain-and-rcu)
 

docs-source/content/idm-products/oam/manage-oam-domains/monitoring-oam-domains.md

@@ -10,6 +10,19 @@ Review the latest changes and known issues for Oracle Access Management on Kuber
 
 | Date | Version | Change |
 | --- | --- | --- |
+| November, 2023 | 23.4.2 | Supports Oracle Access Management 12.2.1.4 domain deployment using the October 2023 container image which contains the October Patch Set Update (PSU) and other fixes released with the Critical Patch Update (CPU) program.|
+| | | This release contains the following changes:
+| | | Support for creation of OAM domains using Weblogic Deploy Tooling (WDT) Models. See [Create OAM domains Using WDT Models](../create-oam-domains/create-oam-domains-using-wdt-models).|
+| | | If currently on October 23 (23.4.1) there is no need to upgrade as the November 23 (23.4.2) release only adds the ability to create new OAM domains using WDT.
+| | | If upgrading to November 23 (23.4.2) from October 22 (22.4.1) or later, you must upgrade the following in order:
+| | | 1. WebLogic Kubernetes Operator to 4.1.2|
+| | | 2. Patch the OAM container image to October 23|
+| | | If upgrading to November 23 (23.4.2) from a release prior to October 22 (22.4.1), you must upgrade the following in order:
+| | | 1. WebLogic Kubernetes Operator to 4.1.2|
+| | | 2. Patch the OAM container image to October 23|
+| | | 3. Upgrade the Ingress|
+| | | 4. Upgrade Elasticsearch and Kibana|
+| | | See [Patch and Upgrade](../patch-and-upgrade) for these instructions.| 
 | October, 2023 | 23.4.1 | Supports Oracle Access Management 12.2.1.4 domain deployment using the October 2023 container image which contains the October Patch Set Update (PSU) and other fixes released with the Critical Patch Update (CPU) program.|
 | | | This release contains the following changes:
 | | | + Support for WebLogic Kubernetes Operator 4.1.2.|