Open Stack

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.


> We haven't created that domain yet at stack
> creation time though, so we would have to add another step before
> testing/using the cloud:
>
> * Update stack with ID of heat stack user domain.
>
> Steven Hardy has indicated that it was problematic to make use of names
> instead of id's for domains, and that to me signals a problem with the
> API and/or policy model in Keystone around domains.
>
> Everything else in TripleO makes use of names except this, so I think
> we need to solve this. This isn't just a TripleO or Heat problem though,
> anybody using domains will run into the same trouble Steven hit, and
> that is not something we should ignore.
>
> Can somebody more familiar with domains explain what would be needed to
> be able to have Heat able to lookup domains by name and use them like
> most other things in OpenStack, where we can use names or IDs
> interchangeably?


> Thanks!
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140428/b1b40c03/attachment.html>