Feature/guest ip

[mborodin]

This PR solves #13 Example is here: https://github.com/mborodin/terraform-provider-xenserver/blob/de52ec6f2adb8ad48cef555d0d6c48e24cef2d9e/examples/datasource_vm_guest_metrics/main.tf

[ringods]

@mborodin can you also add docs for the new datasource? You can add it in this folder:

https://github.com/ringods/terraform-provider-xenserver/tree/master/website/docs/d

If you don't have that folder, please rebase from master.

[mborodin]

@ringods done

[ringods]

@mborodin can you rebase from master? I fixed the .travis.yml file to not set up the golang cookie for pull requests.

[zzzuzik]

could this be merged please?

[dot1q]

I have noticed that the startup_delay isn't working and when

data "xenserver_vm_networks" "new_interfaces" {
  vm_uuid = "${xenserver_vm.vm1.id}"
  startup_delay = 80
}

executes before the VM has fully booted up and the tools have connected, which breaks the execution

The following error is returned

* data.xenserver_vm_networks.new_interfaces: data.xenserver_vm_networks.new_interfaces: API Error: HANDLE_INVALID VM_guest_metrics OpaqueRef:NULL

[ringods]

@mborodin I have finally found the time to review this PR. I am not so fond of the datasource name vm_guest_metrics. I know that the XAPI has different objects for:

• VM
• VM_metrics
• VM_guest_metrics

But from a Terraform viewpoint, I rather would like to know all of this info from a single datasource xenserver_vm, with the same info also offered by the resource xenserver_vm.

What's your idea on renaming the datasource?

Also, could you rebase from master one last time? I merged a few other PRs last weekend.

[debovema]

@mborodin @ringods : any update on this one ?

[ringods]

@debovema I was still trying to discuss the datasource/resource naming with @mborodin. I would like to stick to creation of resources on the Terraform side. This pull request also exposes metrics which should be more for a monitoring tool, less for the terraform provider.

[debovema]

I agree, IP address of VM should be available as an attribute of the VM resource instead of only as a datasource. Otherwise it is not possible to use these IPs correctly in a count meta-parameter of other resources.

I submitted #38 which is the same as this one (#24) but rebased from master. You can ignore it if it is not needed.