external-dns
external-dns copied to clipboard
kubernetes-sigs
Make DNSEndpoint CRD GA
The DNSEndpoint specified in a custom resource is very powerful and allows ExternalDNS to be used in many different ways (e.g. custom CNAME for OpenShift routes, managing A records of nodes in a Open Cluster Management context, setting a TXT records for a ACME DNS challenge). It would be really awesome to have this feature GA.
This issue is meant to track the missing features for the CRD to become GA.
https://github.com/kubernetes-sigs/external-dns/issues/2529 https://github.com/kubernetes-sigs/external-dns/issues/2936
The status of the DNSEndpoint should be improved by at least adding the error message and maybe some provider related status information (e.g. reference for InfoBlox, ...).
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.
This bot triages issues and PRs according to the following rules:
- After 90d of inactivity,
lifecycle/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas applied, the issue is closed
You can:
- Mark this issue or PR as fresh with
/remove-lifecycle stale - Mark this issue or PR as rotten with
/lifecycle rotten - Close this issue or PR with
/close - Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
The Kubernetes project currently lacks enough contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
- After 90d of inactivity,
lifecycle/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas applied, the issue is closed
You can:
- Mark this issue as fresh with
/remove-lifecycle stale - Close this issue with
/close - Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
- After 90d of inactivity,
lifecycle/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas applied, the issue is closed
You can:
- Mark this issue as fresh with
/remove-lifecycle rotten - Close this issue with
/close - Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle rotten
The Kubernetes project currently lacks enough contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
- After 90d of inactivity,
lifecycle/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas applied, the issue is closed
You can:
- Mark this issue as fresh with
/remove-lifecycle stale - Close this issue with
/close - Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
- After 90d of inactivity,
lifecycle/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas applied, the issue is closed
You can:
- Mark this issue as fresh with
/remove-lifecycle rotten - Close this issue with
/close - Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle rotten
@snorwin fully agree that we should improve the DNSEndpoint status reporting. What status fields/logs/events/conditions did you have in mind?
From my understanding we should at least see in the status of the DNSEndpoint CR whether the RR was synced to the provider or not.
@jstudler as you mentioned, most important is to know if the DNSEndpoint was synced to the provider and the error message in case an error occurred. The information whether a DNSEndpoint is skipped or does not match the regex filters of the DNS zone or is currently not tracked by the operator (e.g. missing owner TXT record) could also be of interest.
I could also imagine that provider-specific metadata (e.g., for tracking references and ID) as a map[string]string in the status could simplify certain provider implementations.