On Fri, Nov 14, 2014 at 04:24:17PM -0500, Nir Soffer wrote:
Hi everyone,
the recent JSONRPC discussion and my last work around vdsClient reminded me that since a long time there it was vague plans for a vdsClient overhaul
or at least I haven't ever found a detailed plan :)
Since we have to add jsonrpc support anyway, it could be a good chance to bootstrap a new vdsClient, and incrementally enhance it as needs arises; the old vdsClient will not go away very soon, I guess.
At least, we can to put together a wishlist for a new vdsClient and add it to the wiki.
My one, so far: * client library package: we should have a program-friendly python package to access VDSM, in order * JSON for input: I's like to open logs, grab a line including a command and feed vdsClient with the very same line
Currently we don't see commands json input in the logs, but this can be a good idea (in debug mode).
+1
JSON for output: current vdsClient format replies in a mix of text and json. We need to print the json returned from vdsm as is.
but a pretty-printed output can be useful, too.
I started discussion about it and here is what I was able to gather: - we should start new vdsClient like tool which holds current vdsClient command line interface. - vdsClient should stay as it is and we can extend new client with additional functionality as we need (adding debug mode etc)
Current vdsClient horrible - we need to replace it with something better.
and never look back. it's beyond redemtion.
- The interface is not consistent, trying to convert command line options to xmlrpc call - Error handling is not helpful, showing an error message and then printing help for all verbse, so the error message is hidden above your screen - Help message is not useful, we need only the names of the parameters - We need extended help for specific verb - like "git help commit" - Command output is not consistent and unusable for parsing in scripts We need to print the returned value from vdsm as is, or prety printed.
- there was a suggestion to reuse ovirt-engine-cli ideas and it should use schema to determine the API
Using the schema can be nice to generate help for the commands.
I started a simple jsonrpc client that can be used for testing *now*: http://gerrit.ovirt.org/35181
Example usage:
Calling method without arguements:
# jsonrpc Host.getVMList { "jsonrpc": "2.0", "id": "0e043d83-294a-4d31-b1b6-6dc2f2747494", "result": [ "b3f6fa00-b315-4ad4-8108-f73da817b5c5" ] }
Calling method with arguements:
# jsonrpc VM.getStats '{"vmID": "b3f6fa00-b315-4ad4-8108-f73da817b5c5"}' { "jsonrpc": "2.0", "id": "cefd25a3-6250-4123-8a56-d7047899e19e", "result": [ { "status": "Down", "exitMessage": "Admin shut down from the engine", "vmId": "b3f6fa00-b315-4ad4-8108-f73da817b5c5", "exitReason": 6, "timeOffset": "0", "exitCode": 0 } ] }
Thanks, this looks very nice and ready for contrib, imho. I'd love to see something similar done to make vdscli connect over jsonrpc. When I need to do something less than trivial from the command line, I start python and from vdsm import vdscli s = vdscli.connect() # does a horribly useful heuristic, to connect # to local host over xmlrpc print s.getVMList() I'd like to see vdscli.connect() extended to jsonrpc. This would simplify Bug 1112594 - Use jsonrpc during migration of vms too. Dan.