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 _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
