© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
e3ace39
(Get the code!)
Hi all, I implemented the workaround for this in heat, which does use trusts. I'm very happy to discuss how we did that, and potentially to help fix this bug (we can perhaps reuse some of the code).
The basic approach is:
1. User creates a heat stack, heat creates a trust delegating the users roles to the heat service user
2. Inside heat we have a wrapper around the current token, and each time it's accessed we check the token expiry time
3. If the token is about to expire, we create another token, with the trust, so we're impersonating the user and have a new token where we can act on their behalf.
I discussed it with the keystone team, and was advised that this is a valid use of Trusts, and it works well.
Here is the code:
Creating the trust:
https:/
Checking for token expiry:
https:/
Forcing a new token:
https:/
As you can see, we wrap some of the keystone session/plugin logic in the context, which is convenient as it enables it to be easily shared with the various openstack clients (which are also wrapped in a plugin interface) heat needs. I think the mistral requirements are similar here, but I've not yet looked at the code to see how similar your client usage is.
If you're open to some patches, I'm happy to take a closer look and/or discuss further (shardy on IRC), thanks!