Use shared credentials accross tooling

[envy]

We use ansible and terraform and have a custom inventory script that uses gscloud to create our dynamic inventory for ansible. For this, I have my gridscale auth information in ~/.config/gscloud/config.yaml.

For terraform, I need another file I can source with environment variables with the same auth information as the terraform provider is not reading the config file.

I don't know if the provider uses the gscloud code internally (I suspect it does) so it would be very nice if it could parse the config file so a single source can be used. The AWS provider is doing this and it's a very nice convenience feature.

Things to consider:

• Priority of the config file. Personally, I think it should be lowest priority, so provider block and envrionment variables both overwrite values from the config file.
• What to do when multiple account are in the config file? Maybe a new field for the provider block to specify the name of the account. Or only use the first one.

[nvthongswansea]

@envy the tf provider uses gsclient-go package, so does gscloud. In order to read config from config.yaml which belongs to gscloud, we will need to code that part separately. It's still a nice-to-have feature. I and @bkircher will consider it. Thanks!

[bkircher]

Yes, I like that idea, too. It would enable me to set things up just once and not all over the place. Especially if you work on multiple projects on different API end-points simultaneously. Fun fact, a year ago we started with this but we didn't follow through because of time constraints and rushing code.

@nvthongswansea I think this is something that concerns all client applications and tooling, not just Golang-based tooling.

Consider, registry.terraform.io/providers/hashicorp/aws/latest/docs. It is common in AWS-land to have a shared configuration file that is the same for libraries and client applications. Tutorials usually start by setting-up/modifying this file. And a couple of tools , e.g. AWS command line clients just assume it is there, disregard of product.

Priority of the config file. Personally, I think it should be lowest priority, so provider block and envrionment variables both overwrite values from the config file.

+1

What to do when multiple account are in the config file? Maybe a new field for the provider block to specify the name of the account. Or only use the first one.

gscloud already deals with this by saying there is one account, "default", and that one is always selected if nothing else is specified. If default is missing, an errors is shown. We could make TF always chose the "default"?

[nvthongswansea]

Update: PR #176 is open.

[JanLukasGithub]

Should this still be open as a duplicate of #183 (even though technically #183 came later)?