For situations where the default network-based discovery is inappropriate
or inconvenient, this allows users to provide a hard-coded discovery
document for a particular hostname in the CLI config.
This is a new config block, rather than combined with the existing
"credentials" block, because credentials should ideally live in separate
files from other config so that they can be managed more carefully.
However, this new "host" block _is_ designed to have room for additional
host-specific configuration _other than_ credentials in future, which
might include TLS certificate overrides or other such things used during
the discovery step.
Previously we handled all of the config sources directly within the main
function. We're going to make CLI config loading more complex shortly, so
having this encapsulated in its own function will avoid creating even more
clutter inside the main function.
Along the way here we also switch from using native Go "error" to using
tfdiags.Diagnostics, so that we can potentially issue warnings here too
in future, and so that we can return multiple errors.
We require that each "credentials" block has a valid hostname and that
there be no more than one "credentials_helper" block.
There are some more sophisticated validations we could do here, such as
checking if the same host is declared more than once, but since this
config handling will be rewritten to use HCL2 in the near future, and this
sort of check is easier to do in the HCL2 API, we just check the basic
stuff for now and plan to revisit later.
This allows the use case where installation of a plugin can simply say
to add `$GOPATH/bin/foo` to your terraformrc and the user can do that
verbatim. Additionally terraformrc files become portable for certain
environments which are self-contained.
I was hesitant at first about this because it diverges the syntax a bit
from our standard interpolation syntax. However, due to the special
nature of terraformrc and the strong use cases cited I'm okay with this.
Martin Atkins