From 057317136ed46c969246a175245e1ec310320945 Mon Sep 17 00:00:00 2001
From: Adam Harrison-Fuller <adam@adamhf.io>
Date: Thu, 24 Oct 2019 17:02:09 +0100
Subject: [PATCH] Improve documentation

---
 README.md                                     | 16 ++++++++++
 .../control-label-propagation.yaml            | 29 +++++++++++++++++++
 operator/redisfailover/handler.go             |  2 +-
 3 files changed, 46 insertions(+), 1 deletion(-)
 create mode 100644 example/redisfailover/control-label-propagation.yaml

diff --git a/README.md b/README.md
index e4477f13b..2753e7e2c 100644
--- a/README.md
+++ b/README.md
@@ -117,6 +117,22 @@ 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).
 
+### 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.
+
+By default specifying no whitelist or an empty whitelist will cause all labels to still be copied as not to break backwards compatibility.
+
+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.
+
+
+
+
 ## 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.
diff --git a/example/redisfailover/control-label-propagation.yaml b/example/redisfailover/control-label-propagation.yaml
new file mode 100644
index 000000000..a9f67b12e
--- /dev/null
+++ b/example/redisfailover/control-label-propagation.yaml
@@ -0,0 +1,29 @@
+apiVersion: databases.spotahome.com/v1
+kind: RedisFailover
+metadata:
+  name: redisfailover2
+  labels:
+    # These two labels will be propagated.
+    app.example.com/label1: value
+    app.example.com/label2: value
+    # This one wont be, as there is a non-empty whitelist and the regexp doesnt match it.
+    anotherlabel: value
+spec:
+  sentinel:
+    replicas: 3
+    resources:
+      requests:
+        cpu: 100m
+      limits:
+        memory: 100Mi
+  redis:
+    replicas: 3
+    resources:
+      requests:
+        cpu: 100m
+        memory: 100Mi
+      limits:
+        cpu: 400m
+        memory: 500Mi
+  labelWhitelist:
+  - ^app.example.com.*
diff --git a/operator/redisfailover/handler.go b/operator/redisfailover/handler.go
index e5a7798ff..91d64ee27 100644
--- a/operator/redisfailover/handler.go
+++ b/operator/redisfailover/handler.go
@@ -120,7 +120,7 @@ func (r *RedisFailoverHandler) getLabels(rf *redisfailoverv1.RedisFailover) map[
 			}
 		}
 	} else {
-		// If no whitelist is specified then dont filter label.
+		// If no whitelist is specified then don't filter the labels.
 		filteredCustomLabels = rf.Labels
 	}
 	return util.MergeLabels(defaultLabels, dynLabels, filteredCustomLabels)