* feat(nodes): Initial support to manage APT repositories
> Summary
This commit implements initial support for managing APT repositories
which is (currently) limited to…
- …adding "standard" repositories to allow to configure it.
- toggling the activation status (enabled/disabled) of any configured
repository.
+ !WARNING!
+ Note that deleting or modifying a repository in any other way is
+ (sadly) not possible (yet?)!
+ The limited functionality is due to the (current) capabilities of
+ the Proxmox VE APT repository API [1] itself.
>> Why are there two resources for one API entity?
Even though an APT repository should be seen as a single API entity, it
was required to implement standard repositories as dedicated
`proxmox_virtual_environment_apt_standard_repository`. This is because
standard repositories must be configured (added) first to the default
source list files because their activation status can be toggled. This
is handled by the HTTP `PUT` request, but the modifying request is
`POST` which would require two calls within the same Terraform execution
cycle. I tried to implement it in a single resource and it worked out
mostly after some handling some edges cases, but in the end there were
still too many situations an edge cases where it might break due to
Terraform state drifts between states. In the end the dedicated
resources are way cleaner and easier to use without no complexity and
conditional attribute juggling for practitioners.
>> Other "specialties"
Unfortunately the Proxmox VE API responses to HTTP `GET` requests with
four larger arrays which are, more or less, kind of connected to each
other, but they also somehow stand on their own. This means that there
is a `files` array that contains the `repositories` again which again
contains all repositories with their metadata of every source file. On
the other hand available standard repositories are listed in the
`standard-repos` array, but their activation status is only stored when
they have already been added through a `PUT` request. The `infos` array
is more less useless.
So in order to get the required data and store them in the state the
`importFromAPI` methods of the models must loop through all the
deep-nested arrays and act based on specific attributes like a matching
file path, comparing it to the activation status and so on.
In the end the implementation is really stable after testing it with all
possible conditions and state combinations.
@bpg if you'd like me to create a small data logic flow chart to make it
easier to understand some parts of the code let me know. I can make my
local notes "shareable" which I created to not loose track of the logic.
>> What is the way to manage the activation status of a "standard" repository?
Because the two resources are modular and scoped they can be simply
combined to manage an APT "standard" repository, e.g. toggling its
activation status. The following examples are also included in the
documentations.
```hcl
// This resource ensure that the "no-subscription" standard repository
// is added to the source list.
// It represents the `PUT` API request.
resource "proxmox_virtual_environment_apt_standard_repository" "example" {
handle = "no-subscription"
node = "pve"
}
// This resource allows to actually modify the activation status of the
// standard repository as it represents the `POST`.
// Using the values from the dedicated standard repository resource
// makes sure that Terraform correctly resolves dependency order.
resource "proxmox_virtual_environment_apt_repository" "example" {
enabled = true
file_path = proxmox_virtual_environment_apt_standard_repository.example.file_path
index = proxmox_virtual_environment_apt_standard_repository.example.index
node = proxmox_virtual_environment_apt_standard_repository.example.node
}
```
[1]: https://pve.proxmox.com/pve-docs/api-viewer/#/nodes/{node}/apt/repositories
---------
Signed-off-by: Sven Greb <development@svengreb.de>
Signed-off-by: Pavel Boldyrev <627562+bpg@users.noreply.github.com>
Co-authored-by: Pavel Boldyrev <627562+bpg@users.noreply.github.com>
* feat(cluster): Implement initial support for "hardware mappings"
Right now it is alredy possible to use a mapped resource [1], but there
is no dedicated `proxmox_virtual_environment_cluster_hardware_mapping`
resource but this step must still be done manually (or automated through
other ways that interact with the Proxmox API).
This commit implements support for "hardware mapping" resources and data
sources for the, currently, available bus types PCI and USB, based on
the Proxmox VE API documentations [2].
There are some "specialities" in these resources and data sources:
1. The Proxmox VE API attribute, but this implementations names it
"comment" since this naming is generally across the Proxmox VE web UI
and API documentations. This still follows the Terraform
"best practices" [3] as it improves the user experience by matching
the field name to the naming used in the human-facing interfaces.
2. Like in point 1, the name of the attribute of "node checks
diagnostics" for USB hardware mappings is "errors" in the Proxmox VE
API while it is "checks" for hardware mappings of type PCI.
The second naming pattern is also generally used across the
Proxmox VE web UI and API documentations, including the "check_node"
attribute that is also implemented in the
"proxmox_virtual_environment_hardware_mappings" data source.
Therefore, this implementation named both attributes "checks" which
still follows the Terraform "best practices" [3] as it improves the
user experience by matching the field name to the naming used in the
human-facing interfaces.
3. This implmenetation comes with the "unique" feature of allowing
comments (named "descriptions" by the Proxmox VE API) for an entry in
a device map which is not possible through the web UI at all but only
adding a comment for the whole mapping entry instead.
Note that this implementation also adds another point in the
"Known Issues" documentation since it is only possible to map a
PCI/USB device using the `root` PAM account, but this is still better
than having to manually configure it through the web UI or by
interacting with the Proxmox VE API on other ways.
[1]: https://github.com/bpg/terraform-provider-proxmox/pull/500
[2]: https://pve.proxmox.com/pve-docs/api-viewer/#/cluster/mapping/pci
[3]: https://developer.hashicorp.com/terraform/plugin/best-practices/hashicorp-provider-design-principles#resource-and-attribute-schema-should-closely-match-the-underlying-api
Signed-off-by: Sven Greb <development@svengreb.de>
* fix linter
Signed-off-by: Pavel Boldyrev <627562+bpg@users.noreply.github.com>
---------
Signed-off-by: Sven Greb <development@svengreb.de>
Signed-off-by: Pavel Boldyrev <627562+bpg@users.noreply.github.com>
Co-authored-by: Pavel Boldyrev <627562+bpg@users.noreply.github.com>
cleaning up and refactoring the VM code, add some acceptance tests around disks, few minor bugfixes
Signed-off-by: Pavel Boldyrev <627562+bpg@users.noreply.github.com>
* cleanup 1
* continue refactoring
* more refactoring
* move VMs under nodes
* move container and other apis under nodes
* cleanups
* enabled revive.exported linter & add comments to exported stuff
* enable godot linter
* enable wsl linter
* enable thelper linter
* enable govet linter
* cleanup after rebase
* cleanup after rebase
* extract SSH ops into a separate interface
* fix linter error
* move ssh code to its own package
* cleaning up VirtualEnvironmentClient receivers
* on the finish line
* not sure what else I forgot... 🤔
* fix ssh connection and upload
* renaming client interfaces
* final cleanups
* refactoring existing cluster / firewall API for better composition
* add basic security groups API
fix linter errors
* add rules API
* fix after renaming resourceVirtualEnvironmentClusterIPSet
* fix linter errors
* make linter happy
* even more refactoring
* tidy up datasources
* in refactoring spree
* update examples
* fix firewall resource/datasource & client error handling
* add ipset(s) datasource
* update docs
* add security group resource with rules
* docs
* fix security group update, TODO: rule update
* fix after rebase
* add rule update, extract common rule schema, refactor group
* fix linter errors
* bump linter for ci
* make alias and ipset reusable
* make security group reusable
* refactor datasources
* add security group datasources
* fix linter errors
* update docs
TODO: documentation for group datasources
* add sg docs, update doc index
* minor cleanup
* fix examples & tests
* stub for firewall-level options and rules
* extract firewall interface
* add firewall options and rules on the cluster level
TODO: issues with rule list management
* refactor all resources format AGAIN, now more flat, without complex subresources
* sort out hierarchy of APIs and remove duplication in API wrappers
* bring back security group
* finally, working rules
* restore cluster firewall option
* add containers support
* add options
* move rules back under security group, update docs
* fix vm_id / container_id attrs
* add examples
* cleanup
* more cleanup
Release-As: 0.17.0-rc1
