* 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
Kops includes a dns-controller, and this document describes the existing
annotations and their behaviour. This document is intended to allow us
to see the use-cases identified by kops dns-controller, to ensure the
same annotations can be recognized (perhaps with a `--compatibilty`
flag), and to ensure that we have comparable functionality.
* feat: add first implementation of google dns-provider
* chore(dnsprovider): add boilerplate headers
* chore: update list of dependencies
* chore: vendor depedencies
