tridentctl image requires a cluster to run

[tonyskapunk]

Describe the bug When running tridentctl images I expect it to print the images required but fails if a cluster is not available

Environment Provide accurate information about the environment to help us reproduce the issue.

• Other:
  • Tridentctl version: v21.10.0

To Reproduce Run tridentclt images without a KUBECONFIG

KUBECONFIG=/dev/null ./tridentctl --debug images
FATA[0000] could not initialize Kubernetes client; invalid configuration: no configuration has been provided, try setting KUBERNETES_MASTER environment variable

Expected behavior Being able to obtain the list of images used by trident without requiring a cluster.

Additional context Add any other context about the problem here.

[gnarl]

Hi @tonyskapunk,

The tridentctl command does need to inspect the cluster to determine the correct CSI snapshotter sidecar version to report. We expect that there will be additional checks in the future that also require access to the K8S cluster to accurately report the versions of container images that are required.

If you want a quick reference of the images that are required for a particular Kubernetes version you can check the Trident requirements documentation.

[tonyskapunk]

Hello @gnarl thanks for the response and the link to the docs, that's quite helpful.

Do you know if that inspection is due to the k8s cluster version in question? or if there's any additional information from the cluster that is needed? I'm asking because I see tricentctl allows what seems the definition of the k8s version: --k8s-version

The use case in mind is a disconnected cluster (no internet access), where it would be nice to get the list of images needed by trident before installing the cluster so I can mirror those required images beforehand.

[wonderland]

ping

It would be really nice if this works without already having access to a k8s cluster. The typical use case for tridentctl images is to get the required images while still being outside the secure/air-gapped K8s environment.

The docs are not updated for patch releases (e.g. even if you download 21.10.1, the docs still list the 21.10.0 images). Therefore getting the correct and up-to-date list via tridentctl is the better option, imho. The k8s version can be easily provided via the existing flag. Is there anything else tridentctl would require that drives the need for cluster access?

[gnarl]

@wonderland and @tonyskapunk, access to the K8S cluster is needed to determine the correct version of the CSI snapshotter sidecar that is needed. The snapshotter version is determined based on the volumesnapshots.snapshot.storage.k8s.io CRD's version (v1, v1beta1).

[khassel]

All these image info's can be found in cli/k8s_client/yaml_factory.go.

Executing cat yaml_factory.go | sed -n 's|.*{CSI_SIDECAR_REGISTRY}/||gIp' | sort | uniq will bring this result:

csi-attacher:v3.4.0
csi-node-driver-registrar:v2.4.0
csi-provisioner:v2.2.2
csi-provisioner:v3.1.0
csi-resizer:v1.3.0
csi-snapshotter:{CSI_SNAPSHOTTER_VERSION}

and as mentioned by @gnarl the csi-snapshotter tag depends on v1/v1beta1.

In current master the tag could be "v3.0.3" or "v5.0.0" (which is hardcoded in yaml_factory.go).

So why not deliver both images as result of tridentctl images? Or make a new proc tridentctl images-all

I think most users need this list to bring the images from outside into an internal docker registry so no one matters if there is one image in this list which is not used.

[khassel]

another approach could be to add a new flag e.g. --snap-crd-version to tridentctl images and if this is provided the cluster access is omitted.

If you run the current implementation against a cluster where no snapshotter is installed or the serviceaccount has no rights to read crd's tridentctl images always falls back to the old crd version.

One use case to automate complete installation in a new cluster would be

• run tridentctl images -v $(kubectl version -o json | jq -r '.serverVersion.gitVersion') -o json | jq -r '.imageSets[0].images[]' to get images needed
• install external csi-snapshotter with version extracted from the image (e.g. k8s.gcr.io/sig-storage/csi-snapshotter:v5.0.0)
• install trident

With current implementation you would install the wrong (old) snapshotter.

[scaleoutsean]

tridentctl version also requires a cluster to run (in addition to not actually giving version info about the binary tridentctl itself even when it runs online).

That doesn't mean it should run offline. But something like --offline could be used for both image and version info.

[adkerr]

@Scaleoutsean, if you use the --client command it should work without a cluster and -o yaml should give additional information like go version for the binary

[scaleoutsean]

Thanks, @adkerr! In that case --client would work for me if it was a way to get a list of supported images.