OpenStack RC File Auto Sets Conflicting Environment Variables Preventing Use Of Swift Backend

[zkupu]

Terraform Version

$ terraform -v
Terraform v0.11.8-dev

Terraform Configuration Files

terraform {
  backend "swift" {
    container = "terraform-state"
  }
}

Debug Output

$ terraform init
2018/07/30 14:43:03 [INFO] Terraform version: 0.11.8 dev
2018/07/30 14:43:03 [INFO] Go runtime version: go1.10.1
2018/07/30 14:43:03 [INFO] CLI args: []string{"~/go/bin/terraform", "init"}
2018/07/30 14:43:03 [DEBUG] Attempting to open CLI config file:~/.terraformrc
2018/07/30 14:43:03 [DEBUG] File doesn't exist, but doesn't need to. Ignoring.
2018/07/30 14:43:03 [INFO] CLI command args: []string{"init"}
2018/07/30 14:43:03 [DEBUG] command: loading backend config file: ~/terraform

Initializing the backend...
2018/07/30 14:43:03 [DEBUG] plugin: waiting for all plugin processes to complete...

Error configuring the backend "swift": You must provide exactly one of DomainID or DomainName to authenticate by Username

Please update the configuration in your Terraform files to fix this error.
If you'd like to update the configuration interactively without storing
the values in your configuration, run "terraform init".

Expected Behavior

The problem encountered here is related to the environment variables that are set when authenticating for OpenStack via RC file.

The two (2) environment variables that cause this problem to occur are:

OS_PROJECT_DOMAIN_ID
OS_USER_DOMAIN_NAME

These environment variables are set by default when sourcing an OpenStack RC file and in order to prevent the error reported above, you must unset one of them.

I think it would be helpful to have Terraform ignore one of these environment variables, if both are set.

Actual Behavior

Please see DEBUG OUTPUT above for error.

Steps to Reproduce

1. Source an OpenStack.sh RC file
2. terraform init

Additional Context

As mentioned above, this problem only occurs when authenticating for OpenStack via sourcing an RC file.

References

[apparentlymart]

Hi @zkupu! Sorry for this annoying behavior, and thanks for reporting it.

@jtopjian, do you think it's reasonable for this backend to behave similarly to some other backends and handle conflicting credentials with a preference order rather than an error? I'm not sure what is conventional behavior for OpenStack, but comparing with behavior of other backend's I'd expect environment variables, if set, to take priority over credentials in an on-disk file due to them being more "transient".

[jtopjian]

There's a bit of history on this behavior. First and foremost, I apologize because it's most definitely frustrating and not correct.

The short version is that it was an unfortunate mistake that we lumped these environment variables together. I spent a good amount of time this year fixing Gophercloud and then the OpenStack provider to resolve this. The fix landed in April (https://github.com/terraform-providers/terraform-provider-openstack/pull/290) and we have one more pending PR which will handle some edge cases (https://github.com/terraform-providers/terraform-provider-openstack/pull/329).

If you're curious of the detailed version, PR 290 includes links (and subsequent links) to all the work done.

With all of that in mind, the Swift backend should definitely have the same fixes applied to it. I don't use the Swift backend and since it's bundled in the core Terraform repo it's something I easily forget about.

I believe there's another Swift backend PR that is waiting on some vendor updates, but we should be able to update the auth settings separately. I'll look into this shortly.

[apparentlymart]

Thanks, @jtopjian!

[zkupu]

Awesome!! Thank you so much for the "Swift" responses! :D :D

[jtopjian]

Quick update on this: There's a pending terraform-provider-openstack / gophercloud vendoring cleanup happening right now. I tried working around it, but would end up with mixed versions on the vendor dependencies which is exactly what we're trying to resolve in terraform-provider-openstack.

Once that's resolved (which I hope to have done in the next week or two), I'll be able to get this implemented.

[jtopjian]

I've opened #18671 which fixes this.

[mildwonkey]

The linked commit closes this issue.

[ghost]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.