First draft of DNS Publishing RFC

Signed-off-by: Phil Brookes <[email protected]>

Author: philbrookes

rfcs/0013-dns-publishing-strategy-assets/diagram.png

@@ -0,0 +1,70 @@
+## Why
+Currently there is no way to instruct the DNS Operator to publish or unpublish a DNS Record when certain conditions are met, this means that gracefully removing a DNS Record requires manual intervention and an understanding of the internal workings of the DNS-Operator.
+
+### Some Example Use Cases
+- DNS Failover (rapidly switch to alternative DNS Configuration) to a secondary site
+- Workload migration (removing workload from one cluster in favour of a new cluster)
+- Extra clusters during periods of high load
+
+## What
+Add an optional publishStrategy to the dns policy CRD, which will allow an administrator to define a some rules which when met will instruct the DNS Operator to publish/unpublish the records from the zone and set a condition in the status.
+
+## How
+
+### Diagram
+![Diagram of DNS Publish strategy](./0013-dns-publishing-strategy-assets/diagram.png)
+
+https://miro.com/app/board/uXjVL32kOMY=/
+
+### Kuadrant operator changes
+The DNS Policy and DNS Record CRDs will have a new field added to their spec:
+
+```yaml
+publishStrategy:
+  rule: <implemented using Common Expression Language>
+```
+
+This is read by the kuadrant-operator and propagated into any relevant DNS Records.
+
+When the DNS Operator acts on these instructions it will set a condition in the DNS Record, this condition will be propagated back into the relevant DNS Policy.
+
+### DNS Operator Changes
+The DNS Operator will read the publishStrategy from the DNS Record on reconcile, based on the values it will then interrogate the zone values to see if the publish rule is met. If so it will publish the records, if not it will ensure the records are unpublished and update the condition in the DNS Record status to reflect the decision.
+
+### Available CEL Fields
+
+To begin with a few basic fields will be made available, although this could potentially expand in the future.
+- records: The set of related records in the zone
+- unowned_record_count: The number of related records in the zone with an owner ID that is not the local owner ID
+- unhealthy_record_count: The number of related records flagged as unhealthy
+
+## Use cases expanded
+### DNS Failover
+To enact DNS Failover with this config, the rule for publishing could be set to "when all other records are marked as unhealthy".
+
+#### Example
+Cluster 1 has no publishing rule (i.e. always)
+Cluster 2 publishing rule is: "unhealthy_record_count >= unowned_record_count || unowned_record_count == 0"
+
+- Cluster 1 is currently published and healthy and cluster 2 has no published records.
+- An event occurs that causes the workload to begin malfunctioning on cluster 1.
+- All the records for cluster 1 are marked as unhealthy in the registry (but not removed as they are the only records available)
+- cluster 2 reconciles and sees that all the records currently in the zone are unhealthy, as this satisfies it's publishing rule, it publishes it's records
+- cluster 1 reconciles and sees there are records other than it's own and so unpublishes it's own records due to being unhealthy
+- eventually cluster 1 is healthy again and publishes it's records
+- cluster 2 sees that it's rule is no longer satisfied and so unpublishes it's own records.
+
+### Workload migration
+Cluster 1 has a workload that needs to be migrated to cluster 2.
+- publishing rule on cluster 1 is set to: "unowned_record_count = 0"
+- workload is created on cluster 2
+- records created by cluster 2
+- cluster 1 sees other records exist and unpublishes it's records from the zone
+- admin sees the status updated on the DNS Policy in cluster 1 (all records removed from zone) happened more than the TTL ago
+- admin can safely remove the workload from cluster 1.
+
+### Extra clusters during high load
+This would require the addition of some metrics into the CEL rules that are not currently planned, but this can show how that rule might look.
+
+- Cluster 1 has the workload and publishes always
+- Cluster 2 has the workload and has a publishing rule: "requests_per_minute >= n"