Open Stack

On Mon, Apr 28, 2014 at 2:48 PM, Clint Byrum <clint at fewbar.com> 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 <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.
> >
>
> 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
> 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/b22af319/attachment.html>