Open Stack

Excerpts from Dolph Mathews's message of 2014-04-28 12:28:41 -0700:
> On Mon, Apr 28, 2014 at 12:51 PM, Clint Byrum <clint at fewbar.com> wrote:
> 
> > So in the process of making Heat deploy itself, I've run into a bit of a
> > deadlock.
> >
> > https://bugs.launchpad.net/tripleo/+bug/1287453
> > https://bugs.launchpad.net/heat/+bug/1313003
> >
> > Currently, we deploy OpenStack like this:
> >
> > * First we generate usernames/passwords for all service accounts
> > * Next we deploy Keystone and Heat (and.. the rest of OpenStack)
> >   - In this process, we feed in the usernames and passwords we
> >     generated.
> > * Then when everything is "deployed", we initialize Keystone with the
> >   generated usernames and passwords via the keystone API.
> > * Now we test to make sure what we deployed works.
> >
> > However, in order to create isolated users for narrow access to Heat
> > from inside instances, Heat needs a domain to put these narrowly scoped
> > users in. Heat has a handy script for creating this domain and an admin
> > inside the domain which is needed to create the lesser users. So that
> > naturally fits into our initialization of keystone.
> >
> > The problem is that because of bug 1313003, Heat can only use a domain
> > ID to specify this domain.
> 
> 
> I agree with Stephen's assessment in bug 1313003:
> 
>   https://bugs.launchpad.net/heat/+bug/1313003/comments/1
> 
> It's ultimately a user experience issue (it'd require two config options to
> properly express two different concepts). This issue isn't unique to heat,
> though.
> 
> As Stephen points out, "it's a set-once deployer option (not a user-facing
> one)" - the IDs are intended exactly for this purpose. They're immutable,
> unambiguous identifiers. They're not particularly user-friendly, but as
> Stephen points out, they don't need to be. They just need to be reliable.
> 

In this instance, I, the deployer, am a Heat and Keystone user. So that
is not a valid reason to dismiss this overly complicated user experience.
If it is hard for me in TripleO, and hard for Steven in Heat, then it
will be hard for everybody else who wants to consume keystone domains
via the API.

Could you contrast domains with the way that we can use names for every
other keystone component? Notice:

https://git.openstack.org/cgit/openstack/tripleo-image-elements/tree/elements/heat/os-config-applier/etc/heat/heat.conf#n522

If it has to be a different config option, that is fine, as long as
they're not both required. But this is the only place that we've run
into where we have to put an ID in the configuration for a service,
rather than a name.

Also, names are unambiguous. I requested that name specifically so I
could use it for this purpose. If they're not unique enough to use for
lookups, then I would love to hear an explanation as to why they cannot
be made unique, at least in some context.