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.

We would need robust and extensive testing for this, because deletion is
critical, and we need it to work, but also not cause damage in ways it
shouldn't.

And you're right, purge tools purging outside of the scope asked for is
a worry. Our own internal logic actually works by having the triggering
admin user add itself to the project (and ensure no admin role), then
scope a token to just that project, and delete resources form the point
of view of a project user. That way it's kind of like a user deleting
their own resources, and in truth having a nicer way to even do that
(non-admin clearing of project) would be amazing for a lot of people who
don't want to close their account or disable their project, but just
want to delete stray resources and not get charged.

On 23/01/19 4:03 AM, Tobias Urdin wrote:
> Thanks for the thorough feedback Adrian.
>
> My opinion is also that Keystone should not be the actor in executing
> this functionality but somewhere else
> whether that is Adjutant or any other form (application, library, CLI
> etc).
>
> I would also like to bring up the point about knowing if a project is
> "dirty" (it has provisioned resources).
> This is something that I think all business logic would benefit from,
> we've had issue with knowing when
> resources should be deleted, our solution is pretty much look at
> metrics the last X minutes, check if project
> is disabled and compare to business logic that says it should be deleted.
>
> While the above works it kills some of logical points of disabling a
> project since the only thing that knows if
> the project should be deleted or is actually disabled is the business
> logic application that says they clicked the
> deleted button and not disabled.
>
> Most of the functionality you are mentioning is things that the
> ospurge project has been working to implement and the
> maintainer even did a full rewrite which improved the dependency
> arrangement for resource removal.
>
> I think the biggest win for this community goal would be the
> developers of the projects would be available for input regarding
> the project specific code that does purging. There has been some
> really nasty bugs in ospurge in the past that if executed with the admin
> user you would wipe everything and not only that project, which is
> probably a issue that makes people think twice about
> using a purging toolkit at all.
>
> We should carefully consider what parts of ospurge could be reused,
> concept, code or anything in between that could help derive
> what direction we wan't to push this goal.
>
> I'm excited :)
>
> Best regards
> Tobias
>