The previous client loader routine assumed KUBECONFIG would be set in
CLI environments. Instead, now take this approach:
1. If KUBECONFIG is set, that is the de-facto override that informs the
tool it is being run in a CLI environment.
2. Otherwise, try creating a client from the default kube config file.
3. If that fails, assume the tool is running in a Kubernetes Pod.
This will continue supporting dev/test environments so that building the
rook container is not necessary for development. It also allows support
for highly opinionated environments (like deployed by OpenShift CSVs)
where it's not possible to install the Rook operator without also
deploying a CephCluster.
Signed-off-by: Blaine Gardner <blaine.gardner@ibm.com>
Add a more involved multus validation test to the Rook binary. Because
this is intended to be end-user runnable, make sure operator-only
commands are hidden.
Build this into the rook binary instead of creating a separate binary
for ease, and because any binary built with the kube api becomes 40+
megabytes. We save quite a bit of space by including this in the Rook
binary, which is good for keeping container layers as small as possible.
Signed-off-by: Blaine Gardner <blaine.gardner@redhat.com>
Blaine Gardner
Blaine Gardner