[tc][all] Project deletion community goal for Train cycle
Jean-Philippe Evrard
jean-philippe at evrard.me
Wed Feb 6 10:11:42 UTC 2019
On Wed, 2019-01-30 at 15:28 +0900, Ghanshyam Mann wrote:
> ---- On Wed, 23 Jan 2019 08:21:27 +0900 Adrian Turjak <
> adriant at catalyst.net.nz> wrote ----
> > Thanks for the input! I'm willing to bet there are many people
> excited
> > about this goal, or will be when they realise it exists!
> >
> > The 'dirty' state I think would be solved with a report API in
> each
> > service (tell me everything a given project has resource wise).
> Such an
> > API would be useful without needing to query each resource list,
> and
> > potentially could be an easy thing to implement to help a purge
> library
> > figure out what to delete. I know right now our method for
> checking if a
> > project is 'dirty' is part of our quota checking scripts, and it
> has to
> > query a lot of APIs per service to build an idea of what a project
> has.
> >
> > As for using existing code, OSPurge could well be a starting
> point, but
> > the major part of this goal has to be that each OpenStack service
> (that
> > creates resources owned by a project) takes ownership of their
> own
> > deletion logic. This is why a top level library for cross project
> logic,
> > with per service plugin libraries is possibly the best approach.
> Each
> > library would follow the same template and abstraction layers (as
> > inherited from the top level library), but how each service
> implements
> > their own deletion is up to them. I would also push for them using
> the
> > SDK only as their point of interaction with the APIs (lets set
> some hard
> > requirements and standards!), because that is the python library
> we
> > should be using going forward. In addition such an approach could
> mean
> > that anyone can write a plugin for the top level library (e.g.
> internal
> > company only services) which will automatically get picked up if
> installed.
>
> +100 for not making keystone as Actor. Leaving purge responsibility
> to service
> side is the best way without any doubt.
>
> Instead of accepting Purge APIs from each service, I am thinking
> we should consider another approach also which can be the plugin-able
> approach.
> Ewe can expose the plugin interface from purge library/tool. Each
> service implements
> the interface with purge functionality(script or command etc).
> On discovery of each service's purge plugin, purge library/tool will
> start the deletion
> in required order etc.
>
> This can give 2 simple benefits
> 1. No need to detect the service availability before requesting them
> to purge the resources.
> I am not sure OSpurge check the availability of services or not. But
> in plugin approach case,
> that will not be required. For example, if Congress is not installed
> in my env then,
> congress's purge plugin will not be discovered so no need to check
> Congress service availability.
>
> 2. purge all resources interface will not be exposed to anyone except
> the Purge library/tool.
> In case of API, we are exposing the interface to user(admin/system
> scopped etc) which can
> delete all the resources of that service which is little security
> issue may be. This can be argued
> with existing delete API but those are per resource not all. Other
> side we can say those can be
> taken care by RBAC but still IMO exposing anything to even
> permissiable user(especially human)
> which can destruct the env is not a good idea where only right usage
> of that interface is something
> else (Purge library/tool in this case).
>
> Plugin-able can also have its cons but Let's first discuss all those
> possibilities.
>
> -gmann
Wasn't it what was proposed in the etherpad? I am a little confused
there.
More information about the openstack-discuss
mailing list