During "join" of new control plane machines, kubeadm would
download shared certificates and keys from the cluster stored
in a Secret. Based on the contents of an entry in the Secret,
it would use helper functions from client-go to either write
it as public key, cert (mode 644) or as a private key (mode 600).
The existing logic is always writing both keys and certs with mode 600.
Allow detecting public readable data properly and writing some files
with mode 644.
First check the data with ParsePrivateKeyPEM(); if this passes
there must be at least one private key and the file should be written
with mode 600 as private. If that fails, validate if the data contains
public keys with ParsePublicKeysPEM() and write the file as public
(mode 644).
As a result of this new logic, and given the current set of managed
kubeadm files, .key files will end up with 600, while .crt and .pub
files will end up with 644.
We're running ubernetes tests
`should only be allowed to provision PDs in zones
where nodes exist`
on gcp&gke. While the test is useful in exercising
the scenario of identifying extra zone and
creating a node in it, not every Kube
distribution uses the same approach to create a node,
further if even there is an extra zone, we cannot
guarantee the zone to have enough quota. There can also
be other GCP specific edge cases all of which cannot be
covered within this test. So, removing the test
as agreed upon with the storage team
The data structure would wrap an embedded filesystem andthe root
directory relative to which the embedded filesystem is constructed.
Signed-off-by: Nabarun Pal <pal.nabarun95@gmail.com>
Go 1.16's embed directive doesn't allow embeding files from parent
directories. Hence, moving the translations data to inside the i18n package.
Logically speaking as well, kubectl related artifacts should be inside
the kubectl package.
Signed-off-by: Nabarun Pal <pal.nabarun95@gmail.com>
This will only work if the "ReadWriteOncePod" feature gate is enabled.
Additionally, this access mode will only work when used by itself. This
is because when ReadWriteOncePod is used on a PV or PVC, it renders all
other access modes useless since it is most restrictive.
Original:
> This handler will lookup the owner of the given Deployment, and if it is owned by a Foo resource will enqueue that Foo resource for processing.
Fixed:
> This handler will lookup the owner of the given Deployment, and if it is owned by a Foo resource then the handler will enqueue that Foo resource for processing.
