Expose Affinity host on xenorchestra_vm resource

[brd]

Launching VMs using terraform sometimes ends up with multiple of the same VM role on the same host, sometimes it would be nice to pin the VMs to specific hosts.

What do you think about exposing the 'affinity host' config option from the advanced tab?

[ddelnano]

There are lots of features that the xenorchestra_vm resource doesn't currently support and adding affinity host is definitely one of those things. This is absolutely something that should be possible from terraform.

[ddelnano]

@brd I have the support for this implemented in #110

However, there is still one aspect that needs work, how the affinity_host value is determined. I was thinking that could be provided by a new data source for hosts as described below.

data "xenorchestra_host" "host" {
  name_label = "R620-2"
}

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

Can you tell me how these affinity hosts are usually identified in your deployment? Would a data source like I've described work for your use case?

[brd]

@ddelnano Wow, thanks for your work on this!

I think for me, I would like to see it be something we could leverage count with, so if I have something like:

module "host" {
  source = "./modules/freebsd-12"

  count = 3
  hostname = "host${count.index}"
  ram_gb = 2
  cpus = 1
  disk_gb = 20
  affinity_host = "xen${count.index}"
}

That would result in 3 VMs called: host0, host1, host2 respectively on xen0, xen1, xen2.

[gohumble]

Hello @ddelnano,

yesterday I faced a similar issue. I wanted to set the affinity_host to a value other than the master of a pool.

I created a new host data source, that's able to fetch all hosts in a specific pool. The datasource will return a map of {"hostname":"host_uuid"}. Therefore, you can set the affinity_host value by providing a hostname to your terraform configuration.

Currently, i need to add some tests for this. If you want, i can open a PR for you to review that.

[ddelnano]

@gohumble thanks for putting effort into that! Please open a PR and I'm happy to help in any way to get your change ready to merge.

[ddelnano]

@brd would the following work for your use case (this was cross posted from #120)? affinity_host needs to be a XAPI id (and not a name_label or whatever your pseudo code was using). However, I think if we could have a data source that returns multiple hosts, has the ability to filter them by tag, name_label or other attributes and has the ability to sort that it could solve the problem you are trying to.

Can you confirm if something like this would achieve what you are looking for?

data "xenorchestra_hosts" "hosts" {
  pool_id = data.xenorchestra_pool.pool.id

  # This assumes that hosts would have a name_label that matches the count.index used below
  sort_by = "name_label"
  sort_order = "asc"

  # Optionally filter by tags if needed
  tags = [
    "tag1",
    "tag2",
  ]
}

# Assuming that the name_labels are named appropriately you could hopefully do something like this 
module "host" {
  source = "./modules/freebsd-12"

  count = 3
  hostname = "host${count.index}"
  ram_gb = 2
  cpus = 1
  disk_gb = 20
  affinity_host = data.xenorchestra_hosts.hosts[count.index].id
}

[brd]

@ddelnano I think that would work, but if you do an apply run with -target set, would that mess up where the machines land by sort order? It should not affect the count order I don't think, but maybe that would be a problem too.

Sometimes I use -target on single machines as a way to upgrade individual machines one at a time so I don't take all the webservers offline at once after updating the xenorchestra_template to a new version of the image.

[ddelnano]

@ddelnano I think that would work, but if you do an apply run with -target set, would that mess up where the machines land by sort order? It should not affect the count order I don't think, but maybe that would be a problem too.

I can't say I've used -target much but I'm pretty confident that it doesn't impact how terraform plans. I'll make sure to test that but I believe it will work fine.

Since #110 and #120 have been merged I'm going to close this but I will open up a new issue for the xenorchestra_hosts data source.