<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Apr 28, 2014 at 12:51 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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">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.</blockquote><div><br></div><div>I agree with Stephen's assessment in bug 1313003:</div><div><br></div><div>  <a href="https://bugs.launchpad.net/heat/+bug/1313003/comments/1">https://bugs.launchpad.net/heat/+bug/1313003/comments/1</a></div>

<div><br></div><div>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.</div><div><br></div><div>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.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">We haven't created that domain yet at stack<br>


creation time though, so we would have to add another step before<br>
testing/using the cloud:<br>
<br>
* Update stack with ID of heat stack user domain.<br>
<br>
Steven Hardy has indicated that it was problematic to make use of names<br>
instead of id's for domains, and that to me signals a problem with the<br>
API and/or policy model in Keystone around domains.<br>
<br>
Everything else in TripleO makes use of names except this, so I think<br>
we need to solve this. This isn't just a TripleO or Heat problem though,<br>
anybody using domains will run into the same trouble Steven hit, and<br>
that is not something we should ignore.<br>
<br>
Can somebody more familiar with domains explain what would be needed to<br>
be able to have Heat able to lookup domains by name and use them like<br>
most other things in OpenStack, where we can use names or IDs<br>
interchangeably? </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Thanks!<br>
<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>
</blockquote></div><br></div></div>