-
Notifications
You must be signed in to change notification settings - Fork 2.6k
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
feat(registry): support all "managed" record types #4342
feat(registry): support all "managed" record types #4342
Conversation
Welcome @haslersn! |
Hi @haslersn. Thanks for your PR. I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
13c98b7
to
3e1eb24
Compare
Thanks for this PR @haslersn ! |
/ok-to-test |
The Kubernetes project currently lacks enough contributors to adequately respond to all PRs. This bot triages PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
3e1eb24
to
04701a3
Compare
I don't really know what to write there. The It is expected that the registry supports all records that are created by external-dns, but currently this is not the case. Seen from this angle, this PR is simply a bug fix that establishes expected behavior. In the registry documentation I could add something like: “The registry persists metadata for DNS records of those types specified by Therefore, I now just added „A registry persists metadata for all DNS records created by external-dns“, which is an equivalent statement, because external-dns will not create records of types not specified in |
9033122
to
b119ea1
Compare
b119ea1
to
e637fe1
Compare
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
a2e82c1
to
3721e75
Compare
@mloiseleur PTAL |
registry/txt.go
Outdated
} | ||
|
||
// extractRecordTypeDefaultPosition extracts record type from the default position | ||
// when not using '%{record_type}' in the prefix/suffix | ||
func extractRecordTypeDefaultPosition(name string) (baseName, recordType string) { | ||
func (pr affixNameMapper) extractRecordTypeDefaultPosition(name string) (baseName, recordType string) { |
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.
func (pr affixNameMapper) extractRecordTypeDefaultPosition(name string) (baseName, recordType string) { | |
func (anm affixNameMapper) extractRecordTypeDefaultPosition(name string) (baseName, recordType string) { |
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.
Well, affixNameMapper
already has a lot of methods and all of them use the identifier pr
.
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.
That's true. It does not make sense too. It's like im for TXTRegistry.
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.
Shall I change it everywhere (in a separate commit)?
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.
That would be great, yes 👍
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.
Done
I get your point for the documentation. It makes sense. |
Previously, the registry only supported certain hard-coded record types (A, AAAA, CNAME, NS). With this commit, we instead take the list of types given via --managed-record-types. That means the default now is A, AAAA, CNAME (i.e., NS is no longer included), but I don't think this is a breaking change, because any changes to records that aren't "managed" are filtered out at a later point anyway. Now other record types (such as TXT) can also be handled by the TXT registry. I have tested this by creating a DNSEndpoint with TXT targets and then deleting the DNSEndpoint again. The record and heritage record are correctly created and deleted. Signed-off-by: Sebastian Hasler <[email protected]>
3721e75
to
84cc10e
Compare
Signed-off-by: Sebastian Hasler <[email protected]>
d429855
to
684addd
Compare
/lgtm |
@johngmyers according to the robot, you are requested as a second reviewer. Can you take a look, please? |
The Kubernetes project currently lacks enough active contributors to adequately respond to all PRs. This bot triages PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle rotten |
This should be merged, since it fixes a bug. |
@szuecs can you take a look at this one? (Pinging you, because you have reviewed external-dns PRs in the past.) |
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /close |
@k8s-triage-robot: Closed this PR. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
Previously, the registry only supported certain hard-coded record types (A, AAAA, CNAME, NS). With this commit, we instead take the list of types given via --managed-record-types. That means the default now is A, AAAA, CNAME (i.e., NS is no longer included), but I don't think this is a breaking change, because any changes to records that aren't "managed" are filtered out at a later point anyway.
Now other record types (such as TXT) can also be handled by the TXT registry.
I have tested this by creating a DNSEndpoint with TXT targets and then deleting the DNSEndpoint again. The record and heritage record are correctly created and deleted.
Description
Fixes #ISSUE
Checklist