[tc][all] Project deletion community goal for Train cycle

Lance Bragstad lbragstad at gmail.com
Mon Jan 21 20:30:18 UTC 2019


On Mon, Jan 21, 2019 at 2:18 PM Ed Leafe <ed at leafe.com> wrote:

> On Jan 21, 2019, at 1:55 PM, Lance Bragstad <lbragstad at gmail.com> wrote:
> >
> > Are you referring to the system scope approach detailed on line 38, here
> [0]?
>
> Yes.
>
> > I might be misunderstanding something, but I didn't think keystone was
> going to iterate all available services and call clean-up APIs. I think it
> was just that services would be able to expose an endpoint that cleans up
> resources without a project scoped token (e.g., it would be system scoped
> [1]).
> >
> > [0] https://etherpad.openstack.org/p/community-goal-project-deletion
> > [1]
> https://docs.openstack.org/keystone/latest/admin/tokens-overview.html#system-scoped-tokens
>
> It is more likely that I’m misunderstanding. Reading that etherpad, it
> appeared that it was indeed the goal to have project deletion in Keystone
> cascade to all the services, but I guess I missed line 19.
>
> So if it isn’t Keystone calling this API on all the services, what would
> be the appropriate actor?
>

The actor could still be something like os-purge or adjutant [0]. Depending
on how the implementation shakes out in each service, the implementation in
the actor could be an interation of all services calling the same API for
each one. I guess the benefit is that the actor doesn't need to manage the
deletion order based on the dependencies of the resources (internal or
external to a service).

Adrian, and others, have given this a bunch more thought than I have. So
I'm curious to hear if what I'm saying is in line with how they've
envisioned things. I'm recalling most of this from Berlin.

[0] https://adjutant.readthedocs.io/en/latest/


>
>
> -- Ed Leafe
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190121/3f0f9277/attachment-0001.html>


More information about the openstack-discuss mailing list