On Mon, Apr 28, 2014 at 2:48 PM, Clint Byrum <[email protected]> wrote:
> 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 <[email protected]> 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. > I'd like to understand your notion of an "overly complicated user experience" better... power users want the ability to shoot themselves in the foot, and new users want a simplified experience that doesn't require any thought beyond copy/pasting, as they still need to focus on the big picture. In this specific instance, the power-user solution is to offer both configuration options, whereas Stephen has weighed the pros and cons and determined that the reliable copy/paste experience with IDs is the safest solution. If there's a reliable middleground we're not considering, I'd be interested to hear about it. > > 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 > > Sure: domain names are unambiguous but user mutable, whereas Heat's approach to using admin tenant "name" is at risk to both mutability and ambiguity (in a multi-domain deployment). > If it has to be a different config option, that is fine, as long as > they're not both required. ++ It should be domain name XOR domain ID, given that domain names are unambiguous. > 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. > And Stephen explained his reasoning for this approach quite well. > > Also, names are unambiguous. Domain* names are unambiguous, as are role names (at the moment). User, group and project names are ambiguous in a multi-domain context. > 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. > They are unique enough for reliable lookups. > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
