helmfile delete/destroy be interactive by default

[aegershman]

Piggy-backing off https://github.com/roboll/helmfile/issues/182

Using helmfile version v0.53.3 (provided via brew on mac), but also found this was the case on latest binary release of 0.54.2

helmfile delete should prompt for user confirmation by default, and have --non-interactive (or something to that effect) explicitly called out when confirming the deletion.

I appreciate helmfile's eagerness, but it's probably going to cause someone pain 😉

Sidenote: in general, it may be beneficial to invert the --interactive to be default and have --non-interactive (+ an ability to set it as an env var) be the way to do things without being prompted? Just a thought

[blissd]

I disagree and stand by the discussion in #354.

[aegershman]

I think you and others make good arguments in the linked discussion, though personally I still disagree and think it'd be better if it defaulted to prompting & take in either --non-interactive and/or respect an env_var like HELMFILE_NON_INTERACTIVE.

• There are solid examples of other tools (BOSH, fly-cli for Concourse, cf-cli for Cloudfoundry, etc.) asking for confirmation before performing actions. Granted, there are also plenty of examples defaulting to non-interactive.
• I see your point of view about keeping behavior consistent with kubectl and helm, and feel that's the most compelling reason to keep the behavior of this as-is. I will say, however, that helmfile is obviously very powerful for declaratively configuring a cluster with multiple deployments, but also has much more scope in potential damage. You aren't just operating on a single helm deployment, you're operating on _all_ helm deployments within a cluster, which increases surface area for risk.
• I think it's appropriate to start with the assumption CLI tools will be operated _manually_ at first by a human and used within an automation context second; therefore it's better to default to safeguarding (within reason) and set --non-interactive / HELMFILE_NON_INTERACTIVE when leveraging in ci/cd workflows.

But regardless of my views, it looks like the [discussion has closed on that and this will default to non-interactive](https://github.com/roboll/helmfile/issues/354#issuecomment-424786658, so I suppose there's no reason to reopen this discussion.

[mumoshu]

Hey! Thanks for bringing this up.

I would definitely prefer no-interactivity by default. But I'm ok to enhance helmfile to decide if it should be interactive or not.

Would something like https://github.com/mattn/go-isatty work in practice? For example, can we actually use it so that helmfile decides to be interactive on your laptop, not to be interactive on your laptop but in the middle of a linux pipe, or in CircleCI builds?

[aegershman]

Sure, I understand, no-interactivity by default is how it'll be done 👍 I'm not sure about go-isatty, I have no experience with it... It seems a bit intense of a solution for something that may be able to be solved with an env flag that could be set, like HELMFILE_INTERATIVE, which could fulfill any concerns?

thoughts? Thanks for your time

[sgandon]

I would be more in favour of a flag --interactive that an magical environment variable.

[manics]

For example, can we actually use it so that helmfile decides to be interactive on your laptop, not to be interactive on your laptop but in the middle of a linux pipe, or in CircleCI builds?

I think it's dangerous to have different hidden defaults with a tool this powerful, though it'd be fine to print out an informative error message if the default was interactive but helmfile was run non-interactively.

[aegershman]

Going to reopen this for a bit, but please feel free to close whenever you see fit.

@sgandon I'm picturing the flag --interactive could be explicitly declared or invoked with an env flag.

E.g., like helm itself, which takes in flags like --tls-verify OR can be set with TILLER_TLS_VERIFY, etc.

or, another example, like the bosh-cli:

bosh deploy -h
...
Application Options:
  -v, --version                           Show CLI version
      --config=                           Config file path (default: ~/.bosh/config) [$BOSH_CONFIG]
  -e, --environment=                      Director environment name or URL [$BOSH_ENVIRONMENT]
      --ca-cert=                          Director CA certificate path or value [$BOSH_CA_CERT]
      --sha2                              Use SHA256 checksums [$BOSH_SHA2]
...

A flag and an envvar shouldn't be any different, just being different ways of toggling the (exact) same functionality. I personally feel the best solution is to have commands accept explicitly defined flags or values set via the env. It's an existing pattern, and there are other tools designed with this pattern in mind, e.g. direnv, which automatically loads an .envrc when you cd into the directory.

👍 thoughts?

[sgandon]

I am ok with the double setup using flags and environment variable, this makes sense and does not break anything.
What would be the priority when both flag and env var are used ?

[aegershman]

Because flags are explicitly set by the user, they should take precedence over envvars. This has been my experience with most CLIs at least. Wdyt?