Currently the `--label-filter` flag can only be used to filter CRDs
which match the label selector passed through that flag. This change
extends the functionality to the Ingress, Service and Openshift Route
type objects. When the flag is not specified the default value is
`labels.Everything()` which is an empty string, the same as before.
Annotation based filter is inefficient because the filtering has to be
done in the controller instead of the API server like with label
filtering.
refactor: remove dns api logic and use dns api library
enhancement: add additional args for auth credential retieval
cleanup: simplify, organize processing logic
test: update automation and validate
* Graceful handling of misconfigure password for dyn
If a bad password is given for provider "dyn" then the next
login attempt is at least 30minutes apart. This prevents an
account from being suspended.
Improve validation of flags for dyn provider. Add test for
ValidateConfig() and Config.String()
Also add --dyn-min-ttl option which sets the lower limit
of a record's TTL. Ignored if 0 (the default).
* docs: add graceful handling of misconfiguration to changelog
* Initial commit of Infoblox provider
* address @ideahitme's observations
* fail at addressing @szuecs comments
* fix(infoblox): avoid shadowing err variable
* fix flag descriptions
* default ssl verify to true. thanks @szuecs
* chore(infoblox): bump minium required version
This should ideally be a minor bump but let's do that when we have v0.5
* vendor Azure Go SDK (#210)
* vendor the Azure Go SDK and dependencies
* add initial Azure DNS provider implementation (#210)
* add 'azure' value to 'provider' command line option
* add 'azure-config-file' command line option
* add 'azure-resource-group' command line option
* implement initial Azure DNS provider
note: azure provider is not yet fully implemented (does not query for existing
records).
tests and documentation are forthcoming.
* add a tutorial for the Azure provider (#210)
* add tutorial for using ExternalDNS with Azure DNS
* finish implementation of Azure DNS provider (#210)
* implement the Records method for the Azure DNS provider
* refactor Azure API interface for future tests (#210)
* make Azure provider use an interface for future unit tests
* add unit tests for the Azure provider (#210)
* test retrieving Azure DNS records.
* test updating and deleting Azure DNS records.
* test dry run for the Azure provider (i.e. noop).
* feat(config): change defaults, switch flag processing to kingpin
* chore: vendor kingpin as a dependency
* feat(config): auto-detect cluster config from the environment
* chore: clean up definition of flags
* chore: sanitize flags even further
* chore: update changelog with latest flags changes
* fix(aws): fix messed up test name
* feat(google): add ability to apply changes generated from a plan
* feat(controller): first implementation of controller
* feat: allow to configure in-cluster and kubeconfig
* fix(controller): call RunOnce at the right time and in a loop
* feat(google): add dryRun attribute to Google DNS provider
* fix: use hosted zone id instead of DNS name
* fix(google): stupidly filter by A records for now
* feat: allow specifying the google project and zone
* feat: provide a dry-run flag which defaults to false
* chore: vendor new dependencies
* fix(config): fix failing tests for config object
* ref(controller): return plain value of ApplyChanges
* ref: simplify how to get a valid kubernetes client
Types that we want to work using apimachinery typically go into
pkg/apis/X, and the validation goes into pkg/apis/X/validation. We then
add versions into e.g. pkg/apis/X/v1alpha1, but this feels premature at
the moment.
Changing this later is annoyingly difficult, especially in terms of
validation and dependencies.
We will want the apimachinery, so that we can configure from a
configuration file that is versioned. Hopefully dns-controller won't
end up so complicated that we will require it, but I think there is also
value in following the "standard" patterns for controllers that are
emerging from e.g. ingress.
For a fairly simple example of an API, please consult
https://github.com/kubernetes/kubernetes/tree/master/pkg/apis/certificates
