Merge pull request #1385 from mallardduck/bro-docs-fix

[2.9.1][2.8-Next1] Add info about Private Registry Credentials covering backup labels
Merge pull request #1446 from rancher/release/v2.8
2026-09-30 06:54:09 +00:00 · 2024-08-26 16:37:52 -07:00 · 2024-08-26 16:36:13 -07:00 · 2024-08-26 13:25:37 -07:00 · 2024-08-26 12:41:04 -07:00 · 2024-08-26 11:32:52 -07:00
56 changed files with 217 additions and 86 deletions
@@ -0,0 +1,8 @@
 version: 2
 updates:
  - package-ecosystem: gitsubmodule
    schedule:
        interval: "daily"
    directory: /
@@ -4,6 +4,8 @@ on:
  push:
    branches:
      - main
    paths-ignore:
      - '**/README.md'
 jobs:
  build:
@@ -2,8 +2,8 @@ name: Test deployment
 on:
  pull_request:
-    branches:
+    paths-ignore:
-      - main
+      - '**/README.md'
 jobs:
  test-deploy:
@@ -5,7 +5,10 @@
 # It uses Vale (https://vale.sh/docs/vale-cli/installation/) to provide feedback base off the SUSE Style Guide / OpenSUSE style rules (https://github.com/openSUSE/suse-vale-styleguide)
 name: Style check
-on: [pull_request]
+on:
  pull_request:
    paths-ignore:
      - '**/README.md'
 jobs:
  vale-lint:
@@ -1,7 +1,7 @@
-StylesPath = .github/styles
+StylesPath = .github/styles/suse-vale-styleguide
 [formtats]
 mdx = md
 [*.md]
-BasedOnStyles = suse-vale-styleguide
+BasedOnStyles = common
@@ -15,9 +15,9 @@ To get started, [fork](https://github.com/rancher/rancher-docs/fork) and clone t
 Our repository doesn't allow you to make changes directly to the `main` branch. Create a working branch and make pull requests from your fork to [rancher/rancher-docs](https://github.com/rancher/rancher-docs).
-For most updates, you'll need to edit a file in the `/docs` directory, which represents the ["Latest"](https://ranchermanager.docs.rancher.com/) version of our published documentation. The "Latest" version is a mirror of the most recently released version of Rancher. As of December 2023, the most recently released version of Rancher is 2.8.
+For most updates, you'll need to edit a file in the `/docs` directory, which represents the ["Latest"](https://ranchermanager.docs.rancher.com/) version of our published documentation. The "Latest" version is a mirror of the most recently released version of Rancher. As of August 2024, the most recently released version of Rancher is 2.9.
-Whenever an update is made to `/docs`, you should apply the same change to the corresponding file in `/versioned_docs/version-2.8`. If a change only affects older versions, you don't need to mirror it to the `/docs` directory.
+Whenever an update is made to `/docs`, you should apply the same change to the corresponding file in `/versioned_docs/version-2.9`. If a change only affects older versions, you don't need to mirror it to the `/docs` directory.
 If a file is moved or renamed, you'll also need to edit the `sidebars.js` files for each affected version, as well as the list of redirects in `docusaurus.config.js`. See [Moving or Renaming Docs](./moving-or-renaming-docs.md).
@@ -1,5 +1,6 @@
 ---
 title: API Reference
 hide_table_of_contents: true
 ---
 <head>
@@ -16,7 +16,8 @@ Rancher will publish deprecated features as part of the [release notes](https://
 | Patch Version |  Release Date |
 |---------------|---------------|
-| [2.9.0](https://github.com/rancher/rancher/releases/tag/v2.9.0) | July 31, 2024 |
+| [2.9.1](https://github.com/rancher/rancher/releases/tag/v2.9.1) | Aug 26, 2024 |
 | [2.9.0](https://github.com/rancher/rancher/releases/tag/v2.9.0) | Jul 31, 2024 |
 ### What can I expect when a feature is marked for deprecation?
@@ -148,7 +148,7 @@ To see options on how to customize the cert-manager install (including for cases
 :::
 ```
-# If you have installed the CRDs manually instead of with the `--set installCRDs=true` option added to your Helm install command, you should upgrade your CRD resources before upgrading the Helm chart:
+# If you have installed the CRDs manually, instead of setting `installCRDs` or `crds.enabled` to `true` in your Helm install command, you should upgrade your CRD resources before upgrading the Helm chart:
 kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/<VERSION>/cert-manager.crds.yaml
 # Add the Jetstack Helm repository
@@ -161,7 +161,7 @@ helm repo update
 helm install cert-manager jetstack/cert-manager \
  --namespace cert-manager \
  --create-namespace \
-  --set installCRDs=true
+  --set crds.enabled=true
 ```
 Once you’ve installed cert-manager, you can verify it is deployed correctly by checking the cert-manager namespace for running pods:
@@ -46,6 +46,6 @@ A: You can use a runtime like containerd with Kubernetes that does not require D
 Q: If I am already using RKE1 and want to switch to RKE2, what are my migration options?
-A: Today, you can stand up a new cluster and migrate workloads to a new RKE2 cluster that uses containerd. Rancher is exploring the possibility of an in-place upgrade path.
+A: Today, you can stand up a new cluster and migrate workloads to a new RKE2 cluster that uses containerd. For details, see the [RKE to RKE2 Replatforming Guide](https://links.imagerelay.com/cdn/3404/ql/5606a3da2365422ab2250d348aa07112/rke_to_rke2_replatforming_guide.pdf).
 <br/>
@@ -27,7 +27,7 @@ First configure the HTTP proxy settings on the K3s systemd service, so that K3s'
 ```
 cat <<'EOF' | sudo tee /etc/default/k3s > /dev/null
 HTTP_PROXY=http://${proxy_host}
-HTTPS_PROXY=http://${proxy_host}"
+HTTPS_PROXY=http://${proxy_host}
 NO_PROXY=127.0.0.0/8,10.0.0.0/8,cattle-system.svc,172.16.0.0/12,192.168.0.0/16,.svc,.cluster.local
 EOF
 ```
@@ -71,7 +71,7 @@ Then you have to configure the HTTP proxy settings on the RKE2 systemd service,
 ```
 cat <<'EOF' | sudo tee /etc/default/rke2-server > /dev/null
 HTTP_PROXY=http://${proxy_host}
-HTTPS_PROXY=http://${proxy_host}"
+HTTPS_PROXY=http://${proxy_host}
 NO_PROXY=127.0.0.0/8,10.0.0.0/8,cattle-system.svc,172.16.0.0/12,192.168.0.0/16,.svc,.cluster.local
 EOF
 ```
@@ -54,8 +54,20 @@ Since the private registry cannot be configured after the cluster is created, yo
 1. Select **☰ > Cluster Management**.
 1. On the **Clusters** page, click **Create**.
 1. Choose a cluster type.
-1. In the **Cluster Configuration** go to the **Registries** tab and select **Pull images for Rancher from a private registry**.
+1. In the **Cluster Configuration** go to the **Registries** tab.
-1. Enter the registry hostname and credentials.
+1. Check the box next to **Enable cluster scoped container registry for Rancher system container images**.
 1. Enter the registry hostname.
 1. Under **Authentication** select **Create a HTTP Basic Auth Secret** and fill in the credential fields.
 1. Click **Create**.
 **Result:** The new cluster pulls images from the private registry.
 ### Working with Private Registry Credentials
 When working with private registries, it is important to ensure that any secrets created for these registries are properly backed up. When you add a private registry credential secret through the Rancher GUI and select **Create a HTTP Basic Auth Secret**, the secret is included in backup operations using Rancher Backups.
 However, if you create a credential secret outside of the Rancher GUI, such as by using kubectl or Terraform, you must add the `fleet.cattle.io/managed=true` label to indicate that the secret should be included in backups created by Rancher Backups.
 For example, if you have a custom private registry named "my-private-registry" and create a secret called "my-reg-creds" for it, apply the `fleet.cattle.io/managed=true` label to this secret. This ensures that your backup process captures the secret, providing easy restoration if needed.
 By following this guidance, you can ensure that all of your private registry credentials are backed up and easily accessible in the event of a restore or migration.
@@ -19,7 +19,7 @@ These nodes must be in the same region. You may place these servers in separate
 To install the Rancher management server on a high-availability RKE2 cluster, we recommend setting up the following infrastructure:
 - **Three Linux nodes,** typically virtual machines, in the infrastructure provider of your choice.
- **A load balancer** to direct traffic to the two nodes.
+- **A load balancer** to direct traffic to the nodes.
 - **A DNS record** to map a URL to the load balancer. This will become the Rancher server URL, and downstream Kubernetes clusters will need to reach it.
 ### 1. Set up Linux Nodes
@@ -19,6 +19,7 @@ In order to deploy and run the adapter successfully, you need to ensure its vers
 | Rancher Version | Adapter Version  |
 |-----------------|:----------------:|
 | v2.9.1          | v104.0.0+up4.0.0 |
 | v2.9.0          | v104.0.0+up4.0.0 |
 ### 1. Gain Access to the Local Cluster
@@ -89,6 +89,12 @@ We recommend exporting the kubeconfig file so that if Rancher goes down, you can
 ## Impersonation
 :::caution Known Issue
 Service account impersonation (`--as`) used by lower privileged user accounts to remove privileges is not implemented and is a [feature](https://github.com/rancher/rancher/issues/41988) being tracked.
 :::
 Users technically exist only on the upstream cluster. Rancher creates [RoleBindings and ClusterRoleBindings](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#rolebinding-and-clusterrolebinding) that refer to Rancher users, even though there is [no actual User resource](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#users-in-kubernetes) on the downstream cluster.
 When users interact with a downstream cluster through the authentication proxy, there needs to be some entity downstream to serve as the actor for those requests. Rancher creates service accounts to be that entity. Each service account is only granted one permission, which is to **impersonate** the user they belong to. If there was only one service account that could impersonate any user, then it would be possible for a malicious user to corrupt that account and escalate their privileges by impersonating another user. This issue was the basis for a [CVE](https://github.com/rancher/rancher/security/advisories/GHSA-pvxj-25m6-7vqr).
@@ -20,6 +20,7 @@ Each Rancher version is designed to be compatible with a single version of the w
 | Rancher Version | Webhook Version | Availability in Prime | Availability in Community |
 |-----------------|-----------------|-----------------------|---------------------------|
 | v2.9.1          |     v0.5.1      | &check;               | &check;                   |
 | v2.9.0          |     v0.5.0      | &cross;               | &check;                   |
 ## Why Do We Need It?
@@ -185,9 +185,9 @@ module.exports = {
              label: 'Latest',
            },
            2.9: {
-              label: 'v2.9 (Preview)',
+              label: 'v2.9',
              path: 'v2.9',
-              banner: 'unreleased'
+              banner: 'none'
            },
            2.8: {
              label: 'v2.8',
@@ -1,10 +1,10 @@
 <!-- releaseTask -->
-The following table summarizes different GitHub metrics to give you an idea of each project's popularity and activity levels. This data was collected in March 2024.
+The following table summarizes different GitHub metrics to give you an idea of each project's popularity and activity levels. This data was collected in August 2024.
 | Provider | Project | Stars | Forks | Contributors |
 | ---- | ---- | ---- | ---- | ---- |
-| Canal | https://github.com/projectcalico/canal | 714 | 100 | 20 |
+| Canal | https://github.com/projectcalico/canal | 715 | 100 | 20 |
 | Flannel | https://github.com/flannel-io/flannel | 8.7k | 2.9k | 235 |
-| Calico | https://github.com/projectcalico/calico | 5.8k | 1.3k | 353 |
+| Calico | https://github.com/projectcalico/calico | 5.8k | 1.3k | 354 |
-| Weave | https://github.com/weaveworks/weave/ | 6.6k | 668 | 87 |
+| Weave | https://github.com/weaveworks/weave/ | 6.6k | 667 | 87 |
-| Cilium | https://github.com/cilium/cilium | 19.4k | 2.8k | 775 |
+| Cilium | https://github.com/cilium/cilium | 19.4k | 2.9k | 796 |
@@ -18,12 +18,12 @@ Here you can find links to supporting documentation for the current released ver
    <th>Community</th>
  </tr>
  <tr>
-    <td><b>v2.9.0</b></td>
+    <td><b>v2.9.1</b></td>
    <td><a href="https://ranchermanager.docs.rancher.com/v2.9">Documentation</a></td>
-    <td><a href="https://github.com/rancher/rancher/releases/tag/v2.9.0">Release Notes</a></td>
+    <td><a href="https://github.com/rancher/rancher/releases/tag/v2.9.1">Release Notes</a></td>
    <td><center>N/A</center></td>
    <td><center>N/A</center></td>
    <td><center>&#10003;</center></td>
    <td><center>&#10003;</center></td>
  </tr>
 </table>
@@ -39,9 +39,9 @@ Here you can find links to supporting documentation for the current released ver
    <th>Community</th>
  </tr>
  <tr>
-    <td><b>v2.8.6</b></td>
+    <td><b>v2.8.7</b></td>
    <td><a href="https://ranchermanager.docs.rancher.com/v2.8">Documentation</a></td>
-    <td><a href="https://github.com/rancher/rancher/releases/tag/v2.8.6">Release Notes</a></td>
+    <td><a href="https://github.com/rancher/rancher/releases/tag/v2.8.7">Release Notes</a></td>
    <td><center>N/A</center></td>
    <td><center>&#10003;</center></td>
    <td><center>N/A</center></td>
@@ -88,6 +88,30 @@ Here you can find links to supporting documentation for the current released ver
 ### Past Versions
 Here you can find links to supporting documentation for previous versions of Rancher v2.9, and their availability for [Rancher Prime](/v2.9/getting-started/quick-start-guides/deploy-rancher-manager/prime) and the Community version of Rancher:
 <table>
  <tr>
    <th>Version</th>
    <th>Documentation</th>
    <th>Release Notes</th>
    <th>Support Matrix</th>
    <th>Prime</th>
    <th>Community</th>
  </tr>
  <tr>
    <td><b>v2.9.0</b></td>
    <td><a href="https://ranchermanager.docs.rancher.com/v2.9">Documentation</a></td>
    <td><a href="https://github.com/rancher/rancher/releases/tag/v2.9.0">Release Notes</a></td>
    <td><center>N/A</center></td>
    <td><center>N/A</center></td>
    <td><center>&#10003;</center></td>
  </tr>
  <tr>
  </tr>
 </table>
 Here you can find links to supporting documentation for previous versions of Rancher v2.8, and their availability for [Rancher Prime](/v2.8/getting-started/quick-start-guides/deploy-rancher-manager/prime) and the Community version of Rancher:
 <table>
@@ -98,6 +122,14 @@ Here you can find links to supporting documentation for previous versions of Ran
    <th>Support Matrix</th>
    <th>Prime</th>
    <th>Community</th>
  </tr>
    <tr>
    <td><b>v2.8.6</b></td>
    <td><a href="https://ranchermanager.docs.rancher.com/v2.8">Documentation</a></td>
    <td><a href="https://github.com/rancher/rancher/releases/tag/v2.8.6">Release Notes</a></td>
    <td><center>N/A</center></td>
    <td><center>&#10003;</center></td>
    <td><center>N/A</center></td>
  </tr>
   <tr>
    <td><b>v2.8.5</b></td>
@@ -15,7 +15,7 @@ The recommended infrastructure for the Rancher-only Kubernetes cluster differs d
 To install the Rancher management server on a high-availability RKE2 cluster, we recommend setting up the following infrastructure:
 - **Three Linux nodes,** typically virtual machines, in the infrastructure provider of your choice.
- **A load balancer** to direct traffic to the two nodes.
+- **A load balancer** to direct traffic to the nodes.
 - **A DNS record** to map a URL to the load balancer. This will become the Rancher server URL, and downstream Kubernetes clusters will need to reach it.
 ### 1. Set up Linux Nodes
@@ -46,6 +46,6 @@ A: You can use a runtime like containerd with Kubernetes that does not require D
 Q: If I am already using RKE1 and want to switch to RKE2, what are my migration options?
-A: Today, you can stand up a new cluster and migrate workloads to a new RKE2 cluster that uses containerd. Rancher is exploring the possibility of an in-place upgrade path.
+A: Today, you can stand up a new cluster and migrate workloads to a new RKE2 cluster that uses containerd. For details, see the [RKE to RKE2 Replatforming Guide](https://links.imagerelay.com/cdn/3404/ql/5606a3da2365422ab2250d348aa07112/rke_to_rke2_replatforming_guide.pdf).
 <br/>
@@ -19,7 +19,7 @@ These nodes must be in the same region. You may place these servers in separate
 To install the Rancher management server on a high-availability RKE2 cluster, we recommend setting up the following infrastructure:
 - **Three Linux nodes,** typically virtual machines, in the infrastructure provider of your choice.
- **A load balancer** to direct traffic to the two nodes.
+- **A load balancer** to direct traffic to the nodes.
 - **A DNS record** to map a URL to the load balancer. This will become the Rancher server URL, and downstream Kubernetes clusters will need to reach it.
 ### 1. Set up Linux Nodes
@@ -82,6 +82,12 @@ You will need to use a context defined in this kubeconfig file to access the clu
 ## Impersonation
 :::caution Known Issue
 Service account impersonation (`--as`) used by lower privileged user accounts to remove privileges is not implemented and is a [feature](https://github.com/rancher/rancher/issues/41988) being tracked.
 :::
 Users technically exist only on the upstream cluster. Rancher creates [RoleBindings and ClusterRoleBindings](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#rolebinding-and-clusterrolebinding) that refer to Rancher users, even though there is [no actual User resource](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#users-in-kubernetes) on the downstream cluster.
 When users interact with a downstream cluster through the authentication proxy, there needs to be some entity downstream to serve as the actor for those requests. Rancher creates service accounts to be that entity. Each service account is only granted one permission, which is to **impersonate** the user they belong to. If there was only one service account that could impersonate any user, then it would be possible for a malicious user to corrupt that account and escalate their privileges by impersonating another user. This issue was the basis for a [CVE](https://github.com/rancher/rancher/security/advisories/GHSA-pvxj-25m6-7vqr).
@@ -148,7 +148,7 @@ To see options on how to customize the cert-manager install (including for cases
 :::
 ```
-# If you have installed the CRDs manually instead of with the `--set installCRDs=true` option added to your Helm install command, you should upgrade your CRD resources before upgrading the Helm chart:
+# If you have installed the CRDs manually, instead of setting `installCRDs` or `crds.enabled` to `true` in your Helm install command, you should upgrade your CRD resources before upgrading the Helm chart:
 kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/<VERSION>/cert-manager.crds.yaml
 # Add the Jetstack Helm repository
@@ -161,7 +161,7 @@ helm repo update
 helm install cert-manager jetstack/cert-manager \
  --namespace cert-manager \
  --create-namespace \
-  --set installCRDs=true
+  --set crds.enabled=true
 ```
 Once you’ve installed cert-manager, you can verify it is deployed correctly by checking the cert-manager namespace for running pods:
@@ -46,6 +46,6 @@ A: You can use a runtime like containerd with Kubernetes that does not require D
 Q: If I am already using RKE1 and want to switch to RKE2, what are my migration options?
-A: Today, you can stand up a new cluster and migrate workloads to a new RKE2 cluster that uses containerd. Rancher is exploring the possibility of an in-place upgrade path.
+A: Today, you can stand up a new cluster and migrate workloads to a new RKE2 cluster that uses containerd. For details, see the [RKE to RKE2 Replatforming Guide](https://links.imagerelay.com/cdn/3404/ql/5606a3da2365422ab2250d348aa07112/rke_to_rke2_replatforming_guide.pdf).
 <br/>
@@ -27,7 +27,7 @@ First configure the HTTP proxy settings on the K3s systemd service, so that K3s'
 ```
 cat <<'EOF' | sudo tee /etc/default/k3s > /dev/null
 HTTP_PROXY=http://${proxy_host}
-HTTPS_PROXY=http://${proxy_host}"
+HTTPS_PROXY=http://${proxy_host}
 NO_PROXY=127.0.0.0/8,10.0.0.0/8,cattle-system.svc,172.16.0.0/12,192.168.0.0/16,.svc,.cluster.local
 EOF
 ```
@@ -71,7 +71,7 @@ Then you have to configure the HTTP proxy settings on the RKE2 systemd service,
 ```
 cat <<'EOF' | sudo tee /etc/default/rke2-server > /dev/null
 HTTP_PROXY=http://${proxy_host}
-HTTPS_PROXY=http://${proxy_host}"
+HTTPS_PROXY=http://${proxy_host}
 NO_PROXY=127.0.0.0/8,10.0.0.0/8,cattle-system.svc,172.16.0.0/12,192.168.0.0/16,.svc,.cluster.local
 EOF
 ```
@@ -19,7 +19,7 @@ These nodes must be in the same region. You may place these servers in separate
 To install the Rancher management server on a high-availability RKE2 cluster, we recommend setting up the following infrastructure:
 - **Three Linux nodes,** typically virtual machines, in the infrastructure provider of your choice.
- **A load balancer** to direct traffic to the two nodes.
+- **A load balancer** to direct traffic to the nodes.
 - **A DNS record** to map a URL to the load balancer. This will become the Rancher server URL, and downstream Kubernetes clusters will need to reach it.
 ### 1. Set up Linux Nodes
@@ -81,6 +81,12 @@ You will need to use a context defined in this kubeconfig file to access the clu
 ## Impersonation
 :::caution Known Issue
 Service account impersonation (`--as`) used by lower privileged user accounts to remove privileges is not implemented and is a [feature](https://github.com/rancher/rancher/issues/41988) being tracked.
 :::
 Users technically exist only on the upstream cluster. Rancher creates [RoleBindings and ClusterRoleBindings](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#rolebinding-and-clusterrolebinding) that refer to Rancher users, even though there is [no actual User resource](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#users-in-kubernetes) on the downstream cluster.
 When users interact with a downstream cluster through the authentication proxy, there needs to be some entity downstream to serve as the actor for those requests. Rancher creates service accounts to be that entity. Each service account is only granted one permission, which is to **impersonate** the user they belong to. If there was only one service account that could impersonate any user, then it would be possible for a malicious user to corrupt that account and escalate their privileges by impersonating another user. This issue was the basis for a [CVE](https://github.com/rancher/rancher/security/advisories/GHSA-pvxj-25m6-7vqr).
@@ -1,5 +1,6 @@
 ---
 title: API Reference
 hide_table_of_contents: true
 ---
 <head>
@@ -16,8 +16,9 @@ Rancher will publish deprecated features as part of the [release notes](https://
 | Patch Version |  Release Date |
 |---------------|---------------|
-| [2.8.6](https://github.com/rancher/rancher/releases/tag/v2.8.6) | July 31, 2024 |
+| [2.8.7](https://github.com/rancher/rancher/releases/tag/v2.8.7) | Aug 26, 2024 |
-| [2.8.5](https://github.com/rancher/rancher/releases/tag/v2.8.5) | June 17, 2024 |
+| [2.8.6](https://github.com/rancher/rancher/releases/tag/v2.8.6) | Jul 31, 2024 |
 | [2.8.5](https://github.com/rancher/rancher/releases/tag/v2.8.5) | Jun 17, 2024 |
 | [2.8.4](https://github.com/rancher/rancher/releases/tag/v2.8.4) | May 16, 2024  |
 | [2.8.3](https://github.com/rancher/rancher/releases/tag/v2.8.3) | Mar 28, 2024  |
 | [2.8.2](https://github.com/rancher/rancher/releases/tag/v2.8.2) | Feb 8, 2024   |
@@ -148,7 +148,7 @@ To see options on how to customize the cert-manager install (including for cases
 :::
 ```
-# If you have installed the CRDs manually instead of with the `--set installCRDs=true` option added to your Helm install command, you should upgrade your CRD resources before upgrading the Helm chart:
+# If you have installed the CRDs manually, instead of setting `installCRDs` or `crds.enabled` to `true` in your Helm install command, you should upgrade your CRD resources before upgrading the Helm chart:
 kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/<VERSION>/cert-manager.crds.yaml
 # Add the Jetstack Helm repository
@@ -161,7 +161,7 @@ helm repo update
 helm install cert-manager jetstack/cert-manager \
  --namespace cert-manager \
  --create-namespace \
-  --set installCRDs=true
+  --set crds.enabled=true
 ```
 Once you’ve installed cert-manager, you can verify it is deployed correctly by checking the cert-manager namespace for running pods:
@@ -46,6 +46,6 @@ A: You can use a runtime like containerd with Kubernetes that does not require D
 Q: If I am already using RKE1 and want to switch to RKE2, what are my migration options?
-A: Today, you can stand up a new cluster and migrate workloads to a new RKE2 cluster that uses containerd. Rancher is exploring the possibility of an in-place upgrade path.
+A: Today, you can stand up a new cluster and migrate workloads to a new RKE2 cluster that uses containerd. For details, see the [RKE to RKE2 Replatforming Guide](https://links.imagerelay.com/cdn/3404/ql/5606a3da2365422ab2250d348aa07112/rke_to_rke2_replatforming_guide.pdf).
 <br/>
@@ -27,7 +27,7 @@ First configure the HTTP proxy settings on the K3s systemd service, so that K3s'
 ```
 cat <<'EOF' | sudo tee /etc/default/k3s > /dev/null
 HTTP_PROXY=http://${proxy_host}
-HTTPS_PROXY=http://${proxy_host}"
+HTTPS_PROXY=http://${proxy_host}
 NO_PROXY=127.0.0.0/8,10.0.0.0/8,cattle-system.svc,172.16.0.0/12,192.168.0.0/16,.svc,.cluster.local
 EOF
 ```
@@ -71,7 +71,7 @@ Then you have to configure the HTTP proxy settings on the RKE2 systemd service,
 ```
 cat <<'EOF' | sudo tee /etc/default/rke2-server > /dev/null
 HTTP_PROXY=http://${proxy_host}
-HTTPS_PROXY=http://${proxy_host}"
+HTTPS_PROXY=http://${proxy_host}
 NO_PROXY=127.0.0.0/8,10.0.0.0/8,cattle-system.svc,172.16.0.0/12,192.168.0.0/16,.svc,.cluster.local
 EOF
 ```
@@ -54,8 +54,20 @@ Since the private registry cannot be configured after the cluster is created, yo
 1. Select **☰ > Cluster Management**.
 1. On the **Clusters** page, click **Create**.
 1. Choose a cluster type.
-1. In the **Cluster Configuration** go to the **Registries** tab and select **Pull images for Rancher from a private registry**.
+1. In the **Cluster Configuration** go to the **Registries** tab.
-1. Enter the registry hostname and credentials.
+1. Check the box next to **Enable cluster scoped container registry for Rancher system container images**.
 1. Enter the registry hostname.
 1. Under **Authentication** select **Create a HTTP Basic Auth Secret** and fill in the credential fields.
 1. Click **Create**.
 **Result:** The new cluster pulls images from the private registry.
 ### Working with Private Registry Credentials
 When working with private registries, it is important to ensure that any secrets created for these registries are properly backed up. When you add a private registry credential secret through the Rancher GUI and select **Create a HTTP Basic Auth Secret**, the secret is included in backup operations using Rancher Backups.
 However, if you create a credential secret outside of the Rancher GUI, such as by using kubectl or Terraform, you must add the `fleet.cattle.io/managed=true` label to indicate that the secret should be included in backups created by Rancher Backups.
 For example, if you have a custom private registry named "my-private-registry" and create a secret called "my-reg-creds" for it, apply the `fleet.cattle.io/managed=true` label to this secret. This ensures that your backup process captures the secret, providing easy restoration if needed.
 By following this guidance, you can ensure that all of your private registry credentials are backed up and easily accessible in the event of a restore or migration.
@@ -19,7 +19,7 @@ These nodes must be in the same region. You may place these servers in separate
 To install the Rancher management server on a high-availability RKE2 cluster, we recommend setting up the following infrastructure:
 - **Three Linux nodes,** typically virtual machines, in the infrastructure provider of your choice.
- **A load balancer** to direct traffic to the two nodes.
+- **A load balancer** to direct traffic to the nodes.
 - **A DNS record** to map a URL to the load balancer. This will become the Rancher server URL, and downstream Kubernetes clusters will need to reach it.
 ### 1. Set up Linux Nodes
@@ -19,6 +19,7 @@ In order to deploy and run the adapter successfully, you need to ensure its vers
 | Rancher Version | Adapter Version  |
 |-----------------|:----------------:|
 | v2.8.7          | v103.0.1+up3.0.1 |
 | v2.8.6          | v103.0.1+up3.0.1 |
 | v2.8.5          | v103.0.1+up3.0.1 |
 | v2.8.4          | v103.0.1+up3.0.1 |
@@ -90,6 +90,12 @@ We recommend exporting the kubeconfig file so that if Rancher goes down, you can
 ## Impersonation
 :::caution Known Issue
 Service account impersonation (`--as`) used by lower privileged user accounts to remove privileges is not implemented and is a [feature](https://github.com/rancher/rancher/issues/41988) being tracked.
 :::
 Users technically exist only on the upstream cluster. Rancher creates [RoleBindings and ClusterRoleBindings](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#rolebinding-and-clusterrolebinding) that refer to Rancher users, even though there is [no actual User resource](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#users-in-kubernetes) on the downstream cluster.
 When users interact with a downstream cluster through the authentication proxy, there needs to be some entity downstream to serve as the actor for those requests. Rancher creates service accounts to be that entity. Each service account is only granted one permission, which is to **impersonate** the user they belong to. If there was only one service account that could impersonate any user, then it would be possible for a malicious user to corrupt that account and escalate their privileges by impersonating another user. This issue was the basis for a [CVE](https://github.com/rancher/rancher/security/advisories/GHSA-pvxj-25m6-7vqr).
@@ -20,6 +20,7 @@ Each Rancher version is designed to be compatible with a single version of the w
 | Rancher Version | Webhook Version | Availability in Prime | Availability in Community |
 |-----------------|-----------------|-----------------------|---------------------------|
 | v2.8.7          |     v0.4.10     | &check;               | &cross;                   |
 | v2.8.6          |     v0.4.9      | &check;               | &cross;                   |
 | v2.8.5          |     v0.4.7      | &check;               | &check;                   |
 | v2.8.4          |     v0.4.5      | &check;               | &check;                   |
@@ -1,5 +1,6 @@
 ---
 title: API Reference
 hide_table_of_contents: true
 ---
 <head>
@@ -16,7 +16,8 @@ Rancher will publish deprecated features as part of the [release notes](https://
 | Patch Version |  Release Date |
 |---------------|---------------|
-| [2.9.0](https://github.com/rancher/rancher/releases/tag/v2.9.0) | July 31, 2024 |
+| [2.9.1](https://github.com/rancher/rancher/releases/tag/v2.9.1) | Aug 26, 2024 |
 | [2.9.0](https://github.com/rancher/rancher/releases/tag/v2.9.0) | Jul 31, 2024 |
 ### What can I expect when a feature is marked for deprecation?
@@ -148,7 +148,7 @@ To see options on how to customize the cert-manager install (including for cases
 :::
 ```
-# If you have installed the CRDs manually instead of with the `--set installCRDs=true` option added to your Helm install command, you should upgrade your CRD resources before upgrading the Helm chart:
+# If you have installed the CRDs manually, instead of setting `installCRDs` or `crds.enabled` to `true` in your Helm install command, you should upgrade your CRD resources before upgrading the Helm chart:
 kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/<VERSION>/cert-manager.crds.yaml
 # Add the Jetstack Helm repository
@@ -161,7 +161,7 @@ helm repo update
 helm install cert-manager jetstack/cert-manager \
  --namespace cert-manager \
  --create-namespace \
-  --set installCRDs=true
+  --set crds.enabled=true
 ```
 Once you’ve installed cert-manager, you can verify it is deployed correctly by checking the cert-manager namespace for running pods:
@@ -46,6 +46,6 @@ A: You can use a runtime like containerd with Kubernetes that does not require D
 Q: If I am already using RKE1 and want to switch to RKE2, what are my migration options?
-A: Today, you can stand up a new cluster and migrate workloads to a new RKE2 cluster that uses containerd. Rancher is exploring the possibility of an in-place upgrade path.
+A: Today, you can stand up a new cluster and migrate workloads to a new RKE2 cluster that uses containerd. For details, see the [RKE to RKE2 Replatforming Guide](https://links.imagerelay.com/cdn/3404/ql/5606a3da2365422ab2250d348aa07112/rke_to_rke2_replatforming_guide.pdf).
 <br/>
@@ -27,7 +27,7 @@ First configure the HTTP proxy settings on the K3s systemd service, so that K3s'
 ```
 cat <<'EOF' | sudo tee /etc/default/k3s > /dev/null
 HTTP_PROXY=http://${proxy_host}
-HTTPS_PROXY=http://${proxy_host}"
+HTTPS_PROXY=http://${proxy_host}
 NO_PROXY=127.0.0.0/8,10.0.0.0/8,cattle-system.svc,172.16.0.0/12,192.168.0.0/16,.svc,.cluster.local
 EOF
 ```
@@ -71,7 +71,7 @@ Then you have to configure the HTTP proxy settings on the RKE2 systemd service,
 ```
 cat <<'EOF' | sudo tee /etc/default/rke2-server > /dev/null
 HTTP_PROXY=http://${proxy_host}
-HTTPS_PROXY=http://${proxy_host}"
+HTTPS_PROXY=http://${proxy_host}
 NO_PROXY=127.0.0.0/8,10.0.0.0/8,cattle-system.svc,172.16.0.0/12,192.168.0.0/16,.svc,.cluster.local
 EOF
 ```
@@ -0,0 +1,17 @@
 ---
 title: Glossary
 ---
 <head>
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/glossary"/>
 </head>
 This page covers Rancher-specific terminology and symbols which might be unfamiliar, or which differ between Rancher versions.
 ```mdx-code-block
 import Glossary, {toc as GlossaryTOC} from "/shared-files/_glossary.md"
 <Glossary />
 export const toc = GlossaryTOC;
 ```
@@ -39,23 +39,20 @@ However, you'll need to do some additional steps if you're trying to set a names
 1. Select **☰ > Cluster Management**.
 1. Find the RKE2 cluster in the list and click **⋮ >Edit Config**.
-1. From the **Cluster config** menu, select **Registries**.
+1. In the **Cluster Configuration** go to the **Registries** tab.
-1. In the **Registries** pane, select the **Configure advanced containerd mirroring and registry authentication options** option.
+1. Check the box next to **Enable cluster scoped container registry for Rancher system container images**.
-1. In the text fields under **Mirrors**, enter the **Registry Hostname** and **Mirror Endpoints**.
+1. Enter the registry hostname.
-1. Click **Save**.
+1. Under **Authentication** select **Create a HTTP Basic Auth Secret** and fill in the credential fields.
 1. Repeat as necessary for each downstream RKE2 cluster.
 ## Configure a Private Registry with Credentials when Creating a Cluster
 There is no global way to set up a private registry with authorization for every Rancher-provisioned cluster. Therefore, if you want a Rancher-provisioned cluster to pull images from a private registry that requires credentials, you'll have to pass the registry credentials through the advanced cluster options every time you create a new cluster. 
 Since the private registry cannot be configured after the cluster is created, you'll need to perform these steps during initial cluster setup.
 1. Select **☰ > Cluster Management**.
 1. On the **Clusters** page, click **Create**.
 1. Choose a cluster type.
 1. In the **Cluster Configuration** go to the **Registries** tab and select **Pull images for Rancher from a private registry**.
 1. Enter the registry hostname and credentials.
 1. Click **Create**.
 **Result:** The new cluster pulls images from the private registry.
 ### Working with Private Registry Credentials
 When working with private registries, it is important to ensure that any secrets created for these registries are properly backed up. When you add a private registry credential secret through the Rancher GUI and select **Create a HTTP Basic Auth Secret**, the secret is included in backup operations using Rancher Backups.
 However, if you create a credential secret outside of the Rancher GUI, such as by using kubectl or Terraform, you must add the `fleet.cattle.io/managed=true` label to indicate that the secret should be included in backups created by Rancher Backups.
 For example, if you have a custom private registry named "my-private-registry" and create a secret called "my-reg-creds" for it, apply the `fleet.cattle.io/managed=true` label to this secret. This ensures that your backup process captures the secret, providing easy restoration if needed.
 By following this guidance, you can ensure that all of your private registry credentials are backed up and easily accessible in the event of a restore or migration.
@@ -19,7 +19,7 @@ These nodes must be in the same region. You may place these servers in separate
 To install the Rancher management server on a high-availability RKE2 cluster, we recommend setting up the following infrastructure:
 - **Three Linux nodes,** typically virtual machines, in the infrastructure provider of your choice.
- **A load balancer** to direct traffic to the two nodes.
+- **A load balancer** to direct traffic to the nodes.
 - **A DNS record** to map a URL to the load balancer. This will become the Rancher server URL, and downstream Kubernetes clusters will need to reach it.
 ### 1. Set up Linux Nodes
@@ -19,6 +19,7 @@ In order to deploy and run the adapter successfully, you need to ensure its vers
 | Rancher Version | Adapter Version  |
 |-----------------|:----------------:|
 | v2.9.1          | v104.0.0+up4.0.0 |
 | v2.9.0          | v104.0.0+up4.0.0 |
 ### 1. Gain Access to the Local Cluster
@@ -89,6 +89,12 @@ We recommend exporting the kubeconfig file so that if Rancher goes down, you can
 ## Impersonation
 :::caution Known Issue
 Service account impersonation (`--as`) used by lower privileged user accounts to remove privileges is not implemented and is a [feature](https://github.com/rancher/rancher/issues/41988) being tracked.
 :::
 Users technically exist only on the upstream cluster. Rancher creates [RoleBindings and ClusterRoleBindings](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#rolebinding-and-clusterrolebinding) that refer to Rancher users, even though there is [no actual User resource](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#users-in-kubernetes) on the downstream cluster.
 When users interact with a downstream cluster through the authentication proxy, there needs to be some entity downstream to serve as the actor for those requests. Rancher creates service accounts to be that entity. Each service account is only granted one permission, which is to **impersonate** the user they belong to. If there was only one service account that could impersonate any user, then it would be possible for a malicious user to corrupt that account and escalate their privileges by impersonating another user. This issue was the basis for a [CVE](https://github.com/rancher/rancher/security/advisories/GHSA-pvxj-25m6-7vqr).
@@ -20,6 +20,7 @@ Each Rancher version is designed to be compatible with a single version of the w
 | Rancher Version | Webhook Version | Availability in Prime | Availability in Community |
 |-----------------|-----------------|-----------------------|---------------------------|
 | v2.9.1          |     v0.5.1      | &check;               | &check;                   |
 | v2.9.0          |     v0.5.0      | &cross;               | &check;                   |
 ## Why Do We Need It?
@@ -1315,6 +1315,7 @@
                }
              ]
    },
-        "contribute-to-rancher"
+        "contribute-to-rancher",
        "glossary"
  ]
 }
@@ -1249,6 +1249,7 @@
                }
              ]
    },
-        "contribute-to-rancher"
+        "contribute-to-rancher",
        "glossary"
  ]
 }
@@ -1238,6 +1238,7 @@
        }
      ]
    },
-    "contribute-to-rancher"
+    "contribute-to-rancher",
    "glossary"
  ]
 }
@@ -1311,6 +1311,7 @@
        }
      ]
    },
-    "contribute-to-rancher"
+    "contribute-to-rancher",
    "glossary"
  ]
 }
@@ -1318,6 +1318,7 @@
        "api/v3-rancher-api-guide"
      ]
    },
-    "contribute-to-rancher"
+    "contribute-to-rancher",
    "glossary"
  ]
 }
@@ -1322,6 +1322,7 @@
        "api/v3-rancher-api-guide"
      ]
    },
-    "contribute-to-rancher"
+    "contribute-to-rancher",
    "glossary"
  ]
 }
Author	SHA1	Message	Date
Billy Tat	9cb79db3db	Merge pull request #1385 from mallardduck/bro-docs-fix [2.9.1][2.8-Next1] Add info about Private Registry Credentials covering backup labels	2024-08-26 16:37:52 -07:00
Billy Tat	3d868453d3	Merge pull request #1446 from rancher/release/v2.8 Merge release/v2.8 into main	2024-08-26 16:36:13 -07:00
Billy Tat	07741dfc48	Merge pull request #1445 from rancher/release/v2.9 Merge release/v2.9 into main	2024-08-26 13:25:37 -07:00
Sunil Singh	04d996984f	Merge pull request #1447 from sunilarjun/v2.9.1-impersonation V2.9.1 impersonation - v2.6 addition	2024-08-26 12:41:04 -07:00
Sunil Singh	a025bee29f	Merge branch 'rancher:main' into v2.9.1-impersonation	2024-08-26 11:32:52 -07:00
Sunil Singh	5608d3a7e9	Adding note to v2.6 Signed-off-by: Sunil Singh <sunil.singh@suse.com>	2024-08-26 11:29:54 -07:00
Sunil Singh	bd3447eec5	Merge pull request #1444 from sunilarjun/v2.9.1-impersonation [2.9.1] Impersonation - Known Issue Section	2024-08-26 10:56:17 -07:00
Sunil Singh	c4802f036d	Editing Known Issues to singular Signed-off-by: Sunil Singh <sunil.singh@suse.com>	2024-08-26 09:37:35 -07:00
Billy Tat	dadc85b0f4	Merge pull request #1437 from martyav/aug-2024-release-cni-table [v2.9.1][v2.8.7] Aug 2024 CNI popularity update	2024-08-26 09:21:14 -07:00
Billy Tat	34a3c15409	Merge pull request #1434 from martyav/2.9.1-versions-table [v2.9.1] Update versions table	2024-08-26 09:19:55 -07:00
Billy Tat	ac40bb0ea1	Merge pull request #1433 from martyav/2.8.7-versions-table [v2.8.7] Update versions table	2024-08-26 09:19:26 -07:00
Billy Tat	1b61165bfd	Merge pull request #1435 from martyav/2.8.7-rancher-webhook [v2.8.7] Update Webhook Table	2024-08-26 09:17:50 -07:00
Billy Tat	589363b3bf	Merge pull request #1436 from martyav/2.9.1-rancher-webhook [v2.9.1] Update Webhook Table	2024-08-26 09:16:53 -07:00
Billy Tat	6b5c953747	Merge pull request #1438 from martyav/2.8.7-csp-table [v2.8.7] Update CSP Adapter Table	2024-08-26 09:15:46 -07:00
Billy Tat	1ce86b0926	Merge pull request #1439 from martyav/2.9.1-csp-table [v2.9.1] Update CSP Adapter Table	2024-08-26 09:13:50 -07:00
Sunil Singh	a2d2a88054	Adding in known issues warning to Impersonation section for v2.9.1. Signed-off-by: Sunil Singh <sunil.singh@suse.com>	2024-08-26 09:05:31 -07:00
Billy Tat	e317ba5076	Merge pull request #1440 from martyav/2.8.7-deprecations-table [v2.8.7] Update Deprecations Table	2024-08-26 09:01:58 -07:00
Billy Tat	d46b6efe22	Merge pull request #1441 from martyav/2.9.1-deprecations-table [v2.9.1] Update Deprecations Table	2024-08-26 09:01:17 -07:00
Marty Hernandez AvedonandSunil Singh	7df7b91fc4	Apply suggestions from code review Co-authored-by: Sunil Singh <sunil.singh@suse.com>	2024-08-26 11:38:36 -04:00
Marty Hernandez Avedon Dharmit Shah Billy Tat	ea245e3f5b	[v2.8.7] Update from main to keep working branch PRs less messy to review (#1443 ) * Use crds.enabled to install cert-manager Signed-off-by: Dharmit Shah <dharmit.shah@suse.com> * versioned * reverted changes to earliest versions and slightly modified comment * spacing issue --------- Signed-off-by: Dharmit Shah <dharmit.shah@suse.com> Co-authored-by: Dharmit Shah <dharmit.shah@suse.com> Co-authored-by: Billy Tat <btat@suse.com>	2024-08-26 10:03:09 -04:00
Marty Hernandez Avedon Dharmit Shah Billy Tat	db25cc87a5	[v2.9.1] Update from main to keep working branch PRs less messy to review (#1442 ) * Use crds.enabled to install cert-manager Signed-off-by: Dharmit Shah <dharmit.shah@suse.com> * versioned * reverted changes to earliest versions and slightly modified comment * spacing issue --------- Signed-off-by: Dharmit Shah <dharmit.shah@suse.com> Co-authored-by: Dharmit Shah <dharmit.shah@suse.com> Co-authored-by: Billy Tat <btat@suse.com>	2024-08-26 10:03:00 -04:00
martyav	a7e5e2b9cd	consistently using 3 char month	2024-08-26 08:10:10 -04:00
martyav	8040234882	[v2.8.7] Update Deprecations Table	2024-08-26 08:08:51 -04:00
martyav	8a7de06bb8	[v2.9.1] Update Deprecations Table	2024-08-26 08:06:39 -04:00
martyav	93a4f79512	[v2.9.1] Update CSP Adapter Table	2024-08-26 07:33:42 -04:00
martyav	7d51fdb720	[v2.8.7] Update CSP Adapter Table	2024-08-26 07:31:00 -04:00
martyav	16a44f3fab	[v2.9.1][v2.8.6] Aug 2024 CNI popularity update	2024-08-26 07:04:38 -04:00
martyav	382447e1e1	[v2.9.1] Update Webhook Table	2024-08-26 06:49:21 -04:00
martyav	8d50cb4cb8	[v2.8.7] Update Webhook Table	2024-08-26 06:47:17 -04:00
martyav	304fbc7944	Update versions table - v2.8.7	2024-08-26 06:28:32 -04:00
martyav	bf382897c9	Update versions table - v2.9.1	2024-08-23 16:53:51 -04:00
Billy Tat	9b7d9595f8	Merge pull request #1425 from dharmit/crds.enabled Use crds.enabled to install cert-manager	2024-08-19 13:09:38 -07:00
martyav	5afadf201c	spacing issue	2024-08-19 14:23:37 -04:00
martyav	7f02d2bca2	reverted changes to earliest versions and slightly modified comment	2024-08-19 14:01:01 -04:00
Billy Tat	3ab49d575a	Merge pull request #1430 from rancher/valaparthvi-patch-1 Remove extra double quote from the code	2024-08-16 14:11:41 -07:00
martyav	60e77489ca	versioning	2024-08-16 14:09:17 -04:00
Parthvi Vala	cd6b09a947	Update install-kubernetes.md	2024-08-16 15:06:14 +05:30
Parthvi Vala	94ce568974	Update install-kubernetes.md	2024-08-16 15:01:21 +05:30
Chris Wayne martyav Billy Tat	fd780d0cfb	Update dockershim.md (#1426 ) * Update dockershim.md * versioning * Add reference to replatforming guide --------- Co-authored-by: martyav <marty.avedon@suse.com> Co-authored-by: Billy Tat <btat@suse.com>	2024-08-15 11:27:12 -04:00
Billy Tat	c72420642a	Merge pull request #1414 from rancher/rke2-nodes-incorrect Update ha-rke2-kubernetes-cluster.md	2024-08-14 10:51:41 -07:00
martyav	0c56e643ad	versioned	2024-08-13 10:47:47 -04:00
Billy Tat	632569305c	Merge pull request #1427 from rancher/dependabot/submodules/dot-github/styles/suse-vale-styleguide-1701ad8 Bump .github/styles/suse-vale-styleguide from `7267e53` to `1701ad8`	2024-08-08 22:46:30 -07:00
dependabot[bot]	dd6193ab30	Bump .github/styles/suse-vale-styleguide from `7267e53` to `1701ad8` Bumps [.github/styles/suse-vale-styleguide](https://github.com/openSUSE/suse-vale-styleguide) from `7267e53` to `1701ad8`. - [Release notes](https://github.com/openSUSE/suse-vale-styleguide/releases) - [Commits](https://github.com/openSUSE/suse-vale-styleguide/compare/7267e538abe62921af2b422b937a1f80e8b5f6f1...1701ad82d0da679f2e8943c877722923adb2411b) --- updated-dependencies: - dependency-name: ".github/styles/suse-vale-styleguide" dependency-type: direct:production ... Signed-off-by: dependabot[bot] <support@github.com>	2024-08-08 17:17:03 +00:00
Dharmit Shah	1ac9342705	Use crds.enabled to install cert-manager Signed-off-by: Dharmit Shah <dharmit.shah@suse.com>	2024-08-08 17:55:20 +05:30
Billy Tat	c9e51f3940	Merge pull request #1423 from rancher/dependabot/submodules/dot-github/styles/suse-vale-styleguide-7267e53 Bump .github/styles/suse-vale-styleguide from `037b0e6` to `7267e53`	2024-08-06 11:31:27 -07:00
dependabot[bot]	0b50813ef4	Bump .github/styles/suse-vale-styleguide from `037b0e6` to `7267e53` Bumps [.github/styles/suse-vale-styleguide](https://github.com/openSUSE/suse-vale-styleguide) from `037b0e6` to `7267e53`. - [Release notes](https://github.com/openSUSE/suse-vale-styleguide/releases) - [Commits](https://github.com/openSUSE/suse-vale-styleguide/compare/037b0e6c65ed1d76abbe87afce3109affb92d122...7267e538abe62921af2b422b937a1f80e8b5f6f1) --- updated-dependencies: - dependency-name: ".github/styles/suse-vale-styleguide" dependency-type: direct:production ... Signed-off-by: dependabot[bot] <support@github.com>	2024-08-06 17:25:12 +00:00
Billy Tat	02c1192494	Merge pull request #1422 from btat/vale-dependabot Configure dependabot for vale rules	2024-08-02 15:53:07 -07:00
Sunil Singh	c81ab8ad1b	Merge pull request #1421 from sunilarjun/sync-glossary-v2.9 Re-syncing Glossary - v2.9 Docs/Versioned Sidebars	2024-08-02 15:40:08 -07:00
Billy Tat	c2f2645af9	Merge pull request #1420 from btat/vale-dependency Update suse-vale-styleguide dependency	2024-08-02 13:56:31 -07:00
Sunil Singh	25450ce3f0	Fixing whitespace after review. Signed-off-by: Sunil Singh <sunil.singh@suse.com>	2024-08-02 13:16:09 -07:00
martyav	58d5735ea5	versioning	2024-08-02 14:59:52 -04:00
Sunil Singh	ceba62a306	Resyncing Glossary file with v2.9 docs and resyncing versioned sidebars that were missing the glossary field. Signed-off-by: Sunil Singh <sunil.singh@suse.com>	2024-08-02 11:56:25 -07:00
Billy Tat	52d6c14efb	Update suse-vale-styleguide dependency Reference rules from /common	2024-08-02 10:07:54 -07:00
Billy Tat	df9d7ab0a8	Merge pull request #1417 from rancher/martyav-update-readme-for-new-latest Update README.md concerning latest minor version	2024-08-01 16:23:26 -07:00
Billy Tat	cfe40b0a86	Configure dependabot for vale rules	2024-08-01 16:19:54 -07:00
Billy Tat	bb75ae1765	Merge pull request #1419 from btat/ci-ignore-readme Update workflow conditions	2024-08-01 16:06:59 -07:00
Marty Hernandez AvedonandBilly Tat	7400482b35	Update README.md Co-authored-by: Billy Tat <btat@suse.com>	2024-08-01 18:45:31 -04:00
Billy Tat	28617e4be1	Merge pull request #1418 from btat/api-deadspace Remove white space from API ref page	2024-08-01 15:43:10 -07:00
Billy Tat	7370fefe3c	Update workflow conditions - Don't run for README changes - Run style and test deploy for all branches	2024-08-01 15:21:19 -07:00
Billy Tat	a0f600a998	Merge pull request #1416 from sunilarjun/remove-preview Removing Preview/Banner - v2.9 Docs	2024-08-01 15:04:17 -07:00
Billy Tat	6b36d00b9b	Remove white spacee	2024-08-01 14:58:32 -07:00
Marty Hernandez Avedon	3fde374c30	Update README.md concerning latest minor version v2.9 just got released.	2024-08-01 16:12:22 -04:00
Sunil Singh	b737561d7b	Removing Preview label and banner for v2.9. Signed-off-by: Sunil Singh <sunil.singh@suse.com>	2024-08-01 12:37:43 -07:00
dkeightley	65d21cfc40	Update ha-rke2-kubernetes-cluster.md	2024-07-31 17:18:17 +12:00
Dan Pock	011085ac2d	Sync versioned docs pages	2024-07-19 20:05:09 -04:00
DanandMarty Hernandez Avedon	6fd409221d	Update docs/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/global-default-private-registry.md Co-authored-by: Marty Hernandez Avedon <marty.avedon@suse.com>	2024-07-19 15:06:43 -04:00
DanandMarty Hernandez Avedon	1e93509c84	Update docs/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/global-default-private-registry.md Co-authored-by: Marty Hernandez Avedon <marty.avedon@suse.com>	2024-07-19 13:32:39 -04:00
DanandMarty Hernandez Avedon	0ca00b121d	Update docs/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/global-default-private-registry.md Co-authored-by: Marty Hernandez Avedon <marty.avedon@suse.com>	2024-07-19 13:32:10 -04:00
DanandMarty Hernandez Avedon	9ae6f022fc	Update docs/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/global-default-private-registry.md Co-authored-by: Marty Hernandez Avedon <marty.avedon@suse.com>	2024-07-19 13:27:30 -04:00
DanandMarty Hernandez Avedon	ee9876f04a	Update versioned_docs/version-2.8/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/global-default-private-registry.md Co-authored-by: Marty Hernandez Avedon <marty.avedon@suse.com>	2024-07-19 13:27:23 -04:00
DanandMarty Hernandez Avedon	45bf343dba	Update versioned_docs/version-2.8/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/global-default-private-registry.md Co-authored-by: Marty Hernandez Avedon <marty.avedon@suse.com>	2024-07-19 13:26:45 -04:00
DanandMarty Hernandez Avedon	38a442100c	Update versioned_docs/version-2.8/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/global-default-private-registry.md Co-authored-by: Marty Hernandez Avedon <marty.avedon@suse.com>	2024-07-19 13:26:26 -04:00
DanandMarty Hernandez Avedon	6112a7b128	Update versioned_docs/version-2.8/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/global-default-private-registry.md Co-authored-by: Marty Hernandez Avedon <marty.avedon@suse.com>	2024-07-19 13:25:49 -04:00
Dan Pock	bee7f2e892	Clarify the backup in question is BRO	2024-07-18 12:37:18 -04:00
Dan Pock	bd87f0973b	Add info about Private Registry Credentials covering backup labels	2024-07-18 11:32:44 -04:00