mirror of
https://github.com/bpg/terraform-provider-proxmox.git
synced 2025-07-02 03:22:59 +00:00
* 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>
86 lines
2.6 KiB
Go
86 lines
2.6 KiB
Go
/*
|
|
This Source Code Form is subject to the terms of the Mozilla Public
|
|
License, v. 2.0. If a copy of the MPL was not distributed with this
|
|
file, You can obtain one at https://mozilla.org/MPL/2.0/.
|
|
*/
|
|
|
|
package mapping
|
|
|
|
import (
|
|
"context"
|
|
"fmt"
|
|
"net/http"
|
|
"net/url"
|
|
|
|
"github.com/bpg/terraform-provider-proxmox/proxmox/api"
|
|
proxmoxtypes "github.com/bpg/terraform-provider-proxmox/proxmox/types/hardwaremapping"
|
|
)
|
|
|
|
// Create creates a new hardware mapping.
|
|
func (c *Client) Create(ctx context.Context, hmType proxmoxtypes.Type, data *CreateRequestBody) error {
|
|
err := c.DoRequest(ctx, http.MethodPost, c.ExpandPath(hmType, ""), data, nil)
|
|
if err != nil {
|
|
return fmt.Errorf("creating hardware mapping %q: %w", data.ID, err)
|
|
}
|
|
|
|
return nil
|
|
}
|
|
|
|
// Delete deletes a hardware mapping.
|
|
func (c *Client) Delete(ctx context.Context, hmType proxmoxtypes.Type, name string) error {
|
|
err := c.DoRequest(ctx, http.MethodDelete, c.ExpandPath(hmType, url.PathEscape(name)), nil, nil)
|
|
if err != nil {
|
|
return fmt.Errorf("deleting hardware mapping %q: %w", name, err)
|
|
}
|
|
|
|
return nil
|
|
}
|
|
|
|
// Get retrieves the configuration of a single hardware mapping.
|
|
func (c *Client) Get(ctx context.Context, hmType proxmoxtypes.Type, name string) (*GetResponseData, error) {
|
|
resBody := &GetResponseBody{}
|
|
|
|
err := c.DoRequest(ctx, http.MethodGet, c.ExpandPath(hmType, url.PathEscape(name)), nil, resBody)
|
|
if err != nil {
|
|
return nil, fmt.Errorf("reading hardware mapping %q: %w", name, err)
|
|
}
|
|
|
|
if resBody.Data == nil {
|
|
return nil, api.ErrNoDataObjectInResponse
|
|
}
|
|
|
|
return resBody.Data, nil
|
|
}
|
|
|
|
// List retrieves the list of hardware mappings.
|
|
// If "checkNode" is not empty, the "checks" list will be included in the response that might include configuration
|
|
// correctness diagnostics for the given node.
|
|
func (c *Client) List(ctx context.Context, hmType proxmoxtypes.Type, checkNode string) ([]*ListResponseData, error) {
|
|
options := &listQuery{
|
|
CheckNode: checkNode,
|
|
}
|
|
|
|
resBody := &ListResponseBody{}
|
|
|
|
err := c.DoRequest(ctx, http.MethodGet, c.ExpandPath(hmType, ""), options, resBody)
|
|
if err != nil {
|
|
return nil, fmt.Errorf("listing hardware mapping: %w", err)
|
|
}
|
|
|
|
if resBody.Data == nil {
|
|
return nil, api.ErrNoDataObjectInResponse
|
|
}
|
|
|
|
return resBody.Data, nil
|
|
}
|
|
|
|
// Update updates an existing hardware mapping.
|
|
func (c *Client) Update(ctx context.Context, hmType proxmoxtypes.Type, name string, data *UpdateRequestBody) error {
|
|
err := c.DoRequest(ctx, http.MethodPut, c.ExpandPath(hmType, url.PathEscape(name)), data, nil)
|
|
if err != nil {
|
|
return fmt.Errorf("udating hardware mapping %q: %w", name, err)
|
|
}
|
|
|
|
return nil
|
|
}
|