Open Stack

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.