Comment 6 for bug 1613819

The default domain is setup by default as default/Default in devstack.
That can be changed, which is why it's a configuration option.

stack@ubuntu-xenial:~/devstack$ openstack domain list
+----------------------------------+------------+---------+-----------------------------------+
| ID | Name | Enabled | Description |
+----------------------------------+------------+---------+-----------------------------------+
| default | Default | True | The default domain |
| f2ea5fb408784e589457c910591169dc | swift_test | True | Used for swift functional testing |
+----------------------------------+------------+---------+-----------------------------------+

The default_domain_id setting is only used by one test, which checks the existence of a default domain, so it's completely irrelevant in terms of credentials providers:

http://git.openstack.org/cgit/openstack/tempest/tree/tempest/api/identity/admin/v3/test_domains.py#n167

The default domain_id is not necessarily the domain where you want to provision your test accounts, which is why we have different settings for that, namely:

- when using dynamic credentials, the project domain name of the configured admin user (http://git.openstack.org/cgit/openstack/tempest/tree/tempest/common/dynamic_creds.py#n103)

- when using pre-provisioned credentials, the domain specified in the YAML file (it loaded from the YAML file into a Credentials object)

- default_credentials_domain_name: this is used if no domain could be found with the methods above. It's passed to the credential providers and init time (http://git.openstack.org/cgit/openstack/tempest/tree/tempest/common/credentials_factory.py#n44)

- 'Default' if the none of the above worked (http://git.openstack.org/cgit/openstack/tempest/tree/tempest/lib/common/cred_provider.py#n40)

V3 Users are provisioned without a domain ID, which causes keystone to provision them in the 'default' domain. This is wrong because Tempest should honour either the domain name of the admin user or the the default_credentials_domain_name setting.

So this is a bug, but the bug description is a bit misleading.