So I think most of the folks on this thread understand how to authenticate - right?
You have:
- OS_USERNAME (and OS_USER_DOMAIN_NAME if it's in the non-default domain)
- OS_PROJECT_NAME (and OS_PROJECT_DOMAIN_NAME if it's in the non-defualt domain)
- OS_DOMAIN_NAME only exists if you want to scope to an entire domain, its an XOR relationship with OS_PROJECT_NAME
I think the issue here that Bjoern is trying to raise is that some of the `openstack` commands are inconsistent with regards to the --domain argument.
In some cases we use --domain, and some cases we use --user-domain and --project-domain.
These really come down to the specific command, for `openstack user list` we can only filter by user domains so we just have it as --domain. Same with `openstack group list --domain x` and `openstack project list --domain x`.
In cases where we need to be specific, like adding a role, we qualify it, for instance:
`openstack role add member --user u --user-domain x --project p --project-domain y`
So I think most of the folks on this thread understand how to authenticate - right?
You have: DOMAIN_ NAME if it's in the non-defualt domain)
- OS_USERNAME (and OS_USER_DOMAIN_NAME if it's in the non-default domain)
- OS_PROJECT_NAME (and OS_PROJECT_
- OS_DOMAIN_NAME only exists if you want to scope to an entire domain, its an XOR relationship with OS_PROJECT_NAME
I think the issue here that Bjoern is trying to raise is that some of the `openstack` commands are inconsistent with regards to the --domain argument.
In some cases we use --domain, and some cases we use --user-domain and --project-domain.
These really come down to the specific command, for `openstack user list` we can only filter by user domains so we just have it as --domain. Same with `openstack group list --domain x` and `openstack project list --domain x`.
In cases where we need to be specific, like adding a role, we qualify it, for instance:
`openstack role add member --user u --user-domain x --project p --project-domain y`
Bjoern, are you suggesting that?