Thank you both for the information. Some comments inline.
On 11/13/19 5:10 AM, Pierre Riteau wrote:
Hi Jason,
As you point out, reliance on trusts causes problems when users are disabled or deleted from Keystone. In the past it even prevented non-admin users from starting leases, see [1] for context.
I believe there are some operations that could still benefit from the use of trusts (or another mechanism to execute actions on behalf of users), such as snapshot in the before_end event. It's possible that with the current code, snapshot end up being owned by the blazar service user. I don't think I've ever used this feature…
That's a good point, I also haven't used that functionality. Though, I can't think of many cases where the system user couldn't just override the image owner on create.
For management of hosts specifically, I don't see why trusts should be needed. I have a WIP patch to remove their use [2] which should fix your issue. IIRC it just needs unit tests fixes, maybe some from Chameleon could help to finish it?
[1] https://bugs.launchpad.net/blazar/+bug/1663204 [2] https://review.opendev.org/#/c/641103/
I did see this original patch. Yes, perhaps we can pick it up and see what to do with it. It does call out that, if trusts are removed, the notification payload would change. This likely is not used in practice, perhaps others on this list can chime in if that is not the case.
On Wed, 13 Nov 2019 at 09:39, Sylvain Bauza sbauza@redhat.com wrote:
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
Thanks for the historical context! Good to know that there aren't any technical blockers from considering simplifying this.
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
Cheers, /Jason