This is an "umbrella" ticket (call it an epic, or whatever) to track the migration of the proxmox_virtual_environment_vm resource to the Plugin Framework.
The Plugin Framework gives better control over Optional and Computed fields and their defaults, which is extremely useful in handling the clone operation. During cloning, we inject lots of attributes from a template that are not present in the clone while also overwriting some of the template parameters from the clone.
Related:
247
360
781
850
873
1106
1219
1224
566
1304
1299
and others
Ability to manage data transformations via custom data types (various conventions for lists/sets in the Proxmox API).
Better support for collection data types (lists, and specifically sets, to handle unordered collections of items).
Challenges
There's a vast amount of functionality to port, and some (or most?) of it needs to be re-implemented to leverage the benefits of the Provider Framework data model/custom types.
Severe lack of the provider's code test coverage. The changes/re-implementation will introduce new bugs that will be hard to catch.
Compatibility
Inevitably, some attribute formats and semantics will be incompatible with the old version. Also, some attributes will be renamed/removed. Known incompatibilities are marked with :exclamation: below.
Implementation
The proxmox_virtual_environment_vm2 resource contains the new implementation.
Hi, i think that we need to add reboot flag. which allow/skip rebooting the VM if it needed after changes.
(Currently, I usually comment out the reboot block in the code...)
This is an "umbrella" ticket (call it an epic, or whatever) to track the migration of the
proxmox_virtual_environment_vm
resource to the Plugin Framework.Motivation
Check out the benefits of Plugin Framework from HashiCorp. There are quite a lot.
Specific to this provider:
The Plugin Framework gives better control over
Optional
andComputed
fields and their defaults, which is extremely useful in handling theclone
operation. During cloning, we inject lots of attributes from a template that are not present in the clone while also overwriting some of the template parameters from the clone.Related:
247
360
781
850
873
1106
1219
1224
566
1304
1299
Ability to manage data transformations via custom data types (various conventions for lists/sets in the Proxmox API).
Better support for collection data types (lists, and specifically sets, to handle unordered collections of items).
Challenges
There's a vast amount of functionality to port, and some (or most?) of it needs to be re-implemented to leverage the benefits of the Provider Framework data model/custom types.
Severe lack of the provider's code test coverage. The changes/re-implementation will introduce new bugs that will be hard to catch.
Compatibility
Inevitably, some attribute formats and semantics will be incompatible with the old version. Also, some attributes will be renamed/removed. Known incompatibilities are marked with :exclamation: below.
Implementation
The
proxmox_virtual_environment_vm2
resource contains the new implementation.Status of features/attributes:
acpi
boot_order
description
id
:exclamation:hook_script_file_id
machine
migrate
name
node_name
on_boot
pool_id
protection
reboot
smbios
started
stop_on_destroy
tablet_device
tags
template
agent
audio_device
bios
cdrom
clone
cpu
disk
efi_disk
hostpci
initialization
keyboard_layout
kvm_arguments
memory
network_device
numa
operating_system
serial_device
scsi_hardware
startup
timeouts
:exclamation:tpm_state
usb
vga