This holds the public key for a bare-metal machine. The alternative
is to store this in a secret, but a dedicated CRD works better with
RBAC - we would rather not grant permissions on secrets if we have an
alternative.
We initially support capturing to a file (in our own format, as it
doesn't appear a suitable format exists). This means we don't need a
server to capture the traces, and can start capturing through prow
without a lot of infrastructure changes.
Co-authored-by: Peter Rifel <rifelpet@users.noreply.github.com>
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!)