Tried to install an operator from a tarball which does not exist. Received a confusing message which:
does not contain the string no such file
contains the mistyped filename 3 times
does not contain a colon before the word getting
says something about resolving and index files. These are package repository implementation details opaque to a casual user and are just confusing. I bet a typical user would start to check their DNS setup when after reading such message...
$ kubectl kudo install filename-with-typo.tgz
Error: failed to resolve operator package for: filename-with-typo.tgz getting filename-with-typo.tgz in index file: no operator found for: filename-with-typo.tgz
$ kubectl kudo install ./filename-with-typo.tgz
Error: failed to resolve operator package for: ./filename-with-typo.tgz getting ./filename-with-typo.tgz in index file: no operator found for: ./filename-with-typo.tgz
What you expected to happen:
$ kubectl kudo install filename-with-typo.tgz
Error: failed to find operator package for: filename-with-typo.tgz: no such file or directory in local filesystem, and no such operator in configured package repositories
How to reproduce it (as minimally and precisely as possible):
See above.
Anything else we need to know?:
Some additional thoughts:
I see people struggle with this message in different use cases (tried to get a package from the repo, but happened to have a directory named the same locally; tried to install from a local tarball but had a typo in the name, etc..) and every time the long confusing message made them give up.
Is a dot even allowed in operator names? If not, then the CLI should be able to deduce that this not a name that could possibly exist in a repository and not even look it up there.
The logic for finding an operator is moderately complex. It may be that it is impossible to summarize a failure of such workflow in one line, in a way that is comprehensible to an end-user. Perhaps it would be better to echo the progress as it happens after all, even if that would mean extra verbosity.
Environment:
Kubernetes version (use kubectl version):
Kudo version (use kubectl kudo version): KUDO Version: version.Info{GitVersion:"0.15.0", GitCommit:"f58547c5", BuildDate:"2020-07-09T20:48:15Z", GoVersion:"go1.14.4", Compiler:"gc", Platform:"linux/amd64"} - the experience is the same when using current tip of main
What happened:
Tried to install an operator from a tarball which does not exist. Received a confusing message which:
no such filegettingWhat you expected to happen:
How to reproduce it (as minimally and precisely as possible):
See above.
Anything else we need to know?:
Some additional thoughts:
I see people struggle with this message in different use cases (tried to get a package from the repo, but happened to have a directory named the same locally; tried to install from a local tarball but had a typo in the name, etc..) and every time the long confusing message made them give up.
Is a dot even allowed in operator names? If not, then the CLI should be able to deduce that this not a name that could possibly exist in a repository and not even look it up there.
The logic for finding an operator is moderately complex. It may be that it is impossible to summarize a failure of such workflow in one line, in a way that is comprehensible to an end-user. Perhaps it would be better to echo the progress as it happens after all, even if that would mean extra verbosity.
Environment:
kubectl version):kubectl kudo version):KUDO Version: version.Info{GitVersion:"0.15.0", GitCommit:"f58547c5", BuildDate:"2020-07-09T20:48:15Z", GoVersion:"go1.14.4", Compiler:"gc", Platform:"linux/amd64"}- the experience is the same when using current tip ofmainuname -a):