Comment 7 for bug 1317293

(chat with Steven Hardy) - looks like we need to do some work in heat to fix this.

<shardy> basically you want to get a token, scoped to a trust, then pass that token around and have it reused as opposed to getting a new token
 You can check if the token is trust scoped:
 https://github.com/openstack/heat/blob/master/heat/common/heat_keystoneclient.py#L173
<asalkeld> shardy, 4 lines up we are calling authenticate
 what if that is already a trust token
<shardy> You mean in _v3_client_init?
<shardy> In heat that never happens, because we only ever consume a trust with username/password
 if you have a context which already contains a trust scoped token, that may be the issue
<asalkeld> shardy, but i am using heat with a trust token
<shardy> Ok that is the problem
<shardy> you need chained delegation, which last time I looked was not implemented in keystone
<asalkeld> ga
<shardy> https://blueprints.launchpad.net/keystone/+spec/trusts-chained-delegation
 hmm, that says implemented
<shardy> https://review.openstack.org/#/c/56243/
 Hmm, that patch doesn't implement what I described in the BP at all :
<asalkeld> so why can't it just happily pass around the trust token?
 (dare I ask)
<shardy> because heat needs to create a trust too, so we can impersonate the user you're already impersonating for deferred operations like autoscaling
 and we can't store the token, because it will expire
<shardy> asalkeld: can you explain the use-case, why do you need to use trusts rather than the user's token in this case?
<asalkeld> so we don't have to store a token that will timeout
<shardy> doh
<asalkeld> this is a git hook triggered action
<asalkeld> and we want to kick off a heat update
<shardy> Hmm, so in that case, can you do the intitial stack create with a normal token, and just the stack update with a trust scoped one?
<asalkeld> shardy, that's what we do
<shardy> asalkeld: Ok, we can probably fix it in heat then
<asalkeld> what do I need to do?
<shardy> if we just use the existing trust-scoped token it should work
 which I think is what you said above, but I misunderstood you
<asalkeld> so I have my trust scoped token and heat needs to figure out to then use it's trust scoped token
<shardy> asalkeld: maybe reversing the if self.context.trust_id and elif self.context.auth_token would be enough
<shardy> I seem to recall there was a reason for that ordering but I can't quite remember what
* shardy will need to do some testing
<asalkeld> shardy, i am happy to do the work if you can give some guidance
<shardy> the times when we set the trust_id in the context should be when we start with an empty context, so I *think* we should be able to let the token take precedence
 we'll need to ensure there's nowhere where we just set the trust_id on the request context though