Comment 14 for bug 1511574

armax said:
> * 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 :)

If the CLI script uses only the Neutron API client as I suggested then it could be used from anywhere the client is installed (That is the reason I suggested it uses the API client and not the plugin layer, I'm sorry if I was not clear).

> * 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?

To be honest it's dangerous for me to commit to something like that, it might end up not happening because of my own time constraints. I mean well, but... I would prefer we define something fairly concrete then have John file the spec (If he is willing). Push comes to shove I'll do it.

> * 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.

Extension top level resources? Can you elaborate? Are you talking about *aaS, or something like QoS? Couldn't we use discovery to see if the Neutron server supports the extension and delete conditionally? I am not sure what you mean by 'hooks'.

> * 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.

Naturally :) The script should have a functional test, we can discuss this in the implementation phase.

> * 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.

I had not considered this. We should discuss this further.