stack_user_domain should accept a domain name

[Clint Byrum]

When configuring heat, stack_user_domain must be a domain ID only. However, it will make more sense to users if they can specify a name.

[Steven Hardy (shardy)]

FWIW I decided against doing this when initially implementing, because the keystoneclient interfaces expect either name or ID, and we'd have to have conditional logic to pass the appropriate kwarg, and/or introduce two config file options (as there's no reliable way of deducing whether the stack_user_domain provided by the user is a name or ID)

The other potential issue is sometimes if you pass a name not ID to keystoneclient, it introduces additional policy requirements, e.g doing this may mean that all users need permission to list all domains. So we'll have to test to ensure that's not the case.

Overall, since it's a set-once deployer option (not a user-facing one) it seemed easier and safer to just use the ID consistently.

[Clint Byrum (clint-fewbar)]

So it sounds like keystoneclient has a bug preventing users from making effective use of domain names. It also seems like a bug in keystone's policy model that you can't lookup a single name that you know without also being allowed to list. Unix has had this solved for 40 years now, as you can have 'x' in a directory without 'r'. :-P

If heat always require an ID for this, then in my deployment system, I always have to communicate the ID to Heat after creating the domain. That is actually problematic for a Heat based deployment of Heat. Because we have to return to the stack after we setup keystone for heat and update the parameters to complete Heat's configuration. This isn't solvable just by templates as they are today, because we can't to API calls to the just-deployed keystone from a template that deployed it, since that template is only able to express things in the cloud underneath us.

However, if I can just input a name, then Heat can simply retry until the name exists.

Since this crosses Keystone, and Heat, I'll post a summary to the mailing list and see if we can get some consensus on a way forward for this.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/99225

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/99225
Committed: https://git.openstack.org/cgit/openstack/heat/commit/?id=7354e68bde32d2829038a573705dcb3cddf95455
Submitter: Jenkins
Branch: master

commit 7354e68bde32d2829038a573705dcb3cddf95455
Author: Morgan Fainberg <email address hidden>
Date: Tue Jun 10 15:32:10 2014 -0700

    Support using domain_name instead of domain_id

    When using keystoneclient (heat.common.heat_keystoneclient) to
    perform actions, support the use of domain_name instead of
    exclusively domain_id.

    The new config option to use domain_name instead of domain_id
    is ``stack_user_domain_name``. If ``stack_user_domain_id`` option
    is set (renamed from ``stack_user_domain``), the new
    domain_name-specific option will be ignored.

    Change-Id: I0d3937a98b95100ccaaaf7a46d3ed722aba27de3
    Closes-Bug: #1313003