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 <cl...@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. _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev