Open Stack

On Mon, Jul 07, 2014 at 02:13:57AM -0400, Eoghan Glynn wrote:
> 
> 
> > In current Alarm implementation, Ceilometer will send back Heat an
> > 'alarm' using the pre-signed URL (or other channel under development).
> 
> By the other channel, do you mean the trusts-based interaction?
> 
> We discussed this at the mid-cycle in Paris last week, and it turns out
> there appear to be a few restrictions on trusts that limit the usability
> of this keystone feature, specifically:
> 
>  * no support for cross-domain delegation of privilege (important as
>    the frontend stack user and the ceilometer service user are often
>    in different domains) 

I'm not aware of any such limitation, can you provide links?

FWIW I just did a quick test, and it seems that with impersonation enabled
you can delegate between users in different domains fine, which is good,
because heat will need that to support stack-owners in non-default domains.

>  * no support for creating a trust based on username+domain as opposed
>    to user UUID (the former may be predictable at the time of config
>    file generation, whereas the latter is less likely to be so)

I don't think this is an issue, provided the trust is created inside the
service which consumes it.  You already have all the ID's you need in the
request context, so the only ID you have to obtain is that of the service
user for your service (which is easily obtainable, because you have all the
credentials associated with the service user, so even if you don't put the
ID in the config file, you can easily obtain it, e.g via getting a token).

>  * no support for cascading delegation (i.e. no creation of trusts from
>    trusts)

This is true, I've proposed a spec, and plan to have a crack at
implementing it soon.  This will be required for Solum->Heat->Ceilometer
chained delegation to work.

https://review.openstack.org/#/c/99908/

The "simple" alarm creation would still work without this however, the
problem would be alarms created via deferred operations (from solum or as
part of autoscaling nested stacks inside heat).

> If these shortcomings are confirmed by the domain experts on the keystone
> team, we're not likely to invest further time in trusts until some of these
> issues are addressed on the keystone side.

As mentioned above, AFAIK the only outstanding issue is the lack of chained
delegation, the other stuff, I believe, works or can be worked-around,
provided the trust is created inside ceilometer (e.g not by heat where it
would need to know the ceilometer service user ID).

Steve