[Feature] Upload isos via terraform

[4censord]

I would like to be able to upload iso via terraform.

I was thinking something like this:

data "xenorchestra_sr" "local_storage" {
  name_label = "Your storage repository label"
}

resource "xenorchestra_iso" "from-file" {
	name_label = "Name-of-the-iso-in-xcp"
	file = "./file.iso"
	sr_id = data.xenorchestra_sr.local_storage.id
}

resource "xenorchestra_iso" "from-url" {
	name_label = "Name-of-the-iso-in-xcp"
	url = "https://host/file.iso"
	checksum = "sha256:abcd..."
	sr_id = data.xenorchestra_sr.local_storage.id
}

I dont currently have time to build this myself, but may look into it in a few months time.

[ddelnano]

@4censord thanks for the feature request. Creating isos already seems to be supported by the XOA api used by the terraform provider, so this shouldn't be too difficult to implement. I'll look into this in the coming weeks.

[4censord]

It seems to now be properly supported by xoa, vatesfr/xen-orchestra#6182 (comment).

I would also like to extend that to importing vm images from remote locations, like upstream cloudinit images, and creating VMS with those

[ddelnano]

My earlier comment was about the sr.createIso rpc call. That appears to be around creating a iso storage repository, so the REST api method you linked to seems like what we need.

[ddelnano]

I'm not planning to support fetching files from remote locations in the initial support. Terraform doesn't support having scratch filesystem space for providers (hashicorp/terraform#21308) and while the go-getter client would provide the downloading functionality, I want to avoid solving problems that can be addressed another way.

The terraform http provider has a PR for downloading binary files (hashicorp/terraform-provider-http#158). I'd prefer to wait until that is merged and then provide examples on how to leverage the official providers to accomplish the remote location.

If that doesn't get merged, then I'm open to reconsidering implementing this in the XO provider, but for now I think combining official providers to support remote files is the best option (once available).

[ddelnano]

Once this is released it's possible some users may run into vatesfr/xen-orchestra#6590. The XO team will be providing updates on that issue.

[4censord]

Does the terraform HTTP provider keep its result in memory?
This might be fine for small ISO's like alpine, but bigger ones like current windows isos (>5GiB) might be a problem.

Or even things like cloud-ready images, that might be bigger than 20Gib

[ddelnano]

This was automatically closed by merging that PR, but supporting remote file locations is still outstanding.

Does the terraform HTTP provider keep its result in memory?
This might be fine for small ISO's like alpine, but bigger ones like current windows isos (>5GiB) might be a problem.

It seems like that is the case (source). I still would like to see where that PR goes. If it is merged, doing the streaming inside the provider would be essentially the same work as doing it in the http provider (using the go-getter client, which is maintained by hashicorp as is the http provider). The latter would be a better investment since it would help a larger number of users while helping out the XO use case.

[ddelnano]

I followed up with my PR regarding the http provider today (hashicorp/terraform-provider-http#214 (comment)).

[ddelnano]

The Terraform team got back to me and while they were evaluating this functionality prior, they are not looking to make this change now. They are concerned about the stability of the provider given it has a large user base.

I'm evaluating maintaining whether to maintain a fork of the http provider and publish it to the terraform registry or to build this functionality into the xenorchestra provider. I have a slight preference for the former, since the Terraform team will eventually revisit this and in the meantime those that need this functionality can use the fork.