Setting up context usage internally ready for the context to be
exposed.
Also avoid initializing the client until the first usage, making
building VFS path more of a builder function (deterministic, not
expected to fail for good inputs).
By initializing on demand, we avoid the need for some context.Context
during "build" time and better reflect the notion of (passive)
builders vs (active) requests.
The rule of thumb is that we shouldn't be embedding a context.Context,
but it is reasonable when the lifetime is similar and when the
refactor would otherwise be unacceptably large.
This is a minimal way to introduce it, based on adding the support
needed in the GCS support for serviceAccountIssuerDiscovery. We will
need to plumb through the context in many more places over time.
The io/ioutil package has been deprecated as of Go 1.16, see
https://golang.org/doc/go1.16#ioutil. This commit replaces the existing
io/ioutil functions with their new definitions in io and os packages.
Signed-off-by: Eng Zer Jun <engzerjun@gmail.com>
The schema is "azureblob".
azureClient provides two ways to set up credential. One approach is to
use an account key stored in env var. This approach is used when
accessing Blob from kops CLI. The second approach is to retrieve
credentials from Instance Metadata Service. This works only when
azureClient is created on a VM that has sufficient privilege to access
a specified blob. This approach is used from nodeup, etcd-manager,
etc.
Previously the EC2 metadata service was straightforward HTTP, but IMDS
v2 now requires managing a session token (and is more secure for it).
We now use the AWS SDK when retrieving metadata; it automatically
supports IMDS v2.
Distros that use systemd for DHCP often don't have the hostname
correct, due to e.g. the requirement for policy kit.
We don't rely on it being set correctly on other clouds; no real
reason to require it on GCP either!
We don't call klog.InitFlags yet, because that will cause a flag
redefinition error until we get everyone to stop using glog. That
will happen when we update to k8s 1.13.
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
We move everything to the models. We feature-flag it, because we
probably want to change the names etc, and we aren't going to be able to
offer smooth upgrades until that is done.
Ciprian Hacman
Pierre Prinetti
Peter Rifel
Matt Morrison
John Gardiner Myers
justinsb
Leïla MARABESE
Eng Zer Jun
Kenji Kaneda
Ciprian Hacman
Ole Markus With
tanjunchen
Xiaoyu Zhong
mikesplain
andrewsykim
Xiao An
Justin Santa Barbara
zengchen1024
chrislovecnm
yissachar