* 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
* ref(source): use testify with mocks in test code
* fix: re-introduce NewMockSource for convenience
* fix: avoid circular dependency
* ref: increase usage of testify
* chore: vendor testify as a dependency
* fix(*): cleanup testify expectations
* 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
