Update staging

Author: rjeberhard

documentation/staging/content/_index.md

@@ -16,7 +16,7 @@ Oracle is finding ways for organizations using WebLogic Server to run important
 
 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 "/userguide/_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" >}}).
 
-{{% notice tip %}} Step through the [Tutorial](https://github.com/oracle/weblogic-kubernetes-operator/blob/master/kubernetes/hands-on-lab/README.md)
+{{% notice tip %}} Step through the [Tutorial](https://github.com/oracle/weblogic-kubernetes-operator/blob/main/kubernetes/hands-on-lab/README.md)
 using the operator to deploy and run a WebLogic domain container-packaged web application on an Oracle Cloud Infrastructure Container Engine for Kubernetes (OKE) cluster.
 {{% /notice %}}
 

documentation/staging/content/developerguide/branching.md

@@ -5,14 +5,12 @@ draft: false
 weight: 4
 ---
 
-The `master` branch is protected and contains source for the most recently published release, including release candidates.
+The `main` branch is protected and contains source for the latest completed features and bug fixes.  While this branch contains active work, we expect to keep it always "ready to release."  Therefore, longer running feature work will be performed on specific branches, such as `feature/dynamic-clusters`.
 
-The `develop` branch is protected and contains source for the latest completed features and bug fixes.  While this branch contains active work, we expect to keep it always "ready to release."  Therefore, longer running feature work will be performed on specific branches, such as `feature/dynamic-clusters`.
+Because we want to balance separating destabilizing work into feature branches against the possibility of later difficult merges, we encourage developers working on features to pull out any necessary refactoring or improvements that are general purpose into their own shorter-lived branches and create pull requests to `main` when these smaller work items are completed.
 
-Because we want to balance separating destabilizing work into feature branches against the possibility of later difficult merges, we encourage developers working on features to pull out any necessary refactoring or improvements that are general purpose into their own shorter-lived branches and create pull requests to `develop` when these smaller work items are completed.
+All commits to `main` must pass the [integration test suite]({{< relref "/developerguide/integration-tests.md" >}}).  Please run these tests locally before submitting a pull request.  Additionally, each push to a branch in our GitHub repository triggers a run of a subset of the integration tests with the results visible [here](http://build.weblogick8s.org:8080/job/weblogic-kubernetes-operator-quicktest/).
 
-All commits to `develop` must pass the [integration test suite]({{< relref "/developerguide/integration-tests.md" >}}).  Please run these tests locally before submitting a pull request.  Additionally, each push to a branch in our GitHub repository triggers a run of a subset of the integration tests with the results visible [here](http://build.weblogick8s.org:8080/job/weblogic-kubernetes-operator-quicktest/).
-
-Please submit pull requests to the `develop` branch unless you are collaborating on a feature and have another target branch.  Please see details on the Oracle Contributor Agreement (OCA) and guidelines for pull requests on the [README]({{< relref "/_index.md#contributing-to-the-oracle-weblogic-server-kubernetes-operator-repository" >}}).
+Please submit pull requests to the `main` branch unless you are collaborating on a feature and have another target branch.  Please see details on the Oracle Contributor Agreement (OCA) and guidelines for pull requests on the [README]({{< relref "/_index.md#contributing-to-the-oracle-weblogic-server-kubernetes-operator-repository" >}}).
 
 We will create git tags for each release candidate and generally available (GA) release of the operator.

documentation/staging/content/developerguide/building.md

@@ -42,11 +42,16 @@ You may need to create a directory called `/operator` on your machine.  Please b
 
 If you're not running Kubernetes on your development machine, you'll need to make the container image available to a registry visible to your Kubernetes cluster.  Either `docker push` the image to a private registry or upload your image to a machine running Docker and Kubernetes as follows:
 
+On your build machine:
 ```shell
-# on your build machine
 $ docker save weblogic-kubernetes-operator:some-tag > operator.tar
+```
+```shell
 $ scp operator.tar YOUR_USER@YOUR_SERVER:/some/path/operator.tar
-# on the Kubernetes server
+```
+
+On the Kubernetes server:
+```shell
 $ docker load < /some/path/operator.tar
 ```
 

documentation/staging/content/developerguide/documentation.md

@@ -14,30 +14,28 @@ update to the documentation, follow this process:
     $ git clone https://github.com/oracle/weblogic-kubernetes-operator
     ```
 
-2. Create a new branch from master.
+2. Create a new branch.
 
     ```shell
-    $ git checkout master
-    $ git pull origin master
     $ git checkout -b your-branch
     ```
 
 3. Make your documentation updates by editing the source files in
-`docs-source/content`.
+`documentation/staging/content`.
 {{% notice note %}}
-Make sure you check in the changes from the `docs-source/content` area _only_;
+Make sure you check in the changes from the `documentation/staging/content` area _only_;
 do not build the site and check in the static files.
 {{% /notice %}}
 
 4. If you wish to view your changes, you can run the site locally using
 these commands. The site will be available on the URL shown here:
 
     ```shell
-    $ cd docs-source
+    $ cd documentation/staging
     $ hugo server -b http://localhost:1313/weblogic-kubernetes-operator
     ```
 
 5. When you are ready to submit your changes, push your branch to `origin`
 and submit a pull request. Remember to follow the guidelines in the
-[CONTRIBUTING](https://github.com/oracle/weblogic-kubernetes-operator/blob/master/CONTRIBUTING.md)
+[CONTRIBUTING](https://github.com/oracle/weblogic-kubernetes-operator/blob/main/CONTRIBUTING.md)
 document.

documentation/staging/content/developerguide/integration-tests.md

@@ -15,7 +15,7 @@ You will need to obtain the `kube.config` file for an administrative user and ma
 $ mvn clean verify -P java-integration-tests
 ```
 
-For more detailed information, see [How to run the Java integration tests ](https://github.com/oracle/weblogic-kubernetes-operator/tree/master/integration-tests#how-to-run-the-java-integration-tests).
+For more detailed information, see [How to run the Java integration tests ](https://github.com/oracle/weblogic-kubernetes-operator/tree/main/integration-tests#how-to-run-the-java-integration-tests).
 
 {{% notice note %}}
 When you run the integrations tests, they do a cleanup of any operator or domains on that cluster.   

documentation/staging/content/faq/coherence-requirements.md

@@ -53,6 +53,8 @@ If you have issues with clusters not forming, then you should check that
 
 ```shell
 $ rpm -qa | grep conntrack
+```
+```
 libnetfilter_conntrack-1.0.6-1.el7_3.x86_64
 conntrack-tools-1.4.4-4.el7.x86_64
 ```
@@ -69,6 +71,8 @@ following command:
 
 ```shell
 $ iptables -t nat -v  -L POST_public_allow -n
+```
+```
 Chain POST_public_allow (1 references)
 pkts bytes target     prot opt in     out     source               destination
 164K   11M MASQUERADE  all  --  *      !lo     0.0.0.0/0            0.0.0.0/0
@@ -105,7 +109,11 @@ environment:
 
 ```shell
 $ echo 'Set up systemd service to fix iptables nat chain at each reboot (so Coherence will work)...'
+```
+```shell
 $ mkdir -p /etc/systemd/system/
+```
+```shell
 $ cat > /etc/systemd/system/fix-iptables.service << EOF
 [Unit]
 Description=Fix iptables
@@ -139,5 +147,7 @@ EOF
 
 ```shell
 $ echo 'Start the systemd service to fix iptables nat chain...'
+```
+```shell
 $ systemctl enable --now fix-iptables
 ```

documentation/staging/content/faq/namespace-management.md

@@ -34,6 +34,8 @@ For example, the following command shows all the values of the operator release
 
 ```shell
 $ helm get values weblogic-operator
+```
+```
 domainNamespaces:
 - default
 - ns1
@@ -71,6 +73,8 @@ If you don't know the release name of the operator, you can use `helm list` to l
 
 ```shell
 $ helm list --namespace <namespace>
+```
+```shell
 $ helm list --all-namespaces
 ```
 
@@ -102,8 +106,9 @@ $ kubetctl get cm -n <namespace>
 For example, the following example shows that the domain `configmap` resource exists in the namespace `ns1`.
 
 ```shell
-bash-4.2$ kubectl get cm -n ns1
-
+$ kubectl get cm -n ns1
+```
+```
 NAME                 DATA      AGE
 
 weblogic-scripts-cm   14        12m
@@ -118,9 +123,9 @@ Helm release:
 
 ```shell
 $ helm upgrade \
-  weblogic-operator \
-  kubernetes/charts/weblogic-operator \
-  --reuse-values
+    weblogic-operator \
+    kubernetes/charts/weblogic-operator \
+    --reuse-values
 ```
 
 ####  Delete a Kubernetes namespace from the operator
@@ -134,12 +139,12 @@ name of the operator, and `kubernetes/charts/weblogic-operator` is the location
 
 ```shell
 $ helm upgrade \
-  --reuse-values \
-  --set "domainNamespaces={default}" \
-  --wait \
-  --force \
-  weblogic-operator \
-  kubernetes/charts/weblogic-operator
+    --reuse-values \
+    --set "domainNamespaces={default}" \
+    --wait \
+    --force \
+    weblogic-operator \
+    kubernetes/charts/weblogic-operator
 ```
 
 For operators configured to select managed namespaces through the use of a label selector or regular expression,

documentation/staging/content/faq/oci-fss-pv.md

@@ -31,7 +31,7 @@ see [Persistent storage]({{< relref "/userguide/managing-domains/persistent-stor
 
 #### Failure during domain creation with persistent volume sample
 
-The existing sample for [creation of a domain home on persistent volume](https://github.com/oracle/weblogic-kubernetes-operator/tree/master/kubernetes/samples/scripts/create-weblogic-domain/domain-home-on-pv)
+The existing sample for [creation of a domain home on persistent volume](https://github.com/oracle/weblogic-kubernetes-operator/tree/main/kubernetes/samples/scripts/create-weblogic-domain/domain-home-on-pv)
 uses a Kubernetes Job to create the domain. The sample uses an
 `initContainers` section to change the file ownership which will
 fail for OCI FSS created volumes used with an OKE cluster.
@@ -41,7 +41,8 @@ causing the Kubernetes Job to fail. The failure is seen in the
 description of the Kubernetes Job pod:
 ```shell
 $ kubectl describe -n domain1-ns pod domain1-create-weblogic-sample-domain-job-wdkvs
-...
+```
+```
 Init Containers:
   fix-pvc-owner:
     Container ID:  docker://7051b6abdc296c76e937246df03d157926f2f7477e63b6af3bf65f6ae1ceddee
@@ -61,11 +62,10 @@ Init Containers:
     Ready:          False
     Restart Count:  0
     Environment:    <none>
-...
 ```
 
 #### Updating the domain on persistent volume sample
-In the following snippet of the [create-domain-job-template.yaml](https://github.com/oracle/weblogic-kubernetes-operator/blob/master/kubernetes/samples/scripts/create-weblogic-domain/domain-home-on-pv/create-domain-job-template.yaml),
+In the following snippet of the [create-domain-job-template.yaml](https://github.com/oracle/weblogic-kubernetes-operator/blob/main/kubernetes/samples/scripts/create-weblogic-domain/domain-home-on-pv/create-domain-job-template.yaml),
 you can see the updated `command` for the init container:
 ```yaml
 apiVersion: batch/v1

documentation/staging/content/faq/oci-lb.md

@@ -77,6 +77,8 @@ but initially the external IP is shown as `<pending>`.
 
 ```shell
 $ kubectl -n bob get svc
+```
+```
 NAME                                   TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)                       AGE
 bobs-bookstore-admin-server            ClusterIP      None            <none>        8888/TCP,7001/TCP,30101/TCP   9d
 bobs-bookstore-admin-server-ext        NodePort       10.96.224.13    <none>        7001:32401/TCP                9d
@@ -91,6 +93,8 @@ external IP address will be displayed:
 
 ```shell
 $ kubectl -n bob get svc
+```
+```
 NAME                                   TYPE           CLUSTER-IP      EXTERNAL-IP       PORT(S)                       AGE
 bobs-bookstore-admin-server            ClusterIP      None            <none>            8888/TCP,7001/TCP,30101/TCP   9d
 bobs-bookstore-admin-server-ext        NodePort       10.96.224.13    <none>            7001:32401/TCP                9d

documentation/staging/content/faq/resource-settings.md

@@ -133,10 +133,15 @@ It's also important to keep in mind that if you set a value of CPU core count th
 
 ```shell
 $ kubectl get pod sample-domain1-managed-server1 -n sample-domain1-ns
+```
+```
 NAME                              READY   STATUS    RESTARTS   AGE
 sample-domain1-managed-server1    0/1     Pending   0          65s
-
+```
+```shell
 $ kubectl describe pod sample-domain1-managed-server1 -n sample-domain1-ns
+```
+```
 Events:
   Type     Reason            Age                From               Message
   ----     ------            ----               ----               -------