We're aiming to use this for testing immediately and better
logging/tracing in future, but to make the changes manageable breaking
them into a smaller series that don't directly achieve much.
This is technically a regression. kOps had the behavior where empty image meant use from channel. But this got removed due to strict validation of user input
We check that users haven't specified the kubeconfig file path, as
this file is created / managed by kOps. We don't try to reuse the
upstream configuration validation, as this allows the user to specify
a partial configuration, and this means that we don't have to pull in
the upstream libraries.
We could in future accept the "correct" value or just treat providing
a value as a signal that kOps should not manage the file; for now we
are starting with the most restrictive configuration, as we can then
relax it in future if needed.
This commit will ensure IGs are validated in clientset prior to write similar to clusters. Also introduces strict flag similar to cluster, which only validate values where we have defaults after defaults have been applied.
We will be managing cluster addons using CRDs, and so we want to be
able to apply arbitrary objects as part of cluster bringup.
Start by allowing (behind a feature-flag) for arbitrary objects to be
specified.
Co-authored-by: John Gardiner Myers <jgmyers@proofpoint.com>
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.
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!)
Ignoring replace with no spec changes
Updating replace cancellation to only not set generation, instead of not performing the update
Bazel updates
Setting generation in common clientset code
Bazel updates