Core: CLI imporvement VAULT_ADDR Warning message

[aphorise]

When VAULT_ADDR or -address is not set provide warning messages as below. Resolves #9684.

./vault status
  # WARNING: neither VAULT_ADDR nor the -address parameter is set. Defaulting to loopback address (https://127.0.0.1:8200).
  # Error checking seal status: Get "https://127.0.0.1:8200/v1/sys/seal-status": dial tcp 127.0.0.1:8200: connect: connection refused

[mpalmi]

Looks good! Just one concern here. How often do deployments have VAULT_ADDR and -address both unset. Could this potentially cause alarm (or introduce noise)? If that's the case, maybe we could step this down to Info? Otherwise 👍

[aphorise]

How often do deployments have VAULT_ADDR and -address both unset.

Great question - from my observation 99% (if not 100%) is operators on CLI or in an administration scenarios directly accessing a host / pod where defaults that might be set via some script / ENV setter, was not run or forgotten and to make it even more interesting ofc there is no explicit (127.0.0.1) loopback binding and especially not one with v3 SAN DNS + IP certificates which I am opinionated on 😄 (yes you need it! - 0 trust shouldn't mean we tls_disable loopback cause its fine)

Anyway I've generally observed operators do typically find their way back and recall the need to explicitly define something not right - however just a reminder that nothing is set and that defaults address are being used will hopefully prevent repeats of trying the same command and expecting a different outcome (I've seen that too) 🤣

Could this potentially cause alarm (or introduce noise)? If that's the case, maybe we could step this down to Info?

I agree I'd personally do it Info - but playing the devils advocate - other conflicts like in the case of ~/vault_token & TOKEN overlap are WARN - just based on that being a cautionary note then this could equally qualify with its YELLOW colour scheming which is actually why I thought it may be more fitting; also the fact that it's expected less commonly will over-time make it the lesser yet most common YELLOW which could actually be a good thing? 👺

@shaypepper @mr-fixit - do you folks have any opinions here - is WARN too much noise to be seeing each time and can INFO level messages suffice instead?

PS - @mpalmi on a separate topic related to -address I'd love to understand where there may be an absolute need for that as a client (discarding legacy). If there are more exceptions to it's use then it would be great if that could be eventually removed since we've also observed other strange behaviours or confusion where that's seen as directive address to something else - eg vault operator raft join -address=http://...leader:8200 (not correct). I also appreciate that some of these parameters are striving to provide multiple uses as a Vault Client, Vault Agent, Vault Server, etc - in the CLI client case excluding some of these would actually help - maybe one day if Vault gets a separate CLI.

[mr-fixit]

How often do deployments have VAULT_ADDR and -address both unset.

As a newbie, it's the first mistake I made.

@shaypepper @mr-fixit - do you folks have any opinions here - is WARN too much noise to be seeing each time and can INFO level messages suffice instead?

The reason I asked for this was to help the newbie. Will 'INFO' still show up to the newbie?

[aphorise]

@mr-fixit - difference:

[mr-fixit]

i'm happy either way.

[aphorise]

@mpalmi I'm actually now inclined to the Yellow warning which also becomes the first note on dev mode too. WDYT should I move over to info to leave as is?

[aphorise]

@mpalmi please recheck.

[mpalmi]

@mpalmi I'm actually now inclined to the Yellow warning which also becomes the first note on dev mode too. WDYT should I move over to info to leave as is?

I just looked through the existing c.UI.Warn() messages, and they seem to be generally related to failures of some kind. My 2c is that expected default behavior is more at home in the bucket of Info; however, I'm more than happy to let go of this opinion 😄.

I defer to your judgment on this @aphorise.

[mpalmi]

Looks good to me! I'm comfortable with the Warn if you'd prefer to keep it that way.

[aphorise]

Hey @mpalmi do you know if this will make it into 1.12 - prior to it's code freeze?

[aphorise]

Closing in favour of replacement: #17076