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 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>
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!)
We've done this in the API already, but we had a single CAStore
interface that did Keysets and SSHCredentials. Separate out
SSHCredentials into SSHCredentialStore, and start using API objects as
our primary representation.
This lets us configure cross-project permissions while ourselves needing
minimal permissions, but also gives us a nice hook for future lockdown
of object-level permissions.
We modelled our VFS clientset (for API objects backed by a VFS path)
after the "real" clientsets, so now it is relatively easy to add a
second implementation that will be backed by a real clientset.
The snafu here is that we weren't really using namespaces previously.
Namespaces do seem to be the primary RBAC scoping mechanism though, so
we start using them with the real clientset.
The namespace is currently inferred from the cluster name. We map dots
to dashes, because of namespace limitations, which could yield
collisions, but we'll deal with this by simply preventing users from
creating conflicting cluster names - i.e. you simply won't be able to
create a.b.example.com and a-b.example.com