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. > 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 > [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
