rfc for removal of managed zone API #93
Conversation
Sure I can see that. But we have to remove the managedzone ref as part of this work and replace it with a secretRef anyway, so it seemed a reasonable to question if we should go with a single secret or allow multiple as part of this work allowing us to remove a limitation the DNSPolicy has currently and avoid two breaking changes one after the other. So this was really an attempt to be somewhat efficient and remove the need for another RFC. |
Sure, my problem with this is that while removing managedzone is simple enough and probably will go through without much debate. Multiple credentials is a new feature and might require more discussion. When I looked through the PRs I didnt pay much attention to this RFC because I thought it handles just the removal. I would either split this into two RFC or rescope this RFC to focus mainly on the new feature and as part of that we will remove ManagedZone |
Yeah I think that is reasonable. And to be fair the concept emerged as part of thinking about removal. So I guess we can say the original RFC was intended to just be removal of the MZ but our thinking evolved and so re-focusing the RFC to be around supporting multiple providers and domains from a single policy is a reasonable approach or removing that part into a separate RFC 👍 |
|
@mikenairn could I get a review on this |
| ``` | ||
|
|
||
| Validation of the secret structure will happen in the dns operator rather than doing it once in the kuadrant operator and again in the dns operator. If the secret doesn't exist or if the required fields are not present the status of the DNSRecord will be updated to reflect the issue and the DNSPOlicy will reflect this status condition in its existing `recordConditions` section as it does now. | ||
| DNSPolicy controller will only validate that the specified DOMAIN exists in the target gateway. If it does not exist it will mark this in the status of DNSPolicy. |
There was a problem hiding this comment.
What does this mean? Is the policy controller having to read data from the providerRef(secret)?
rfcs/0011-removal-managed-zone.md
Outdated
| ``` | ||
|
|
||
| ZONE_ID: somezone | ||
| DOMAIN_NAME: *.a.b.com |
There was a problem hiding this comment.
The only reason i see needing the DOMAIN_NAME in the secret would be if we intend to look it up, much like we do currently for ManagedZones, is that the intention? Are we still only creating a DNSRecord if we have a providerRef that has a domain set that matches a listener host? If that is the case, domain name here would not have the wildcard on it, it should match the zone domain name a.b.com.
There was a problem hiding this comment.
Yes I forgot to remove this after our conversation online... Will update. I think we just create the DNSRecord and allow the DNS Opertor to do the work and pass back the result.
Signed-off-by: Michael Nairn <[email protected]>
@jsmolar @mikenairn @philbrookes
fixes #67