Should podcli exit with errorlevel for unknown command?

[Jaykul]

I discovered this morning that if we make a mistake in the command-line for podcli, the healthchecks always "pass" without checking anything. For instance, if someone tries this:

        readinessProbe:
          exec:
            command:
            - podcli
            - check
            - https
            - localhost:9898/readyz
          initialDelaySeconds: 5
          timeoutSeconds: 5

It outputs the help, but doesn't produce a non-zero exit code, so the health check "passes"

Obviously, what they meant was this:

        readinessProbe:
          exec:
            command:
            - podcli
            - check
            - http
            - https://localhost:9898/readyz
          initialDelaySeconds: 5
          timeoutSeconds: 5

[stefanprodan]

We should error out on unknown commands, in this case is the command but a flag.

[Jaykul]

That's true, but there's really very little difference when we're in automation.

In general, I'm not a fan of apps spitting out help when they're not explicitly asked for help, and this is why. Tools should produce an error whenever the command line is wrong. Helpful error messages are great, but if there's no error, the automation wrappers can't tell the difference between constructive help text and normal output.

In this case, the end result is a health check that ... doesn't check anything.

I would argue that unless the user intentionally asked for help (i.e. used the "help" command, or put "-h" on there), if podcli can't parse the command line -- it doesn't really matter if it's a bad command or bad parameters, this is an error condition.

[stefanprodan]

Agreed! i think there is a setting in cobra to error out

[stefanprodan]

Exiting with an error on unknown commands is not supported by cobra, this PR needs to be merged: spf13/cobra#2167