Release k8s Yellow Submarine

content/operate/kubernetes/active-active/global-config.md

@@ -48,7 +48,6 @@ The [REAADB API reference]({{<relref "/operate/kubernetes/reference/redis_enterp
 
 This section edits the secrets under the REAADB `.spec.globalConfigurations` section. For more information and all available fields, see the [REAADB API reference]({{<relref "/operate/kubernetes/reference/redis_enterprise_active_active_database_api">}}).
 
-
 1. On an existing participating cluster, generate a YAML file containing the database secret with the relevant data.
 
     This example shoes a secret named `my-db-secret` with the password `my-password` encoded in base 64.
@@ -87,7 +86,7 @@ This section edits the secrets under the REAADB `.spec.globalConfigurations` sec
 
 1. On each other participating cluster, check the secret status.
 
-    ``sh
+    ```sh
     kubectl get reaadb <reaadb-name> -o=jsonpath='{.status.secretsStatus}'
     ```
 
@@ -103,4 +102,72 @@ This section edits the secrets under the REAADB `.spec.globalConfigurations` sec
     kubectl apply -f <db-secret-file>
     ```
 
-1. Repeat the previous two steps on every participating cluster.
+1. Repeat the previous two steps on every participating cluster.
+
+## Configure role permissions
+
+You can configure role-based access control (RBAC) permissions for Active-Active databases using the `rolesPermissions` field in the REAADB `.spec.globalConfigurations` section. The role permissions configuration is propagated across all participating clusters, but the underlying roles and Redis ACLs must be manually created on each cluster.
+
+{{<note>}}You must manually create the specified roles and Redis ACLs on all participating clusters before configuring role permissions. The operator only propagates the role permissions configuration—it does not create the underlying roles and ACLs. If roles or ACLs are missing on any cluster, the operator will log errors and dispatch an Event associated with the REAADB object until they are manually created.{{</note>}}
+
+### Prerequisites
+
+Before configuring role permissions:
+
+1. Manually create the required roles and Redis ACLs on all participating clusters using the Redis Enterprise admin console or REST API.
+2. Ensure role and ACL names match exactly across all clusters (names are case-sensitive).
+3. Verify that roles and ACLs are properly configured on each cluster.
+
+{{<warning>}}The operator does not automatically create or synchronize roles and ACLs across clusters. You are responsible for manually creating identical roles and ACLs on each participating cluster.{{</warning>}}
+
+### Add role permissions to REAADB
+
+1. Create or update your REAADB custom resource to include `rolesPermissions` in the global configurations.
+
+    Example REAADB with role permissions:
+
+    ```yaml
+    apiVersion: app.redislabs.com/v1alpha1
+    kind: RedisEnterpriseActiveActiveDatabase
+    metadata:
+      name: reaadb-boeing
+    spec:
+      globalConfigurations:
+        databaseSecretName: <my-secret>
+        memorySize: 200MB
+        shardCount: 3
+        rolesPermissions:
+          - role: <role-name>
+            acl: <acl-name>
+            type: redis-enterprise
+      participatingClusters:
+        - name: rerc-ohare
+        - name: rerc-reagan
+    ```
+
+    Replace `<role-name>` and `<acl-name>` with the exact names of your Redis Enterprise role and ACL.
+
+2. Apply the REAADB custom resource:
+
+    ```sh
+    kubectl apply -f <reaadb-file>
+    ```
+
+    Alternatively, patch an existing REAADB to add role permissions:
+
+    ```sh
+    kubectl patch reaadb <reaadb-name> --type merge --patch \
+    '{"spec": {"globalConfigurations": {"rolesPermissions": [{"role": "<role-name>", "acl": "<acl-name>", "type": "redis-enterprise"}]}}}'
+    ```
+
+3. After the REAADB is active and its replication status is "Up", verify role permissions are applied to the local database using the Redis Enterprise REST API. See [Database requests]({{<relref "/operate/rs/references/rest-api/requests/bdbs#get-bdbs">}}) for details.
+
+### Troubleshooting role permissions
+
+If you encounter issues with role permissions:
+
+- **Missing role or ACL errors**: Manually create the specified roles and ACLs on all participating clusters with exact name matches. The operator cannot create these automatically.
+- **Permission propagation failures**: Verify that the roles and ACLs are properly configured and accessible on each cluster. Remember that you must manually create identical roles and ACLs on every participating cluster.
+- **Case sensitivity issues**: Verify that role and ACL names match exactly, including capitalization, across all clusters.
+
+For more details on the `rolesPermissions` field structure, see the [REAADB API reference]({{<relref "/operate/kubernetes/reference/redis_enterprise_active_active_database_api#specglobalconfigurationsrolespermissions">}}).

content/operate/kubernetes/deployment/helm.md

@@ -11,14 +11,13 @@ weight: 11
 ---
 Helm charts provide a simple way to install the Redis Enterprise for Kubernetes operator in just a few steps. For more information about Helm, go to [https://helm.sh/docs/](https://helm.sh/docs/).
 
-{{<note>}} This feature is currently in public preview and is not supported on production workloads. Only new installations of the Redis operator are supported at this time. The steps for [creating the RedisEnterpriseCluster (REC)]({{<relref "operate/kubernetes/deployment/quick-start#create-a-redis-enterprise-cluster-rec">}}) and other custom resources remain the same.{{</note>}}
-
 ## Prerequisites
 
 - A [supported distribution]({{< relref "/operate/kubernetes/reference/supported_k8s_distributions" >}}) of Kubernetes.
 - At least three worker nodes.
 - [Kubernetes client (kubectl)](https://kubernetes.io/docs/tasks/tools/).
-- [Helm 3.10 or later](https://helm.sh/docs/intro/install/).
+- [Helm 3.10 or later](https://helm.sh/docs/intro/install/)
+    or 3.18 for migrating from a non-Helm installation.
 
 If you suspect your file descriptor limits are below 100,000, you must either manually increase limits or [Allow automatic resource adjustment]({{< relref "/operate/kubernetes/security/allow-resource-adjustment" >}}). Most major cloud providers and standard container runtime configurations set default file descriptor limits well above the minimum required by Redis Enterprise. In these environments, you can safely run without enabling automatic resource adjustment.
 
@@ -36,14 +35,14 @@ The steps below use the following placeholders to indicate command line paramete
 
 1. Add the Redis repository.
 
-```sh
-helm repo add <repo-name> https://helm.redis.io/
-```
+   ```sh
+   helm repo add <repo-name> https://helm.redis.io/
+   ```
 
 2. Install the Helm chart into a new namespace.
 
 ```sh
-helm install <release-name> redis/redis-enterprise-operator \
+helm install <release-name> <repo-name>/redis-enterprise-operator \
     --version <chart-version> \
     --namespace <namespace-name> \
     --create-namespace
@@ -71,13 +70,13 @@ To monitor the installation add the `--debug` flag. The installation runs severa
 
 ### Specify values during install
 
-1. View configurable values with `helm show values <repo-name>/<chart-name>`.
+1. View configurable values with `helm show values <repo-name>/redis-enterprise-operator`.
 
 2. Install the Helm chart, overriding specific value defaults using `--set`.
 
 ```sh
-helm install <operator-name> redis/redis-enterprise-operator \
-    --version <release-name> \
+helm install <operator-name> <repo-name>/redis-enterprise-operator \
+    --version <chart-version> \
     --namespace <namespace-name> \
     --create-namespace
     --set <key1>=<value1> \
@@ -86,20 +85,72 @@ helm install <operator-name> redis/redis-enterprise-operator \
 
 ### Install with values file
 
-1. View configurable values with `helm show values <repo-name>/<chart-name>`.
+1. View configurable values with `helm show values <repo-name>/redis-enterprise-operator`.
 
 2. Create a YAML file to specify the values you want to configure.
 
 3. Install the chart with the `--values` option.
 
 ```sh
-helm install <operator-name> redis/redis-enterprise-operator \
-    --version <release-name> \
+helm install <operator-name> <repo-name>/redis-enterprise-operator \
+    --version <chart-version> \
     --namespace <namespace-name> \
     --create-namespace \
     --values <path-to-values-file>
 ```
 
+## Migrate from a non-Helm installation
+
+To migrate an existing non-Helm installation of the Redis Enterprise operator to a Helm-based installation:
+
+1. [Upgrade]({{<relref "operate/kubernetes/upgrade">}}) your existing Redis Enterprise operator to match the version of the Helm chart you want to install. Use the same non-Helm method you used for the original installation.
+
+2. [Install](#install) the Helm chart adding the `--take-ownership` flag:
+
+   ```sh
+   helm install <release-name> <repo-name>/redis-enterprise-operator --take-ownership
+   ```
+
+   - The `--take-ownership` flag is available with Helm versions 3.18 or later.
+   - This flag is only needed for the first installation of the chart. Subsequent upgrades don't require this flag.
+   - Use the `helm install` command, not `helm upgrade`.
+
+3. Delete the old `ValidatingWebhookConfiguration` object from the previous non-Helm installation:
+
+   ```sh
+   kubectl delete validatingwebhookconfiguration redis-enterprise-admission
+   ```
+
+   This step is only needed when the `admission.limitToNamespace` chart value is set to `true` (the default). In this case, the webhook object installed by the chart is named `redis-enterprise-admission-<namespace>`, and the original webhook object, named `redis-enterprise-admission`, becomes redundant. If `admission.limitToNamespace` is set to `false`, the webhook installed by the chart is named `redis-enterprise-admission`, and the existing webhook object is reused.
+
+## Upgrade the chart
+
+To upgrade an existing Helm chart installation:
+
+```sh
+helm upgrade <release-name> <repo-name>/redis-enterprise-operator --version <chart-version>
+```
+
+You can also upgrade from a local directory:
+
+```sh
+helm upgrade <release-name> <path-to-chart>
+```
+
+For example, to upgrade a chart with the release name `my-redis-enterprise` from the chart's root directory:
+
+```sh
+helm upgrade my-redis-enterprise .
+```
+
+To upgrade with OpenShift, add `--set openshift.mode=true`.
+
+The upgrade process automatically updates the operator and its components, including the Custom Resource Definitions (CRDs). The CRDs are versioned and update only if the new version is higher than the existing version.
+
+After you upgrade the operator, you might need to upgrade your Redis Enterprise clusters, depending on the Redis software version bundled with the operator. For detailed information about the upgrade process, see [Redis Enterprise for Kubernetes upgrade documentation](https://redis.io/docs/latest/operate/kubernetes/upgrade/).
+
+For more information and options when upgrading charts, see [helm upgrade](https://helm.sh/docs/helm/helm_upgrade/).
+
 ## Uninstall
 
 1. Delete any custom resources managed by the operator. See [Delete custom resources]({{<relref "operate/kubernetes/re-clusters/delete-custom-resources">}}) for detailed steps. You must delete custom resources in the correct order to avoid errors.
@@ -116,7 +167,6 @@ This removes all Kubernetes resources associated with the chart and deletes the
 
 ## Known limitations
 
-- Only new installations of the Redis operator are supported at this time. The steps for [creating the RedisEnterpriseCluster (REC)]({{<relref "operate/kubernetes/deployment/quick-start#create-a-redis-enterprise-cluster-rec">}}) and other custom resources remain the same.
-- Upgrades and migrations are not supported.
+- The steps for [creating the RedisEnterpriseCluster (REC)]({{<relref "operate/kubernetes/deployment/quick-start#create-a-redis-enterprise-cluster-rec">}}) and other custom resources remain the same.
 - The chart doesn't include configuration options for multiple namespaces, rack-awareness, and Vault integration. The steps for configuring these options remain the same.
 - The chart has had limited testing in advanced setups, including Active-Active configurations, air-gapped deployments, and IPv6/dual-stack environments.