> 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).
But then how is it any different from os-purge itself?
> 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.
Understood, I am only saying that John might not be well equipped to drive that, if you can't do it for good reasons, we'd need to figure out who would.
> 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'.
Sorry I wasn't clear: I meant stuff like firewall, vpns, load balancers, unicorns and butterflies that Neutron might not be necessarily aware of. We can delete a router, but if a router's deletion is prevented by a unicorn attached to it, then we gotta figure out a way to delete the unicorn first. Are you with me?
> Naturally :) The script should have a functional test, we can discuss
this in the implementation phase.
Ok, no argument about this.
> I had not considered this. We should discuss this further.
> 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).
But then how is it any different from os-purge itself?
> 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.
Understood, I am only saying that John might not be well equipped to drive that, if you can't do it for good reasons, we'd need to figure out who would.
> 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'.
Sorry I wasn't clear: I meant stuff like firewall, vpns, load balancers, unicorns and butterflies that Neutron might not be necessarily aware of. We can delete a router, but if a router's deletion is prevented by a unicorn attached to it, then we gotta figure out a way to delete the unicorn first. Are you with me?
> Naturally :) The script should have a functional test, we can discuss
this in the implementation phase.
Ok, no argument about this.
> I had not considered this. We should discuss this further.
Let me know if I am talking nonsense.