Error: jsonrpc2: code 10 message: invalid parameters

[ghost]

Environment: Terraform v0.12.6 provider.xenorchestra v.0.2.0 XO: xo-server 5.51.1 Xen-Machine: XCP-ng 7.6.0

main.tf:

resource "xenorchestra_vm" "foo" {

  core_os = false
  cpu_cap = 2
  cpu_weight = 2
  cpus = 1
  memory_max = 1073733632
  name_label = "someText"
  name_description = "someText"
  cloud_config = "${xenorchestra_cloud_config.devops.template}"
  template = "someNumericHashValue"
  network {
    network_id = "someNumericHashValue"
  }

  disk {
    sr_id = "someNumericHashValue"
    name_label = "someText"
    size = 32212254720
  }
}

terraform validate: Success! The configuration is valid. terraform plan: Creates an execution plan and is ready to apply terraform apply: Is fine until it asks for confirmation then it will try to create and fails on cmdline

Error: jsonrpc2: code 10 message: invalid parameters

  on main.tf line 8, in resource "xenorchestra_vm" "foo":
   8: resource "xenorchestra_vm" "foo" {

Even with a cloud config set to an empty string (like this cloud_config = "") terraform will run fine until the jsonrpc2 error is thrown.

terraform.log

[ddelnano]

Hi @rschardt2 can you please paste the rest of your terraform code?

[ghost]

Even without the xenorchestra_cloud_config (cloud_config set to an empty string). It will run fine until the jsonrpc2 error is thrown.

provider "xenorchestra" {
  # Must be ws or wss
  url      = "ws://xxx.xxx.xxx.xxx:xxxx" # Or set XOA_URL environment variable
  username = "someText"                  # Or set XOA_USER environment variable
  password = "someText"                  # Or set XOA_PASSWORD environment variable
}

resource "xenorchestra_vm" "foo" {

  core_os = false
  cpu_cap = 2
  cpu_weight = 2
  cpus = 1
  memory_max = 1073733632
  name_label = "someText"
  name_description = "someText"
  cloud_config = "${xenorchestra_cloud_config.devops.template}"
  template = "someNumericHashValue"
  network {
    network_id = "someNumericHashValue"
  }

  disk {
    sr_id = "someNumericHashValue"
    name_label = "someText"
    size = 32212254720
  }
}

resource "xenorchestra_cloud_config" "devops" {
  name = "devops_cloud_config"
  template = <<EOF
#cloud-config
hostname: {name}%
bootcmd:
  - /bin/sh -c 'echo "hello world"'
users:
  - name: barfoo
    gecos: Bar B. Foo
    shell: /bin/bash
    sudo: ALL=(ALL) NOPASSWD:ALL
    lock-passwd: false
    passwd: somePasswordHash
packages:
  - htop
EOF
}

[ddelnano]

So my guess is that the disk sr_id or network_id is incorrect and that is causing the API to return with invalid parameters. Although when I try to reproduce that in the acceptance tests I get a more obvious error.

ddelnano@ddelnano-desktop:~/code/terraform-provider-xenorchestra (master) $ make testacc
TF_ACC=1 go test ./... -v
?       github.com/ddelnano/terraform-provider-xenorchestra     [no test files]
=== RUN   TestGetPIFByDevice
--- PASS: TestGetPIFByDevice (0.60s)
=== RUN   TestGetTemplate
--- PASS: TestGetTemplate (1.20s)
=== RUN   TestThatUnmarshalingWorks
--- PASS: TestThatUnmarshalingWorks (0.00s)
=== RUN   TestUnmarshalingVmObject
--- PASS: TestUnmarshalingVmObject (0.00s)
PASS
ok      github.com/ddelnano/terraform-provider-xenorchestra/client      (cached)
=== RUN   TestAccXenorchestraDataSource_pif
--- PASS: TestAccXenorchestraDataSource_pif (2.34s)
=== RUN   TestAccXenorchestraDataSource_template
--- PASS: TestAccXenorchestraDataSource_template (2.58s)
=== RUN   TestAccXenorchestraCloudConfig_readAfterDelete
--- PASS: TestAccXenorchestraCloudConfig_readAfterDelete (1.21s)
=== RUN   TestAccXenorchestraCloudConfig_create
--- PASS: TestAccXenorchestraCloudConfig_create (0.93s)
=== RUN   TestAccXenorchestraCloudConfig_updateName
--- PASS: TestAccXenorchestraCloudConfig_updateName (1.44s)
=== RUN   TestAccXenorchestraCloudConfig_updateTemplate
--- PASS: TestAccXenorchestraCloudConfig_updateTemplate (1.61s)
=== RUN   TestAccXenorchestraCloudConfig_import
--- PASS: TestAccXenorchestraCloudConfig_import (1.09s)
=== RUN   TestAccXenorchestraVm_create
[DEBUG] VM params map[string]interface {}{"memoryMax":1073733632, "existingDisks":map[string]interface {}{"0":map[string]interface {}{"name_label":"Ubuntu Bionic Beaver 18.04_imavo", "size":32212254720, "$SR":"f469400-4a2b-5624-cf62-61e522e50ea1"}}, "VIFs":[]map[string]string{map[string]string{"network":"d225cf00-36f8-e6d6-6a29-02636d4de56b"}}, "bootAfterCreate":true, "name_label":"Name", "name_description":"description", "template":"2dd0373e-0ed5-7413-a57f-1958d03b698c", "cloudConfig":"template", "coreOs":false, "CPUs":1, "cpuCap":interface {}(nil), "cpuWeight":interface {}(nil)}--- FAIL: TestAccXenorchestraVm_create (3.11s)
    testing.go:569: Step 0 error: errors during apply:

            Error: jsonrpc2: code 1 message: no such object f469400-4a2b-5624-cf62-61e522e50ea1

                      on /tmp/tf-test315550669/main.tf line 16:
                                (source code not available)

FAIL
FAIL    github.com/ddelnano/terraform-provider-xenorchestra/xoa 14.346s
Makefile:22: recipe for target 'testacc' failed
make: *** [testacc] Error 1

So it would help if I could find a way to reproduce this so that we can improve the logging, add test cases, etc.

Can you look at the XOA api logs to see if that gives you anymore useful information or have you tried doing a packet capture to see what API request is returning the invalid params? That would be my next step if I had access to your XOA instance.

[ghost]

Here is the log from my xo-instance 2019-11-18T08_59_33.339Z - XO.log

And I got this response via websocket traffic interception between xo and my host: websocket_xo_response.txt

Its odd that the second part of the error msg isn't send. Maybe it is an internal error of the jsonrpc2-library?

I can confirm that my ressource-ids match the populated ressouces. Also there is enough space to create the vm.

[ddelnano]

@rschardt2 it seems that your XOA server doesn't support xo.getAllObjects? Atleast that's what the logs lead me to believe. The terraform provider calls that rpc method and provides a type field to filter the results.

Can you try installing the xo-cli and see if you can run the following?

xo-cli xo.getAllObjects --type=VM

I either think this is related to your XO version or something with your XCP version (I'm using Xenserver).

[ddelnano]

I upgraded from xo-server 5.31.2 to 5.50.1 and now I see the same failures you are seeing. So this was a breaking change in xo-server. I checked the changelog and didn't see anything related to this. I have opened an issue here.

[ddelnano]

It seems I was using the xo.getAllObjects rpc method with incorrect arguments. It wasn't until some type of validation was added to where this stopped working. I have a fix at #26

[ddelnano]

@rschardt2 I'm pretty confident I understand the failure of this since I was able to reproduce it. Please install the 0.3.0 version of the terraform provider and see if it works. Reopen this issue if this is still a problem.