Comment 13 for bug 1511574
Revision history for this message
| Armando Migliaccio (armando-migliaccio) wrote Re: [RFE] Support cleanup of all resources associated with a given tenant with a single API call | #13 |
Assaf, thanks for the nicely written comment.
So to try, and distill it a bit to ensure we're on the same page. I'd like to say that for the sake of this effort:
* We should not pursue an end-to-end integration strategy: Neutron should provide the ability to purge project resources that is invoked by an external party.
* The smallest unit of cleanup is a project, aka tenant in existing Neutron parlance, rather than domain, users and whatnot.
To your summary:
1) File a cross-project spec.
2) Write the code, expose it via CLI, not API.
3) If 1 succeeds, expose the already merged code via the API.
I see the following open issues:
* If no REST API is going to be provided to start with, the tool must be invoked from the node where a single server is running, no? This sounds pretty limiting to me, but if acceptable, we should make this clear upfront. Not sure what'd gain by not exposing the API since operators would still use this in interim and switching to something different is still going to be painful. The difference in this case is that we'd make their life miserable asking them to ssh into one of boxes, when they could neatly do that from their home laptop connected to the admin url. It's either that, or I am grossly missing something and I am making a fool of myself :)
* We can't expect that the submitter of the purge code neutron side to be the same person that files a cross-project spec. That requires a different set of skills, i.e. we need a seasoned dude like yourself to help champion that through, are you prepared to do the legwork?
* We should be careful about the chain of dependencies between known and unknown (extension) resources, so the framework must be planned to allow for hooks and all.
* Testing: the tool can easily break if we don't test this continuously in that a commit about a dependency change, or a policy rule change, can easily invalidate the dependency chain, and that can prevent the deletion, leading to stale resources. This also bring me to the next point.
* purge is intrinsically an async operation, therefore the API should be task-oriented, where the user can check the operation status, whether it has completed successfully, whether there are some resources still behind etc.
In a nutshell, this is no small feat of engineering and a spec (both for the Neutron design internals) and the user facing API must be pursued.
Thoughts?