Closed ddelnano closed 4 years ago
Have you tried using XO 5.51 instead? It should yield additional details on the error per this commit -- https://github.com/vatesfr/xen-orchestra/commit/036b30212ed8ff740a82c38b75475757876bd667
@Danp2 yea the user that reported this issue initially is running 5.51.1. See the linked issue for that detail. It identifies the type
argument.
Seems like type
isn't a valid parameter. Perhaps you should be using filter
instead?
That doesn't work either. I noticed that the command help says to use filter
but it doesn't seem to work.
ddelnano@ddelnano-desktop:~/code/terraform-provider-xenorchestra (master) $ xo-cli --list-commands | grep Objec
...
xo.getAllObjects [filter=<object>] [limit=<number>] [ndjson=<boolean>]
...
ddelnano@ddelnano-desktop:~/code/terraform-provider-xenorchestra (master) $ xo-cli xo.getAllObjects filter=VM
✖ invalid parameters
JsonRpcError: invalid parameters
at Peer._callee$ (/usr/local/lib/node_modules/xo-cli/node_modules/json-rpc-peer/dist/index.js:212:17)
at tryCatch (/usr/local/lib/node_modules/xo-cli/node_modules/regenerator-runtime/runtime.js:62:40)
at Generator.invoke [as _invoke] (/usr/local/lib/node_modules/xo-cli/node_modules/regenerator-runtime/runtime.js:296:22)
at Generator.prototype.(anonymous function) [as next] (/usr/local/lib/node_modules/xo-cli/node_modules/regenerator-runtime/runtime.js:114:21)
at step (/usr/local/lib/node_modules/xo-cli/node_modules/babel-runtime/helpers/asyncToGenerator.js:17:30)
at /usr/local/lib/node_modules/xo-cli/node_modules/babel-runtime/helpers/asyncToGenerator.js:35:14
at new Promise (<anonymous>)
at new F (/usr/local/lib/node_modules/xo-cli/node_modules/core-js/library/modules/_export.js:36:28)
at Peer.<anonymous> (/usr/local/lib/node_modules/xo-cli/node_modules/babel-runtime/helpers/asyncToGenerator.js:14:12)
at Peer.exec (/usr/local/lib/node_modules/xo-cli/node_modules/json-rpc-peer/dist/index.js:256:21)
at Peer.write (/usr/local/lib/node_modules/xo-cli/node_modules/json-rpc-peer/dist/index.js:367:12)
at Xo.<anonymous> (/usr/local/lib/node_modules/xo-cli/node_modules/jsonrpc-websocket-client/dist/index.js:92:12)
at emitOne (events.js:116:13)
at Xo.emit (events.js:211:7)
at WebSocket.<anonymous> (/usr/local/lib/node_modules/xo-cli/node_modules/jsonrpc-websocket-client/dist/websocket-client.js:232:20)
at WebSocket.onMessage (/usr/local/lib/node_modules/xo-cli/node_modules/ws/lib/EventTarget.js:99:16)
You can use --list-objects
which is a helper for this method:
$ xo-cli --list-objects type=VM
@julien-f that works for the xo-cli. But the bug I linked is calling that same json rpc method from golang. How can the terraform providers call that? It doesn’t seem to be the same format object.method
as the other RPC commands
$ xo-cli xo.getAllObjects filter=json:'{ "type": "VM" }'
filter
is a predicate object that will be used to match the objects.
Is that documented somewhere? I realized the mismatch of how I was using the RPC method and the arguments it exposed but it wasn’t clear to me how I was supposed to know that filter is the predicate object you described.
XO API is mostly for internal use, that's why there are no documentation.
But --list-commands
told you that the filter
param is an object
, and the only way to enter non-string values from the CLI is to use the (documented) json:
prefix.
@julien-f that fixed my issue! So it seems I got lucky that a previous lack of input validation was passed through the rpc call. I have updated the provider to use the documented filter
argument. Thanks for the help :)
I have to agree to disagree that just because a tool is "internal" that it means documentation isn't necessary.
Context
An update to xo-server between versions 5.31.2 to 5.50.1 has broken the terraform-provider-xenorchestra. See https://github.com/terra-farm/terraform-provider-xenorchestra/issues/25 for the context. I checked the changelog and I didn't see any deprecation warnings that would indicate this no longer works so this seems like a bug.
Expected behavior
The following command should list all the objects that are of VM type.
Current behavior