This requires passing a cloud object in additional places throughout the validation package and originating mostly from cmd/kops
This means that some kops commands now require valid cloud provider credentials, but I don't think this is an issue because the vast majority of use-cases already require the same cloud provider credentials in order to interact with the state store.
kube-apiserver doesn't expose the healthcheck via a dedicated
endpoint, instead relying on anonyomous-access being enabled. That
has previously forced us to enable the unauthenticated endpoint on
127.0.0.1:8080.
Instead we now run a small sidecar container, which
proxies /healthz and /readyz requests (only) adding appropriate
authentication using a client certificate.
This will also enable better load balancer checks in future, as these
have previously been hampered by the custom CA certificate.
Co-authored-by: John Gardiner Myers <jgmyers@proofpoint.com>
The client-go signature for most methods adds a context.Context
object, and also makes Options mandatory. Feed through a
context.Context through many of our methods (but use context.TODO to
stop it getting totally out of hand!)
Add tests for no ssh key functionality
Add docs for setting no ssh key
Disable sshKey rendering for cloudformation if nosshkey is set
Fix broken test
make goimports
Fix
Formatting fix
Update kubernetes version for tests
Update expected test output
Fix imports in mesh.pb.go
Run hack/update-expected.sh
Change digital ocean logic to handle *string for SSHKeyName
Fix expected output
Missed a few
As discussed during yesterday's office hours.
This should be cherry-picked back to 1.16.
We'll need to bump the minor version in the 1.17 and master branches.
Once we officially drop support we could make this a sliding window that uses the `kops.Version` variable.
I think we could have deprecation warnings for the 2 oldest versions still supported by the kops version, announcing that the n+2 Kops version will no longer support the specified k8s version.
Like we recently did with kops-controller, this means we aren't
reliant on pushing a docker container for development. This should
also fix the e2e tests, which otherwise break whenever we make an
incompatible change to dns-controller.
We then `docker load` it when using a KOPS_BASE_URL.
This should simplify the development process (particularly once we
also do this for dns-controller; at that point we won't need a
registry at all).
This should also fix the problems in CI, where the kops-controller
image isn't available. We've been getting away with testing with the
previous version for dns-controller, which changes pretty slowly. But
that's not a good idea for kops-controller, which is likely to be more
critical and evolve more rapidly.