Open Stack

Excerpts from Dolph Mathews's message of 2013-09-03 16:12:00 -0700:
> On Tue, Sep 3, 2013 at 5:52 PM, Steven Hardy <shardy at redhat.com> wrote:
> 
> > Hi,
> >
> > I have a question for the keystone folks re the expected behavior when
> > deleting a trust.
> >
> > Is it expected that you can only ever delete a trust as the user who
> > created it, and that you can *not* delete the trust when impersonating that
> > user using a token obtained via that trust?
> >
> 
> We have some tests in keystone somewhat related to this scenario, but
> nothing that asserts that specific behavior-
> 
> https://github.com/openstack/keystone/blob/master/keystone/tests/test_auth.py#L737-L763
> 
> > The reason for this question, is for the Heat use-case, this may represent
> > a significant operational limitation, since it implies that the user who
> > creates the stack is the only one who can ever delete it.
> >
> 
> I don't follow this implication-- can you explain further? I don't see how
> the limitation above (if it exists) would impact this behavior or be a
> blocker for the design below.
> 

The way heatclient works right now, it will obtain a trust from
keystone, and then give that trust to Heat to use while it is managing
the stack. However, if this user was just one user in a team of users
who manage that stack, then when the stack is deleted, neither heat,
nor the user who is deleting the stack will be able to delete the trust
that was given to Heat.

This presents an operational hurdle for Heat users, as they will have to
have a stack "owner" user that is shared amongst a team. Otherwise they
may be stuck in a situation where the creating user is not available to
delete a stack that must be deleted for some reason.

Ideally as a final operation with the trust Heat, or the user doing the
delete, would be able to use the trust to delete itself.