[blazar] Why/how does Blazar use Keystone trusts?

Sylvain Bauza sbauza at redhat.com
Wed Nov 13 08:25:31 UTC 2019


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 at 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*
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20191113/104bcd6b/attachment.html>


More information about the openstack-discuss mailing list