Skip to content

Feature Request: Improve usability of proxmox_files for conditional file usage #2717

@dgomesb

Description

@dgomesb

Description

The proxmox_files data source is very useful for listing files in a Proxmox datastore. However, using it in combination with proxmox_virtual_environment_download_file to implement a very common workflow is currently more complex than expected.

This is especially noticeable when working with cloud images (content_type = "import") used as base disks for virtual machines.


Problem

A frequent use case is:

"Use an existing base image if it exists in the datastore; otherwise, download it and use it."

While the provider already offers all the necessary building blocks (proxmox_files and proxmox_virtual_environment_download_file), implementing this behavior requires a significant amount of boilerplate and manual logic.


Current Workaround (Full Example)

locals {
  target_file_name = "noble-server-cloudimg-amd64.img"

  matching_files = [
    for f in data.proxmox_files.images.files : f if f.name == local.target_file_name
  ]

  image_file_id = length(local.matching_files) > 0 ? local.matching_files[0].id : proxmox_virtual_environment_download_file.ubuntu_image[0].id
}

data "proxmox_files" "images" {
  node_name    = "pve"
  datastore_id = "local"
  content_type = "import"
}

resource "proxmox_virtual_environment_download_file" "ubuntu_image" {
  count = length(local.matching_files) == 0 ? 1 : 0

  node_name    = "pve"
  datastore_id   = "local"
  content_type  = "import"

  url              = "https://cloud-images.ubuntu.com/noble/current/noble-server-cloudimg-amd64.img"
  file_name = "noble-server-cloudimg-amd64.img"
}

resource "proxmox_virtual_environment_vm" "vm" {
  name      = "example-vm"
  node_name = "pve"

  disk {
    datastore_id = "local"
    file_id      = local.image_file_id
  }
}

Why this is problematic

For such a common workflow, the current approach requires:

  • Manual iteration and filtering over files
  • Multiple locals variables
  • Conditional resource creation using count
  • Conditional selection of IDs
  • Handling Terraform indexing ([0])

This increases complexity and reduces readability.


Proposed Improvement

Improve the usability of proxmox_files by allowing direct lookup of a file by name.

Example (hypothetical)

data "proxmox_files" "base_image" {
  node_name    = var.node_name
  datastore_id = var.datastore_id
  content_type = "import"

  file_name = "noble-server-cloudimg-amd64.qcow2"
}

Expected behavior

  • If the file exists → return it (e.g., expose id)
  • If the file does not exist → return null (or empty result)

Simplified Workflow with This Improvement

resource "proxmox_virtual_environment_download_file" "base_image" {
  count = data.proxmox_files.base_image.id == null ? 1 : 0

  node_name    = var.node_name
  datastore_id = var.datastore_id
  content_type = "import"

  url  = "https://cloud-images.ubuntu.com/noble/current/noble-server-cloudimg-amd64.img"
  file_name = "noble-server-cloudimg-amd64.qcow2"
}

resource "proxmox_virtual_environment_vm" "vm" {
  name      = "example-vm"
  node_name = var.node_name

  disk {
    datastore_id = var.datastore_id
    import_from      = data.proxmox_files.base_image.id != null
    ? data.proxmox_files.base_image.id
    : proxmox_virtual_environment_download_file.base_image[0].id
  }
}

Benefits

  • Eliminates manual filtering logic
  • Reduces boilerplate significantly
  • Keeps download responsibility in proxmox_virtual_environment_download_file
  • Makes the workflow much more intuitive and readable
  • Better aligns with common Terraform patterns

Summary

While the provider already supports all required operations, the current user experience for "use existing or download if missing" is unnecessarily complex.

Allowing proxmox_files to query directly by file name would greatly simplify this workflow without changing existing responsibilities between data sources and resources.

Thank you for your work on this provider!

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions