<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Apr 28, 2014 at 2:48 PM, Clint Byrum <span dir="ltr"><<a href="mailto:clint@fewbar.com" target="_blank">clint@fewbar.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Excerpts from Dolph Mathews's message of 2014-04-28 12:28:41 -0700:<br>
<div><div class="h5">> On Mon, Apr 28, 2014 at 12:51 PM, Clint Byrum <<a href="mailto:clint@fewbar.com">clint@fewbar.com</a>> wrote:<br>
><br>
> > So in the process of making Heat deploy itself, I've run into a bit of a<br>
> > deadlock.<br>
> ><br>
> > <a href="https://bugs.launchpad.net/tripleo/+bug/1287453" target="_blank">https://bugs.launchpad.net/tripleo/+bug/1287453</a><br>
> > <a href="https://bugs.launchpad.net/heat/+bug/1313003" target="_blank">https://bugs.launchpad.net/heat/+bug/1313003</a><br>
> ><br>
> > Currently, we deploy OpenStack like this:<br>
> ><br>
> > * First we generate usernames/passwords for all service accounts<br>
> > * Next we deploy Keystone and Heat (and.. the rest of OpenStack)<br>
> > - In this process, we feed in the usernames and passwords we<br>
> > generated.<br>
> > * Then when everything is "deployed", we initialize Keystone with the<br>
> > generated usernames and passwords via the keystone API.<br>
> > * Now we test to make sure what we deployed works.<br>
> ><br>
> > However, in order to create isolated users for narrow access to Heat<br>
> > from inside instances, Heat needs a domain to put these narrowly scoped<br>
> > users in. Heat has a handy script for creating this domain and an admin<br>
> > inside the domain which is needed to create the lesser users. So that<br>
> > naturally fits into our initialization of keystone.<br>
> ><br>
> > The problem is that because of bug 1313003, Heat can only use a domain<br>
> > ID to specify this domain.<br>
><br>
><br>
> I agree with Stephen's assessment in bug 1313003:<br>
><br>
> <a href="https://bugs.launchpad.net/heat/+bug/1313003/comments/1" target="_blank">https://bugs.launchpad.net/heat/+bug/1313003/comments/1</a><br>
><br>
> It's ultimately a user experience issue (it'd require two config options to<br>
> properly express two different concepts). This issue isn't unique to heat,<br>
> though.<br>
><br>
> As Stephen points out, "it's a set-once deployer option (not a user-facing<br>
> one)" - the IDs are intended exactly for this purpose. They're immutable,<br>
> unambiguous identifiers. They're not particularly user-friendly, but as<br>
> Stephen points out, they don't need to be. They just need to be reliable.<br>
><br>
<br>
</div></div>In this instance, I, the deployer, am a Heat and Keystone user. So that<br>
is not a valid reason to dismiss this overly complicated user experience.<br>
If it is hard for me in TripleO, and hard for Steven in Heat, then it<br>
will be hard for everybody else who wants to consume keystone domains<br>
via the API.<br></blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Could you contrast domains with the way that we can use names for every<br>
other keystone component? Notice:<br>
<br>
<a href="https://git.openstack.org/cgit/openstack/tripleo-image-elements/tree/elements/heat/os-config-applier/etc/heat/heat.conf#n522" target="_blank">https://git.openstack.org/cgit/openstack/tripleo-image-elements/tree/elements/heat/os-config-applier/etc/heat/heat.conf#n522</a><br>
<br></blockquote><div><br></div><div>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).</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
If it has to be a different config option, that is fine, as long as<br>
they're not both required.</blockquote><div><br></div><div>++ It should be domain name XOR domain ID, given that domain names are unambiguous.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
But this is the only place that we've run<br>
into where we have to put an ID in the configuration for a service,<br>
rather than a name.<br></blockquote><div><br></div><div>And Stephen explained his reasoning for this approach quite well.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Also, names are unambiguous.</blockquote><div><br></div><div>Domain* names are unambiguous, as are role names (at the moment). User, group and project names are ambiguous in a multi-domain context.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I requested that name specifically so I<br>
could use it for this purpose. If they're not unique enough to use for<br>
lookups, then I would love to hear an explanation as to why they cannot<br>
be made unique, at least in some context.<br></blockquote><div><br></div><div>They are unique enough for reliable lookups.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>