terraform-provider-openstack: authentication worked in 1.3.0 but fails in 1.4.0

Terraform Version

$ terraform -v
Terraform v0.11.7

Affected Resource(s)

All openstack_ resources and data sources.

Debug Output

Relevant output is:

2018/05/02 14:44:02 [ERROR] root: eval: *terraform.EvalConfigProvider, err: You must provide exactly one of DomainID or DomainName in a Scope with ProjectName
2018/05/02 14:44:02 [ERROR] root: eval: *terraform.EvalSequence, err: You must provide exactly one of DomainID or DomainName in a Scope with ProjectName
2018/05/02 14:44:02 [ERROR] root: eval: *terraform.EvalOpFilter, err: You must provide exactly one of DomainID or DomainName in a Scope with ProjectName
2018/05/02 14:44:02 [ERROR] root: eval: *terraform.EvalSequence, err: You must provide exactly one of DomainID or DomainName in a Scope with ProjectName
2018/05/02 14:44:02 [TRACE] [walkRefresh] Exiting eval tree: provider.openstack

Expected Behavior

v1.4.0 should work with existing configurations that worked with v.1.3.0.

Actual Behavior

WIth v.1.40, auth failed with the error message:

Error: Error refreshing state: 1 error(s) occurred:

* provider.openstack: You must provide exactly one of DomainID or DomainName in a Scope with ProjectName

Important Factoids

This issue can be solved (in our environment) by setting an additional environment variable: OS_PROJECT_DOMAIN_NAME=Default

Note that with v1.3.0, the OS_ vars we had set (and were working) were:

OS_AUTH_URL
OS_USERNAME
OS_PASSWORD
OS_PROJECT_NAME
OS_USER_DOMAIN_NAME

With v.1.4.0, it appears we need to set:

OS_AUTH_URL
OS_USERNAME
OS_PASSWORD
OS_PROJECT_NAME
OS_USER_DOMAIN_NAME
OS_PROJECT_DOMAIN_NAME

About this issue

Original URL
State: closed
Created 6 years ago
Comments: 15 (10 by maintainers)

Most upvoted comments

@posox I see the problem.

I’m quite sure if you do:

OS_IDENTITY_API_VERSION=2.0

It’ll start working again.

This is a bug in the new upstream authentication code. I’ll get this fixed.

We’re going to have a short release cycle for version 1.5, so this will be released within the next 7-10 days.

jtopjian on May 4, 2018

First and foremost, I apologize for the inconvenience this is causing you folks.

The changes made were:

Newly created authentication arguments of user_domain_name, user_domain_id, project_domain_name, and project_domain_id were added. Adding arguments is not a breaking change.
The environment variables which these arguments read from were moved from their original incorrect placement of domain_name and domain_id to the newly created, corrected arguments.

Our analysis was that the only way this change would cause disruption to users is if an incorrect environment variable was being used previously. That environment variable would then be read by a new authentication field and a scoping error would occur. This sounds exactly what is happening here.

This change resolved several bugs being reported for users who were unable to log in using the credentials provided to them by their cloud providers. In fact, this bug was preventing entire public OpenStack clouds from cleanly working with Terraform.

This change was tested across five different clouds by two developers with different forms of authentication and no issues were seen. Of course we realize that there will be edge cases because of this change and we will definitely provide help and troubleshooting for these cases.

My understanding, from what has been provided, is that you folks are hitting an issue where an environment variable is now being set in the new argument and you need to change your auth settings. To that, I absolutely do sympathize. I understand that your workflows have become reliant upon that configuration and this is disruptive.

From reading the provided information, you were previously setting OS_USER_DOMAIN_NAME. While this worked before, it should actually never have worked. The reason it was working before is that OS_USER_DOMAIN_NAME was being squashed, along with other OS_*_DOMAIN_* variables into the default OS_DOMAIN_ID and OS_DOMAIN_NAME settings. This should have never been done in the provider.

The error message you’re getting is correct: you need to provide a domain name or ID (either by setting OS_PROJECT_DOMAIN_NAME or OS_DOMAIN_NAME) when authenticating with a project. OS_USER_DOMAIN_* scopes a user to a domain, not a project to a domain.

After setting OS_PROJECT_DOMAIN_NAME or OS_DOMAIN_NAME, my guess is that you can unset OS_USER_DOMAIN_NAME entirely and still authenticate.

Again, I do understand that this has caused disruption. Please let me know if this analysis is incorrect or if you’d like to continue discussing this.

edit: to clarify this situation in more detail: If you were to revert to 1.3 and only use OS_PROJECT_DOMAIN_NAME (or even OS_DOMAIN_NAME), you would still authenticate correctly. When moving to 1.4 and retain these settings, you would see no impact. It’s really only by coincidence that OS_USER_DOMAIN_NAME had a correct value which allowed the project/domain scoping to work in 1.3 and prior. I’m basing this on the information provided and I might be wrong. Please let me know if I’m wrong here as if there truly is a bug, I’d like to identify and fix it.

jtopjian on May 4, 2018