-
Notifications
You must be signed in to change notification settings - Fork 12
rfc: Cluster Aware DNSRecord Delegation #127
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
Signed-off-by: Michael Nairn <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the bones of it is here. I think we should call out in a bit more detail
- how conflicts from a secondary DNSRecord would be handled
- how deletion and clean up is handled
- The minimum perms the primary needs to make this work
- What a CRD provider looks like
I also wondered if it would make things easier to reason about if the DNS Operator/Kuadrant had a flag set from a configmap that would put it into "secondary or primary" mode. You could then have the kuadrant resource accept configuration of
dns:
mode: secondary
that would trigger it to update the configmap mounted into the dns operator. This leaves an open question around providers though
Update to use controller modes instead of the policy spec. Signed-off-by: Michael Nairn <[email protected]>
Add more detail about the CRD Provider implementation. Signed-off-by: Michael Nairn <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is really good. I think we can implement based on this. Only thing I really call out here is that health checks would still be the domain of each individual controller and not be delegated to the primary. One other thought is on the Core DNS plugin. Is there any work required for that or will it remain the same?
Add default provider secret concept Update primary/remote example diagram Update some reference level details, needs more still Rename crd provider to dnsrecord Signed-off-by: Michael Nairn <[email protected]>
Update diagrams crd -> dnsrecord provider Update name requirements of authoritative zone record Update default secret error requirement Update role requirements of cluster aware controller for primary/remote comms. Signed-off-by: Michael Nairn <[email protected]>
Rename rfc to cluster_aware_dnsrecord_delegation Signed-off-by: Michael Nairn <[email protected]>
* Add Namespace requirements for multi cluster * Update CoreDNS provider changes * Updated default provider secret changes Signed-off-by: Michael Nairn <[email protected]>
* Update label requirements. Signed-off-by: Michael Nairn <[email protected]>
* Add details of loading dns operator options form a configMap. Signed-off-by: Michael Nairn <[email protected]>
Signed-off-by: Michael Nairn <[email protected]>
maleck13
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is in line with what was discussed 👍
Signed-off-by: Michael Nairn <[email protected]>
Signed-off-by: Michael Nairn <[email protected]>
Proposal to add functionality to delegate the processing of a DNSRecord to a designated cluster or clusters in a multi cluster environment.
The concepts being proposed can be applied to any of our currently supported DNS providers, but will be a requirement for the multi cluster CoreDNS solution.