Open Stack

Hi Adrian,

This is a great goal that I look forward to seeing in OpenStack.

I don't have an opinion on where the code lives or if it is a plugin
model. Either way should work fine for us.

I do have two questions that I hope we can address early on though:

1. Should the service implement an API endpoint that does the business
logic/workflow or is it expected that the common code will somehow
encapsulate that?  For example, Octavia currently implements "cascade
delete" where you can ask it to delete all of the resources for a load
balancer. I expect we need a layer over this that will iterate across
the load balancers owned by a project. We could implement that in our
API, or we could expect the "common" code to address that. It might be
best to leave this to the service plugin, as in the case of Octavia,
these deletes can be done in parallel, but that might not be the case
for all services.
2. How are we going to handle objects that are in an immutable state?
For example, in Octavia if another user is performing an action on one
of the load balancers, that object is in an immutable "PENDING_UPDATE"
state until the action completes. This means executing a delete on it
would return a 409 conflict from the API.  I think we should decide if
this "global cleanup" should retry the delete and/or in the end just
make note of the issue and continue. If the service is handling the
cleanup, I could see Octavia retrying for a period of time and then
noting that it was unable to cleanup an object should it remain locked
by the controller for too long.

Michael

On Sun, Mar 10, 2019 at 11:21 PM Monty Taylor <mordred at inaugust.com> wrote:
>
>
>
> On 3/11/19 5:05 AM, Adrian Turjak wrote:
> > Hello OpenStackers!
> >
> > As has been mentioned a few times on the mailing list, one of the
> > current community goal proposals is a new library/tool for cleaning up
> > all the resources for a given project in an OpenStack cloud. For a long
> > time we've lacked something like this, and it has made cleaning up a
> > project and deleting it a pain, specifically because of the various
> > dependencies around resources.
> >
> > The goal is now up for review: https://review.openstack.org/#/c/639010
> >
> > The discussion right now is around the version originally proposed and
> > discussed at the last Summit, a plugin based solution with a central
> > library. We are also looking at an alternative which would be a single
> > library like the SDK, or potentially even including the deletion login
> > in the SDK itself, and the CLI part in the OpenStackClient.
> >
> > In all likelihood the single library approach will end up chosen, and
> > I'll have a new written version of the goal up soon for that. If you
> > have feedback against that you should voice it now! Are there any
> > arguments for or against a plugin based solution we haven't heard yet?
> >
> > Additionally we would like feedback (specifically from the SDK team) if
> > they think we should keep this as a standalone library that uses the
> > SDK, or make it part of the SDK.
>
> I think it would be perfectly welcome in the SDK. It seems like exactly
> the sort of business logic type thing that would be quite at home in the
> cloud layer.
>
> > We also need additional developers willing to contribute their time to
> > this goal. Ideally we want every service to have some say in the code to
> > clean up their resources, so I would highly suggest each new PTL works
> > with their team to see who wants to help us make sure they are
> > represented in this goal.
> >
> > Let's actually make this goal a reality! Put your hand up for wanting to
> > contribute review time, and code!
> >
> > Cheers,
> > Adrian
> >
> >
> >
>