Intent to contribute: ISO generation for cloud-init disks about terraform-provider-proxmox HOT 6 OPEN

Hi @ZauberNerd! 👋🏼

That's an interesting idea! While I'm not opposed to this approach, it won't solve the main problem you're aiming at: eliminating SSH access. We still need SSH to run the custom import command for VM disks, as the PVE API does not allow importing, for example, a qcow2 image stored in the iso storage using import-disk attribute.

Would you mind sketching an example of a VM resource using this new approach, so we can discuss the details?

I'm also about to start experimenting with the implementation of the initialization section for the new VM2 resource. It would be nice to flesh out some design points around cloud-init.

from terraform-provider-proxmox.

Yes, unfortunately it doesn't solve other file upload issues. As far as I understand, only .iso and .vztmpl can be uploaded, right (https://pve.proxmox.com/pve-docs/api-viewer/#/nodes/{node}/storage/{storage}/upload)?
I just checked and the UI creates a raw disk, which can then be configured via the UI. This won't be the case with my proposed solution.

My idea was to specifically target the cloud-init generation:

• add a new content_type to proxmox_virtual_environment_file (e.g. cloud-init or cloud-init-iso or something similar)
• build an ISO9660 image on the fly via the above mentioned library with the content of source_file or source_raw and upload it

This would allow to at least eliminate SSH access for a common use case of provisioning cloud-init based VMs.

from terraform-provider-proxmox.

Hey @ZauberNerd !

I just checked and the UI creates a raw disk, which can then be configured via the UI. This won't be the case with my proposed solution.

Yes, and there will be a possibility of having two conflicting cloud-init configs, one from the custom build iso file you're proposing, and another that comes from the initialization section.

I would prefer to have the new "cloud-init-iso" configuration wrapped up in the initialization as well. That way we can have some schema rules that could prevent declaring PVE-native cloud-init params when a custom coloud-init files are there.

I'm thinking about a structure like:

initailization {
  datastore_id = ...
  interface = ...
 
  # all other existing attributes
  # but if present alongside the `iso` then provider will throw an error

  iso {
    meta_data = <<-EOT
    ...
    EOT

    user_data = ....
    vendor_data = ....
    ... 
  }

WDYT?

from terraform-provider-proxmox.

@bpg I like it. But do we then still need the iso block or could we make meta_data, user_data and vendor_data mutually exclusive to other parameters?
I'm not too well versed in terraform api design, so not sure, if that is a good pattern or not?

from terraform-provider-proxmox.

Yes, we can define constraints on the attribute to make them mutually exclusive. Actually that's what I meant by "throw an error". Provider could do the schema validation when parsing a config, and flag attributes that overwrite each other.

from terraform-provider-proxmox.

There is also a good thread with lots of details about cloud-init behaviour in different cases.

from terraform-provider-proxmox.