xo.getAllObjects rpc call fails to accept the type argument

[ddelnano]

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.

• XO origin: the sources / XO Appliance
• Versions:
  • node: 8.16.1+5
  • npm: 4.6.1
  • xo-server: 5.50.1
  • xo-server-cloud: 0.3.0
  • xo-server-telemetry: 0.2.0
  • xo-server-xoa: 0.1.0
  • xo-web-free: 5.50.3
  • xoa-cli: 0.16.0
  • xoa-updater: 0.21.1

Expected behavior

The following command should list all the objects that are of VM type.

xo-cli --list-objects type=VM

Current behavior

[Danp2]

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

[ddelnano]

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

[Danp2]

Seems like type isn't a valid parameter. Perhaps you should be using filter instead?

[ddelnano]

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)

[julien-f]

You can use --list-objects which is a helper for this method:

$ xo-cli --list-objects type=VM

[ddelnano]

@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

[julien-f]

$ xo-cli xo.getAllObjects filter=json:'{ "type": "VM" }'

filter is a predicate object that will be used to match the objects.

[ddelnano]

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.

[julien-f]

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.

[ddelnano]

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