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.
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
John Gardiner Myers