Merge branch 'main' into 'apply-eds-comment'

# Conflicts:
#   documentation/4.0/content/samples/azure-kubernetes-service/includes/prerequisites-01.txt
#   documentation/4.0/content/samples/azure-kubernetes-service/includes/prerequisites-02.txt

Author: rjeberhard

documentation/4.0/content/samples/azure-kubernetes-service/includes/prerequisites-01.txt

@@ -4,7 +4,7 @@ This sample assumes the following prerequisite environment.
 
 * If you don't have an [Azure subscription](https://learn.microsoft.com/en-us/azure/guides/developer/azure-developer-guide#understanding-accounts-subscriptions-and-billing), create a [free account](https://azure.microsoft.com/free/?ref=microsoft.com&utm_source=microsoft.com&utm_medium=docs&utm_campaign=visualstudio) before you begin.
   * It's recommended that the Azure identity you use to sign in and complete this article has either the [Owner](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles#owner) role in the current subscription or the [Contributor](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles#contributor) and [User Access Administrator](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles#user-access-administrator) roles in the current subscription. 
-  * Failing that, if your identity has very limited role assignments, ensure you have the following role assignments in the AKS resource group and AKS node resource group.
+  * If your identity has very limited role assignments, ensure you have the following role assignments in the AKS resource group and AKS node resource group.
     * [Contributor](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles#contributor) role and [User Access Administrator](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles#user-access-administrator) role in the resource group that runs AKS cluster. This requires asking a privileged user to assign the roles before creating resource in the resource group.
     * [Contributor](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles#contributor) role in the AKS node resource group whose name starts with "MC_". This requires asking a privileged user to assign the role after the AKS instance is created.
 * Operating System: GNU/Linux, macOS or [WSL2 for Windows 10](https://docs.microsoft.com/windows/wsl/install-win10).

documentation/4.0/content/samples/azure-kubernetes-service/includes/prerequisites-02.txt

@@ -4,7 +4,7 @@ This sample assumes the following prerequisite environment.
 
 * If you don't have an [Azure subscription](https://learn.microsoft.com/en-us/azure/guides/developer/azure-developer-guide#understanding-accounts-subscriptions-and-billing), create a [free account](https://azure.microsoft.com/free/?ref=microsoft.com&utm_source=microsoft.com&utm_medium=docs&utm_campaign=visualstudio) before you begin.
   * It's recommended that the Azure identity you use to sign in and complete this article has either the [Owner](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles#owner) role in the current subscription or the [Contributor](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles#contributor) and [User Access Administrator](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles#user-access-administrator) roles in the current subscription. 
-  * Failing that, if your identity has very limited role assignments, ensure you have [Contributor](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles#contributor) role and [User Access Administrator](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles#user-access-administrator) role in the resource group that runs the AKS cluster. This requires asking a privileged user to assign the roles before creating resources in the resource group.
+  * If your identity has very limited role assignments, ensure you have [Contributor](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles#contributor) role and [User Access Administrator](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles#user-access-administrator) role in the resource group that runs the AKS cluster. This requires asking a privileged user to assign the roles before creating resources in the resource group.
 * Operating System: GNU/Linux, macOS or [WSL2 for Windows 10](https://docs.microsoft.com/windows/wsl/install-win10).
 * [Git](https://git-scm.com/downloads); use `git --version` to test if `git` works.  This document was tested with version 2.25.1.
 * [Azure CLI](https://docs.microsoft.com/cli/azure); use `az --version` to test if `az` works.  This document was tested with version 2.48.1.

documentation/4.1/.vscode/settings.json

@@ -0,0 +1,3 @@
+{
+    "git.ignoreLimitWarning": true
+}

documentation/4.1/README.md

@@ -0,0 +1,7 @@
+# WebLogic Kubernetes Operator Documentation
+
+***
+For information on updating and contributing to the operator
+documentation, see the _Documentation_ section of the
+[Developer Guide](https://oracle.github.io/weblogic-kubernetes-operator/developerguide/documentation)
+***

documentation/4.1/archetypes/default.md

@@ -0,0 +1,6 @@
+---
+title: "{{ replace .Name "-" " " | title }}"
+date: {{ .Date }}
+draft: false
+---
+

documentation/4.1/config.toml

@@ -0,0 +1,27 @@
+# analytics
+googleAnalytics = "UA-129126578-2"
+
+baseURL = "/weblogic-kubernetes-operator/"
+languageCode = "en-us"
+title = "WebLogic Kubernetes Operator"
+
+# Change the default theme to be use when building the site with Hugo
+theme = "hugo-theme-learn"
+
+publishDir = "docs"
+
+canonifyURLs = true
+
+# For search functionality
+[outputs]
+  home = [ "HTML", "RSS", "JSON"]
+
+[params]
+  # disable the copy to clipboard links
+  disableInlineCopyToClipBoard = true
+
+[markup]
+  [markup.tableOfContents]
+    endLevel = 5
+    ordered = false
+    startLevel = 3

documentation/4.1/content/_index.md

@@ -0,0 +1,66 @@
+### WebLogic Kubernetes Operator
+
+The WebLogic Kubernetes Operator (the “operator”) supports running your WebLogic Server and Fusion Middleware Infrastructure domains on Kubernetes, an industry standard, cloud neutral deployment platform. It lets you encapsulate your entire WebLogic Server installation and layered applications into a portable set of cloud neutral images and simple resource description files. You can run them on any on-premises or public cloud that supports Kubernetes where you've deployed the operator.
+
+Furthermore, the operator is well suited to CI/CD processes. You can easily inject changes when moving between environments, such as from test to production. For example, you can externally inject database URLs and credentials during deployment or you can inject arbitrary changes to most WebLogic configurations.
+
+The operator takes advantage of the [Kubernetes operator pattern](https://kubernetes.io/docs/concepts/extend-kubernetes/operator/), which means that it uses Kubernetes APIs to provide support for operations, such as: provisioning, lifecycle management, application versioning, product patching, scaling, and security. The operator also enables the use of tooling that is native to this infrastructure for monitoring, logging, tracing, and security.
+
+You can:
+* Deploy an operator that manages all WebLogic domains in all namespaces in a Kubernetes cluster, or that only manages domains in a specific subset of the namespaces, or that manages only domains that are located in the same namespace as the operator. At most, a namespace can be managed by one operator.
+* Supply WebLogic domain configuration using:
+  * _Model in Image_: Includes [WebLogic Deploy Tooling](https://github.com/oracle/weblogic-deploy-tooling) models and archives in a container image.
+  * _Domain in Image_: Includes a WebLogic domain home in a container image.
+     * **NOTE**: The Domain in Image [domain home source type]({{< relref "/managing-domains/choosing-a-model/_index.md" >}}) is deprecated in WebLogic Kubernetes Operator version 4.0. Oracle recommends that you choose either Domain in PV or Model in Image, depending on your needs.
+  * _Domain in PV_: Locates WebLogic domain homes in a Kubernetes PersistentVolume (PV). This PV can reside in an NFS file system or other Kubernetes volume types.
+* Configure deployment of WebLogic domains as Kubernetes resources (using Kubernetes custom resource definitions).
+* Override certain aspects of the WebLogic domain configuration; for example, use a different database password for different deployments.
+* Start and stop servers and clusters in the domain based on declarative startup parameters and desired states.
+* Scale WebLogic domains by starting and stopping Managed Servers on demand, Kubernetes scale commands, setting up a Kubernetes Horizontal Pod Autoscaler, or by integrating with a REST API to initiate scaling based on the WebLogic Diagnostics Framework (WLDF), Prometheus, Grafana, or other rules.
+* Expose HTTP paths on a WebLogic domain outside the Kubernetes domain with load balancing, and automatically update the load balancer when Managed Servers in the WebLogic domain are started or stopped.
+* Expose the WebLogic Server Administration Console outside the Kubernetes cluster, if desired.
+* Expose T3 channels outside the Kubernetes domain, if desired.
+* Publish operator and WebLogic Server logs into Elasticsearch and interact with them in Kibana.
+
+{{% notice tip %}}
+The fastest way to experience the operator is to follow the [Quick Start guide]({{< relref "/quickstart/_index.md" >}}), or you can peruse our [documentation]({{< relref "/introduction/_index.md" >}}), read our [blogs](https://blogs.oracle.com/weblogicserver/how-to-weblogic-server-on-kubernetes), or try out the [samples]({{< relref "/samples/_index.md" >}}).
+Also, you can step through the [Tutorial](https://github.com/oracle/weblogic-kubernetes-operator/blob/{{< latestMinorVersion >}}/kubernetes/hands-on-lab/README.md)
+using the operator to deploy and run a WebLogic domain container-packaged web application on an Oracle Container Engine for Kubernetes (OKE) cluster.
+{{% /notice %}}
+
+***
+#### Current production release
+
+The [current release of the operator](https://github.com/oracle/weblogic-kubernetes-operator/releases) is {{< latestVersion >}}.
+This release was published on April 8, 2023. See the [operator prerequisites]({{< relref "/introduction/prerequisites/introduction.md" >}}) and [supported environments]({{< relref "/introduction/platforms/environments.md" >}}).
+
+***
+
+#### Recent changes and known issues
+
+See the [Release Notes]({{< relref "release-notes.md" >}})  for recent changes to the operator and known issues.
+
+#### Operator earlier versions
+
+Documentation for prior releases of the operator: [2.5.0](https://oracle.github.io/weblogic-kubernetes-operator/2.5/), [2.6.0](https://oracle.github.io/weblogic-kubernetes-operator/2.6/), [3.0.x](https://oracle.github.io/weblogic-kubernetes-operator/3.0/), [3.1.x](https://oracle.github.io/weblogic-kubernetes-operator/3.1/), [3.2.x](https://oracle.github.io/weblogic-kubernetes-operator/3.2/), [3.3.x](https://oracle.github.io/weblogic-kubernetes-operator/3.3/), and [3.4.x](https://oracle.github.io/weblogic-kubernetes-operator/3.4/).
+
+#### Backward compatibility guidelines
+
+Starting from the 2.0.1 release, operator releases are backward compatible with respect to the domain
+resource schema, operator Helm chart input values, configuration overrides template, Kubernetes resources created
+by the operator Helm chart, Kubernetes resources created by the operator, and the operator REST interface. We intend to
+maintain compatibility for three releases, except in the case of a clearly communicated deprecated feature, which will be
+maintained for one release after a replacement is available.
+
+#### Getting help
+
+See [Get help]({{< relref "/introduction/get-help.md" >}}).
+
+#### Related projects
+
+* [Oracle Fusion Middleware on Kubernetes](https://oracle.github.io/fmw-kubernetes/)
+* [WebLogic Deploy Tooling](https://oracle.github.io/weblogic-deploy-tooling/)
+* [WebLogic Image Tool](https://oracle.github.io/weblogic-image-tool/)
+* [WebLogic Monitoring Exporter](https://github.com/oracle/weblogic-monitoring-exporter)
+* [WebLogic Remote Console](https://oracle.github.io/weblogic-remote-console/)
+* [WebLogic Kubernetes Toolkit UI](https://oracle.github.io/weblogic-toolkit-ui/)

documentation/4.1/content/base-images/_index.md

@@ -0,0 +1,12 @@
+---
+title: "WebLogic images"
+date: 2019-02-23T16:45:55-05:00
+weight: 5
+pre: "<b> </b>"
+description: "Obtain, create, and dynamically patch images for WebLogic Server or Fusion Middleware Infrastructure deployments."
+---
+The following sections guide you through obtaining, creating, and dynamically updating WebLogic images.
+
+{{% children style="h4" description="true" %}}
+
+#### [Use or create WebLogic images depending on domain home source type]({{< relref "/managing-domains/choosing-a-model#use-or-create-weblogic-images-depending-on-domain-home-source-type" >}})

documentation/4.1/content/base-images/access-images.md

@@ -0,0 +1,92 @@
+---
+title: "Access domain images"
+date: 2019-02-23T16:45:55-05:00
+weight: 4
+description: "Set up Kubernetes to access domain images."
+---
+
+In most operator samples, it is assumed that the Kubernetes cluster has a single worker node
+and any images that are needed by that node have either been created on that node or
+externally pulled to the node from a registry (using `docker pull`).
+This is fine for most demonstration purposes,
+and if this assumption is correct, then no additional steps
+are needed to ensure that Kubernetes has access to the image.
+_Otherwise, additional steps are typically required to ensure that a Kubernetes cluster has access to domain images._
+
+For example, it is typical in production deployments
+for the Kubernetes cluster to be remote and have multiple worker nodes,
+and to store domain images in a central repository that requires authentication.
+
+Here are two typical scenarios for supplying domain images to such deployments:
+
+- [Option 1](#option-1-store-images-in-a-central-registry-and-set-up-image-pull-secrets-on-each-domain-resource): Store images in a central registry and set up image pull secrets on each domain resource
+
+- [Option 2](#option-2-store-images-in-a-central-registry-and-set-up-a-kubernetes-service-account-with-image-pull-secrets-in-each-domain-namespace): Store images in a central registry and set up a Kubernetes service account with image pull secrets in each domain namespace
+
+#### Option 1: Store images in a central registry and set up image pull secrets on each domain resource
+
+The most commonly used option is to store the image in a central registry
+and set up image pull secrets for a domain resource:
+
+- A Kubernetes `docker-registry` secret containing the registry credentials must be created
+  in the same namespace as domain resources with a `domain.spec.image` attribute that reference the image.
+  For example, to create a secret with OCR credentials:
+
+  ```shell
+  $ kubectl create secret docker-registry SECRET_NAME \
+    -n NAMESPACE_WHERE_YOU_DEPLOY_DOMAINS \
+    --docker-server=container-registry.oracle.com \
+    --docker-username=YOUR_USERNAME \
+    --docker-password=YOUR_PASSWORD \
+    --docker-email=YOUR_EMAIL
+  ```
+
+- The name of the secret must be added to these domain resources using
+  the `domain.spec.imagePullSecrets` field. For example:
+
+  ```text
+  ...
+  spec:
+  ...
+    imagePullSecrets:
+    - name: SECRET_NAME
+  ...
+  ```
+
+- If you are using the Oracle Container Registry, then
+  you must use the web interface to accept the Oracle Standard Terms and Restrictions
+  for the Oracle software images that you intend to deploy.
+  You need to do this only once for a particular image.
+  See [Obtain images from the Oracle Container Registry]({{< relref "/base-images/ocr-images#obtain-images-from-the-oracle-container-registry" >}}).
+
+For more information about creating Kubernetes Secrets for accessing
+the registry, see the Kubernetes documentation,
+[Pull an image from a private registry](https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/).
+
+#### Option 2: Store images in a central registry and set up a Kubernetes service account with image pull secrets in each domain namespace
+
+An option for accessing an image that is stored in a private registry
+is to set up the Kubernetes `ServiceAccount` in the namespace running the
+WebLogic domain with a set of image pull secrets thus avoiding the need to
+set `imagePullSecrets` for each `Domain` resource being created (because each resource
+instance represents a WebLogic domain that the operator is managing):
+
+- Create a Kubernetes `docker-registry` secret as shown
+  in [Option 1](#option-1-store-images-in-a-central-registry-and-set-up-image-pull-secrets-on-each-domain-resource).
+
+- Modify the `ServiceAccount` that is in the same namespace
+  as your domain resources to include this image pull secret:
+
+  ```shell
+  $ kubectl patch serviceaccount default -n domain1-ns \
+  -p '{"imagePullSecrets": [{"name": "my-registry-pull-secret"}]}'
+  ```
+
+  Note that this patch command entirely replaces the current list of
+  image pull secrets (if any). To include multiple secrets, use
+  the following format:
+  `-p '{"imagePullSecrets": [{"name": "my-registry-pull-secret"}, {"name": "my-registry-pull-secret2"}]}'`.
+
+For more information about updating a Kubernetes `ServiceAccount`
+for accessing the registry, see the Kubernetes documentation,
+[Configure service accounts for pods](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#add-image-pull-secrets-to-a-service-account).