feat(sdn): add custom resource to apply sdn_* configurations

[MacherelR]

Contributor's Note

• I have added / updated documentation in /docs for any user-facing features or additions.
• I have added / updated acceptance tests in /fwprovider/tests for any new or updated resources / data sources.
• I have ran make example to verify that the change works as expected.

Based on the SDN Implementation discussions (#1995 and #817), I have added a custom resource allowing the reload of sdn configurations automatically everytime an SDN resource is created/updated.
Only remaining caveats:

1. You need to explicitely mention every resource you want to watch inside the replace_triggered_by list, which can become a bit heavy in case of a huge network definition.
2. When destroying resources (terraform destroy) the configuration isn't applied as the applier resource is also destroyed... Thought about calling the client.ApplyConfig method in the provider's Delete method but as the applier depends_on (safer) the resources, he will be deleted before and therefore that won't ensure the latest apply.

Proof of Work

Here's an example of use:

resource "proxmox_virtual_environment_sdn_zone_simple" "test_zone_1" {
  id = "tZone1"
  nodes= [data.proxmox_virtual_environment_nodes.example.names]
  mtu = 1496

  depends_on = [
    proxmox_virtual_environment_sdn_applier.finalizer
  ]
}

resource "proxmox_virtual_environment_sdn_zone_simple" "test_zone_2" {
  id = "tZone2"
  nodes= [data.proxmox_virtual_environment_nodes.example.names]
  mtu = 1496
  
  depends_on = [
    proxmox_virtual_environment_sdn_applier.finalizer
  ]
}

resource "proxmox_virtual_environment_sdn_applier" "applier" {
   lifecycle {
    replace_triggered_by = [
      proxmox_virtual_environment_sdn_zone_simple.test_zone_1,
      proxmox_virtual_environment_sdn_zone_simple.test_zone_2,
      ]
  }

  depends_on = [
    proxmox_virtual_environment_sdn_zone_simple.test_zone_1,
    proxmox_virtual_environment_sdn_zone_simple.test_zone_2,
  ]
}

resource "proxmox_virtual_environment_sdn_applier" "finalizer" {
}

As you can try it, everytime a resource of type zone will be modified, the applier will be replaced, triggering a reload on proxmox's SDN configs.

See more examples in the acceptance tests.

Now as discussed with @bpg, this might not be the most effective or perfectly rendered version, but I had very little time to work on it and won't be available for some time so, anyone, feel free to leave comments or, even better, collaborate and improve this work ! :)

Community Note

• Please vote on this pull request by adding a 👍 reaction to the original pull request comment to help the community and maintainers prioritize this request
• Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for pull request followers and do not help prioritize the request

Closes #0000 | Relates #0000

[bpg]

When destroying resources (terraform destroy) the configuration isn't applied as the applier resource is also destroyed... Thought about calling the client.ApplyConfig method in the provider's Delete method but as the applier depends_on (safer) the resources, he will be deleted before and therefore that won't ensure the latest apply.

Ah.. that's a good point, let me think about it...

[bpg]

When destroying resources (terraform destroy) the configuration isn't applied as the applier resource is also destroyed... Thought about calling the client.ApplyConfig method in the provider's Delete method but as the applier depends_on (safer) the resources, he will be deleted before and therefore that won't ensure the latest apply.

Ah.. that's a good point, let me think about it...

We could probably introduce a "finalizer" resources, smth. like:

resource "proxmox_virtual_environment_sdn_finalizer" "cleanup" {
...
}

resource "proxmox_virtual_environment_sdn_zone_simple" "test_zone_1" {
  id = "tZone1"
  nodes = [data.proxmox_virtual_environment_nodes.example.names]
  
  depends_on = [proxmox_virtual_environment_sdn_finalizer.cleanup]
}

[bpg]

Have some comments below. I also realized that we don't read the pending state of zones, so testing of the apply function in acceptance tests can't be done efficiently.

I'll work on changes to address all of this.

[bpg]

we should probably wait here for the task to complete

[bpg]

I'd just use the unix timestamp in msec here

[bpg]

not sure if this code does anything 🤔

[bpg]

I don't think import is needed for this resource

[bpg]

Well, this whole "pending" state is a bit of mess.

For example, after creating a new zone, but before applying it, the API returns the zone as:

{
    "data": {
        "state": "new",
        "zone": "zoneS",
        "pending": {
            "nodes": "pve",
            "mtu": 1496
        },
        "type": "simple",
        "digest": null
    }
}

then after applying:

{
    "data": {
        "mtu": 1496,
        "zone": "zoneS",
        "digest": null,
        "type": "simple",
        "nodes": "pve"
    }
}

[bpg]

/gemini review

[gemini-code-assist]

Code Review

This pull request introduces a new experimental resource, proxmox_virtual_environment_sdn_applier, to trigger the application of SDN configurations. This is a valuable addition for managing SDN resources more effectively with Terraform. The changes also include updating existing SDN resources and data sources to expose pending and state information, which improves visibility into the configuration status. The implementation is solid, with comprehensive acceptance tests. I've found a minor inconsistency in the new resource's implementation and a couple of typos in the documentation, which I've detailed in the review comments.

[bpg]

Okay, i think it is in a good shape now. Apply on zone create / update / delete works fine. So, LGTM! 🚀