Let me tell you a story.
Long time ago, in a far far away galaxy, some people wanting to have a way to reserve some compute nodes in OpenStack created a new project that was named "Climate".
Those folks weren't really knowing Keystone but they saw some problem : when the reservation was beginning, the token was expired.

For that specific reason, they tried to see how to fix it and then saw Keystone trusts. They then said "heh, nice" and they started to use it.
After 5 years, nobody really thought whether trusts should still be needed. Maybe the new Blazar team should look at service tokens, rather.

Anyway, just my 2cts.

-Sylvain

On Wed, Nov 13, 2019 at 12:26 AM Jason Anderson <jasonanderson@uchicago.edu> wrote:
Hi Blazar contributors,

We hit an issue today involving trusts in Blazar, where a host couldn't be deleted due to some issue authenticating against the trust associated with the host. We still haven't resolved this issue, but it felt odd to me: why is a trust even involved here?

I have often wondered what the reason is for using trusts in Blazar, as I can't think of anything Blazar is doing that could not be done by the Blazar system user (and in fact, many operations are done via this user... via another trust.) There are also issues where a user leaves a project before their leases have ended; in this case Blazar has difficulty cleaning up because it tries to resurrect a trust that is not tied to a valid user/project relationship.

Does anybody have context on to how trusts are used in Blazar and if they are still necessary? Does it make sense to remove this functionality?

Thank you,

--
Jason Anderson

Chameleon DevOps Lead
Consortium for Advanced Science and Engineering, The University of Chicago
Mathematics & Computer Science Division, Argonne National Laboratory