XO-Server api doesn't allow empty string params

[josuemotte]

Hello,

This commit from xen-orchestra project is breaking TF provider for VM creation, https://github.com/vatesfr/xen-orchestra/commit/d6a3492e90d9ae6135cd43510ce963d08bcf3b8c

From TF point of view no issue, but on xen-orchestra, created VMs will not start and report this error :

vm.start
{
  "id": "833f68c2-a8b9-6682-4f17-94ad98dec153",
  "bypassMacAddressesCheck": false,
  "force": false
}
{
  "code": "HANDLE_INVALID",
  "params": [
    "host",
    "OpaqueRef:171c29cc-17c4-43ae-8fdb-1f0c40b49293"
  ],
  "call": {
    "method": "VM.start",
    "params": [
      "OpaqueRef:f114762a-5507-421c-873d-3725fad083d2",
      false,
      false
    ]
  },
  "message": "HANDLE_INVALID(host, OpaqueRef:171c29cc-17c4-43ae-8fdb-1f0c40b49293)",
  "name": "XapiError",
  "stack": "XapiError: HANDLE_INVALID(host, OpaqueRef:171c29cc-17c4-43ae-8fdb-1f0c40b49293)
    at Function.wrap (/opt/xo/xo-builds/xen-orchestra-202303222329/packages/xen-api/src/_XapiError.js:16:12)
    at /opt/xo/xo-builds/xen-orchestra-202303222329/packages/xen-api/src/transports/json-rpc.js:35:21
    at runNextTicks (node:internal/process/task_queues:60:5)
    at processImmediate (node:internal/timers:447:9)
    at process.callbackTrampoline (node:internal/async_hooks:130:17)"
}

I already open an issue there but I guess there might be others functionalities broken now, if you want to follow the issue : https://github.com/vatesfr/xen-orchestra/issues/6748

Cheers

[josuemotte]

after more testing, the issue seems to be related to the argument : affinity_host of the resource xenorchestra_vm, if the value is not correct you won't receive any error just a broken VM.

The argument was previously optional but since https://github.com/vatesfr/xen-orchestra/commit/d6a3492e90d9ae6135cd43510ce963d08bcf3b8c it is now mandatory.

[ddelnano]

@josuemotte thanks for reporting this. I've been meaning to get CI setup for the provider so issues like this get caught sooner.

I'm not sure that I follow why the validation added in https://github.com/vatesfr/xen-orchestra/commit/d6a3492e90d9ae6135cd43510ce963d08bcf3b8c causes this breakage. I understand how that change relates to #235 though (empty string mac address values are now rejected).

As for the issue with affinity_host, the terraform provider could validate that the string is a valid host id. Alternatively, could you use a host data source to lookup the host you want and use its attributes as an input to the vm resource (untested example below)?

data "xenorchestra_host" "host" {
 [ ... ]
}

resource "xenorchestra_vm" "vm" {
  affinity_host = data.xenorchestra_host.host.id
}

[ddelnano]

The empty string validation failures related to mac addresses are fixed in v0.24.1 (will be available on the terraform registry in the next 30 mins).

[josuemotte]

Hi,

Indeed using data is working fine.

[ddelnano]

Given that I'm going to close this issue since the mac address bug is fixed in v0.24.1 and using the xenorchestra_host data source will surface an invalid afffinity_host parameter before vm creation is even attempted.

Happy to discuss other ideas if you feel that doesn't sufficiently address the situation.

[marlluslustosa]

until the problem is solved, use this block below as an example and then the VM will get host affinty from the master pool. I'm using this and it works well as a palliative.

virt_resources = {
  pool        = "Pool_name"
...
}

data "xenorchestra_pool" "POOL" {
  name_label = var.virt_resources.pool  
}

data "xenorchestra_hosts" "pool_hosts" {
  pool_id = data.xenorchestra_pool.POOL.id  
}

resource "xenorchestra_vm" "VM" {
...
  affinity_host = data.xenorchestra_hosts.pool_hosts.master
}