request: improve vault login error message to help the newbie

[mr-fixit]

If I run vault login... without an -address FOO parameter, and don't have VAULT_ADDR defined, it will use the default, as per vault login --help:

-address=
Address of the Vault server. The default is https://127.0.0.1:8200. This
can also be specified via the VAULT_ADDR environment variable.

Since I'm a newbie, doing this by accident, I don't have a local vault server at that address, so I get this:

Error authenticating: Put https://127.0.0.1:8200/v1/auth/nytimes-github/login: dial tcp 127.0.0.1:8200: connect: connection refused

This error message doesn't help me, because I don't know enough about vault to recognize the existent of 127.0.0.1:8200 in the error message as a sign that I'm using the default value for the address.

Describe the solution you'd like
In this situation, could something like the following be added to the error message?

There is no vault server running at the default address (127.0.0.1:8200). Please pass a valid address via the `-address` parameter or the environment variable VAULT_ADDR

[shaypepper]

I would love to see this fixed too. I got caught on this for an embarrassingly long time!

[aphorise]

@mr-fixit @shaypepper do you have any inputs or opinions on the weather the related message on the PR should be INFO level or WARNING? - or it doesnt matter so much?

[mr-fixit]

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

[michaeljs1990]

What docs were you trying to follow when you got this message? It seems more helpful to update the docs then start outputting new warnings all over the place that will in general just add more noise. Working against localhost is fairly common even in some production use cases where you are using kubectl proxy to access the leader node directly.

[aphorise]

I do agree that current defaults should be ok especially where things are configured against default addresses / ports - which is what I tend to do too. 😄

There are cases however where environment setters or login scripts fail to set required non-default / loopback address that will then end up being used and failing - perhaps then reminding users of something being wrong.

I think longer term the better experience may be to have some means of pre-checking avaible adaptors and default against each wherever addresses are not set. This may make it more versatile than assuming loop-back on 127.0.0.1; the same logic could also relate to the server and agent the same as CLI. That sort of approach could also better respond or not try anything if there are no avaible adaptors / routes. In any case those thoughts there may be for the future more and separate.

I think issue can help newbies and folks needing specific address to be set with each of their shell sessions.

[mr-fixit]

Agreed, there's always a tension between designing for the newbie and for the experienced. The coaching that one needs is just noise to the other.

@michaeljs1990, you asked, "what docs were you trying to follow when you got this message?"

The company had docs about vault, and those docs also point to Hashicorp's docs. Did I find the answer? Yes, eventually. Was it in any of those docs? I don't remember.

You suggest that the need could be met by improving the docs. That's a good idea too.

[rawwwulea]

the "newbie" is the user. i can't login to my vault. congratulations!