spotahome · uhthomas · May 11, 2023
@@ -201,3 +201,4 @@ generate-crd:
  -e CRD_OUT_PATH=/go/src/$(PROJECT_PACKAGE)/manifests \
  $(CODEGEN_IMAGE) update-crd.sh
  cp -f manifests/databases.spotahome.com_redisfailovers.yaml manifests/kustomize/base
+ cp -f manifests/databases.spotahome.com_redisfailovers.yaml charts/redisoperator/crds
@@ -22,7 +22,7 @@ It can be done with plain old [deployment](example/operator), using [Kustomize](
 
 From the root folder of the project, execute the following:
 
-```
+```sh
 helm repo add redis-operator https://spotahome.github.io/redis-operator
 helm repo update
 helm install redis-operator redis-operator/redis-operator
@@ -32,19 +32,20 @@ helm install redis-operator redis-operator/redis-operator
 
 Helm chart only manage the creation of CRD in the first install. In order to update the CRD you will need to apply directly.
 
-```
+```sh
 REDIS_OPERATOR_VERSION=v1.2.4
 kubectl replace -f https://raw.githubusercontent.com/spotahome/redis-operator/${REDIS_OPERATOR_VERSION}/manifests/databases.spotahome.com_redisfailovers.yaml
 ```
 
-```
+```sh
 helm upgrade redis-operator redis-operator/redis-operator
 ```
+
 ### Using kubectl
 
 To create the operator, you can directly create it with kubectl:
 
-```
+```sh
 REDIS_OPERATOR_VERSION=v1.2.4
 kubectl create -f https://raw.githubusercontent.com/spotahome/redis-operator/${REDIS_OPERATOR_VERSION}/manifests/databases.spotahome.com_redisfailovers.yaml
 kubectl apply -f https://raw.githubusercontent.com/spotahome/redis-operator/${REDIS_OPERATOR_VERSION}/example/operator/all-redis-operator-resources.yaml
@@ -97,7 +98,7 @@ Once the operator is deployed inside a Kubernetes cluster, a new API will be acc
 
 In order to deploy a new redis-failover a [specification](example/redisfailover/basic.yaml) has to be created:
 
-```
+```sh
 REDIS_OPERATOR_VERSION=v1.2.4
 kubectl create -f https://raw.githubusercontent.com/spotahome/redis-operator/${REDIS_OPERATOR_VERSION}/example/redisfailover/basic.yaml
 ```
@@ -173,35 +174,42 @@ By default, redis and sentinel will be called with the basic command, giving the
 If necessary, this command can be changed with the `command` option inside redis/sentinel spec. An example can be found in the [custom command example file](example/redisfailover/custom-command.yaml).
 
 ### Custom Priority Class
+
 In order to use a custom Kubernetes [Priority Class](https://kubernetes.io/docs/concepts/configuration/pod-priority-preemption/#priorityclass) for Redis and/or Sentinel pods, you can set the `priorityClassName` in the redis/sentinel spec, this attribute has no default and depends on the specific cluster configuration. **Note:** the operator doesn't create the referenced `Priority Class` resource.
 
 ### Custom Service Account
+
 In order to use a custom Kubernetes [Service Account](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/) for Redis and/or Sentinel pods, you can set the `serviceAccountName` in the redis/sentinel spec, if not specified the `default` Service Account will be used. **Note:** the operator doesn't create the referenced `Service Account` resource.
 
 ### Custom Pod Annotations
+
 By default, no pod annotations will be applied to Redis nor Sentinel pods.
 
 In order to apply custom pod Annotations, you can provide the `podAnnotations` option inside redis/sentinel spec. An example can be found in the [custom annotations example file](example/redisfailover/custom-annotations.yaml).
+
 ### Custom Service Annotations
+
 By default, no service annotations will be applied to the Redis nor Sentinel services.
 
 In order to apply custom service Annotations, you can provide the `serviceAnnotations` option inside redis/sentinel spec. An example can be found in the [custom annotations example file](example/redisfailover/custom-annotations.yaml).
 
-### Control of label propagation.
+### Control of label propagation
+
 By default the operator will propagate all labels on the CRD down to the resources that it creates. This can be problematic if the
 labels on the CRD are not fully under your own control (for example: being deployed by a gitops operator)
-as a change to a labels value can fail on immutable resources such as PodDisruptionBudgets.  To control what labels the operator propagates
-to resource is creates you can modify the labelWhitelist option in the spec.
+as a change to a labels value can fail on immutable resources such as PodDisruptionBudgets. To control what labels the operator propagates
+to resource is creates you can modify the `propagateLabels` option in the spec.
 
-By default specifying no whitelist or an empty whitelist will cause all labels to still be copied as not to break backwards compatibility.
+All labels will be propagated unless otherwise specified.
 
 Items in the array should be regular expressions, see [here](example/redisfailover/control-label-propagation.yaml) as an example of how they can be used and
 [here](https://github.com/google/re2/wiki/Syntax) for a syntax reference.
 
-The whitelist can also be used as a form of blacklist by specifying a regular expression that will not match any label.
+The allowlist can also be used as a form of blocklist by specifying a regular expression that will not match any label.
 
-NOTE: The operator will always add the labels it requires for operation to resources. These are the following:
-```
+NOTE: The operator will always add the labels it requires for operation to resources. These are the following:
+
+```yaml
 app.kubernetes.io/component
 app.kubernetes.io/managed-by
 app.kubernetes.io/name
@@ -213,12 +221,13 @@ redisfailovers.databases.spotahome.com/name
 ### ExtraVolumes and ExtraVolumeMounts
 
 If the user choose to have extra volumes creates and mounted, he could use the `extraVolumes` and `extraVolumeMounts`, in `spec.redis` of the CRD. This allows users to mount the extra configurations, or secrets to be used. A typical use case for this might be
+
 - Secrets that sidecars might use to backup of RDBs
 - Extra users and their secrets and acls that could used the initContainers to create multiple users
 - Extra Configurations that could merge on top the existing configurations
 - To pass failover scripts for addition for additional operations
 
-```
+```yaml
 ---
 apiVersion: v1
 kind: Secret
@@ -259,14 +268,12 @@ spec:
  readOnly: true
 ```
 
-
-
 ## Connection to the created Redis Failovers
 
 In order to connect to the redis-failover and use it, a [Sentinel-ready](https://redis.io/topics/sentinel-clients) library has to be used. This will connect through the Sentinel service to the Redis node working as a master.
 The connection parameters are the following:
 
-```
+```yaml
 url: rfs-<NAME>
 port: 26379
 master-name: mymaster
@@ -276,7 +283,7 @@ master-name: mymaster
 
 To enable auth create a secret with a password field:
 
-```
+```yaml
 echo -n "pass" > password
 kubectl create secret generic redis-auth --from-file=password
 
@@ -293,19 +300,22 @@ spec:
  auth:
  secretPath: redis-auth
 ```
+
 You need to set secretPath as the secret name which is created before.
 
 ### Bootstrapping from pre-existing Redis Instance(s)
+
 If you are wanting to migrate off of a pre-existing Redis instance, you can provide a `bootstrapNode` to your `RedisFailover` resource spec.
 
 This `bootstrapNode` can be configured as follows:
-|  Key | Type | Description | Example File |
-|:--------------:|--------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------|
-| host | **required** | The IP of the target Redis address or the ClusterIP of a pre-existing Kubernetes Service targeting Redis pods | [bootstrapping.yaml](example/redisfailover/bootstrapping.yaml) |
-| port | _optional_ | The Port that the target Redis address is listening to. Defaults to `6379`. | [bootstrapping-with-port.yaml](example/redisfailover/bootstrapping-with-port.yaml) |
+| Key  | Type | Description | Example File |
+| :------------: | ------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------- |
+| host | **required** | The IP of the target Redis address or the ClusterIP of a pre-existing Kubernetes Service targeting Redis pods | [bootstrapping.yaml](example/redisfailover/bootstrapping.yaml) |
+| port | _optional_ | The Port that the target Redis address is listening to. Defaults to `6379`. | [bootstrapping-with-port.yaml](example/redisfailover/bootstrapping-with-port.yaml) |
 | allowSentinels | _optional_ | Allow the Operator to also create the specified Sentinel resources and point them to the target Node/Port. By default, the Sentinel resources will **not** be created when bootstrapping. | [bootstrapping-with-sentinels.yaml](example/redisfailover/bootstrapping-with-sentinels.yaml) |
 
 #### What is Bootstrapping?
+
 When a `bootstrapNode` is provided, the Operator will always set all of the defined Redis instances to replicate from the provided `bootstrapNode` host value.
 This allows for defining a `RedisFailover` that replicates from an existing Redis instance to ease cutover from one instance to another.
 
@@ -314,16 +324,19 @@ This allows for defining a `RedisFailover` that replicates from an existing Redi
 Depending on the configuration provided, the Operator will launch the `RedisFailover` in two bootstrapping states: without sentinels and with sentinels.
 
 #### Default Bootstrapping Mode (Without Sentinels)
+
 By default, if the `RedisFailover` resource defines a valid `bootstrapNode`, **only the redis instances will be created**.
 This allows for ease of bootstrapping from an existing `RedisFailover` instance without the Sentinels intermingling with each other.
 
 #### Bootstrapping With Sentinels
+
 When `allowSentinels` is provided, the Operator will also create the defined Sentinel resources. These sentinels will be configured to point to the provided
 `bootstrapNode` as their monitored master.
 
 ### Default versions
 
 The image versions deployed by the operator can be found on the [defaults file](api/redisfailover/v1/defaults.go).
+
 ## Cleanup
 
 ### Operator and CRD
@@ -332,15 +345,15 @@ If you want to delete the operator from your Kubernetes cluster, the operator de
 
 Also, the CRD has to be deleted. Deleting CRD automatically wil delete all redis failover custom resources and their managed resources:
 
-```
+```sh
 kubectl delete crd redisfailovers.databases.spotahome.com
 ```
 
 ### Single Redis Failover
 
 Thanks to Kubernetes' `OwnerReference`, all the objects created from a redis-failover will be deleted after the custom resource is.
 
-```
+```sh
 kubectl delete redisfailover <NAME>
 ```
 
@@ -349,6 +362,7 @@ kubectl delete redisfailover <NAME>
 ### Redis Operator
 
 [![Redis Operator Image](https://quay.io/repository/spotahome/redis-operator/status "Redis Operator Image")](https://quay.io/repository/spotahome/redis-operator)
+
 ## Documentation
 
 For the code documentation, you can lookup on the [GoDoc](https://godoc.org/github.com/spotahome/redis-operator).

@@ -22,11 +22,11 @@ type RedisFailover struct {
 
 // RedisFailoverSpec represents a Redis failover spec
 type RedisFailoverSpec struct {
- Redis RedisSettings `json:"redis,omitempty"`
- Sentinel SentinelSettings `json:"sentinel,omitempty"`
- Auth AuthSettings `json:"auth,omitempty"`
- LabelWhitelist []string `json:"labelWhitelist,omitempty"`
- BootstrapNode *BootstrapSettings `json:"bootstrapNode,omitempty"`
+ Redis  RedisSettings `json:"redis,omitempty"`
+ Sentinel  SentinelSettings `json:"sentinel,omitempty"`
+ Auth  AuthSettings `json:"auth,omitempty"`
+ PropagateLabels []string `json:"propagateLabels,omitempty"`
+ BootstrapNode  *BootstrapSettings `json:"bootstrapNode,omitempty"`
 }
 
 // RedisCommandRename defines the specification of a "rename-command" configuration option