SystemVM offering declaration

[bddvlpr]

Adds a cloudstack_system_service_offering resource that does what it says on the tin, creates SystemVM offerings. I was first considering merging this logic with cloudstack_service_offering_fixed as it performs the exact same API call with an exception of a few parameters, but to avoid confusion I kept it separate (I also don't want to mix it with the shared commons between constrained and fixed offerings).

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[sureshanaparti]

Hi @bddvlpr Can you check the failed tests here. Thanks.

[bddvlpr]

These failing tests are not of my doing, one of which is the panic where the acceptance test times out (happens upstream too periodically). The other is a racecon on the initialization of the simulator which also happens upstream. Could you please re-run these tests?

[Copilot]

Warning

Copilot couldn't run its full agentic review because it didn't start before the timeout. Make sure your repository has a runner available, or add a copilot-code-review.yml file specifying one with the runs-on attribute. See the docs for more details.

Pull request overview

Copilot reviewed 5 out of 5 changed files in this pull request and generated 5 comments.

[sureshanaparti]

Hi @bddvlpr Can you check & address the copilot comments if relevant. Thanks.

[bddvlpr]

I've adressed the comments. Only one was kind-of relevant and I've added tests for this one.

[sudo87]

@bddvlpr validateSystemServiceOfferingConfiguration compares system_vm_type/storage_type against lowercase literals, but both fields accept mixed case via StringInSlice(..., true) — the lowercasing StateFunc only applies to stored state, not to the raw value CustomizeDiff sees while planning. So system_vm_type = "DomainRouter" (valid per schema, and CloudStack's own casing convention) with network_rate set wrongly fails with "network_rate can only be set when system_vm_type is domainrouter". Same issue in reverse for storage_type = "Local" + offer_ha — it silently skips the check instead. Could this be a problem?

[sureshanaparti]

@bddvlpr validateSystemServiceOfferingConfiguration compares system_vm_type/storage_type against lowercase literals, but both fields accept mixed case via StringInSlice(..., true) — the lowercasing StateFunc only applies to stored state, not to the raw value CustomizeDiff sees while planning. So system_vm_type = "DomainRouter" (valid per schema, and CloudStack's own casing convention) with network_rate set wrongly fails with "network_rate can only be set when system_vm_type is domainrouter". Same issue in reverse for storage_type = "Local" + offer_ha — it silently skips the check instead. Could this be a problem?

ping @bddvlpr can you advise on this. thanks.

[bddvlpr]

Should be resolved with the EqualFold.

[kiranchavala]

LGTM tested manually

resource "cloudstack_system_service_offering" "router" {
  name           = "redundant-router-offering2"
  display_text   = "Redundant router offering2"
  system_vm_type = "domainrouter"
  cpu_number     = 2
  cpu_speed      = 1000
  memory         = 2048
  network_rate   = 200
  offer_ha       = true
}

terraform apply

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated
with the following symbols:
  + create

Terraform will perform the following actions:

  # cloudstack_system_service_offering.router will be created
  + resource "cloudstack_system_service_offering" "router" {
      + cpu_number     = 2
      + cpu_speed      = 1000
      + display_text   = "Redundant router offering"
      + id             = (known after apply)
      + limit_cpu_use  = false
      + memory         = 2048
      + name           = "redundant-router-offering"
      + network_rate   = 200
      + offer_ha       = true
      + storage_type   = "shared"
      + system_vm_type = "domainrouter"
    }

Plan: 1 to add, 0 to change, 0 to destroy.

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: yes

cloudstack_system_service_offering.router: Creating...
cloudstack_system_service_offering.router: Creation complete after 1s [id=41794c08-592b-48d2-878c-2f8fceef2dd6]

Apply complete! Resources: 1 added, 0 changed, 0 destroyed.

updated the value of the resource

terraform apply
cloudstack_system_service_offering.router: Refreshing state... [id=41794c08-592b-48d2-878c-2f8fceef2dd6]

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated
with the following symbols:
  ~ update in-place

Terraform will perform the following actions:

  # cloudstack_system_service_offering.router will be updated in-place
  ~ resource "cloudstack_system_service_offering" "router" {
      ~ display_text   = "Redundant router offering" -> "Redundant router offering2"
        id             = "41794c08-592b-48d2-878c-2f8fceef2dd6"
      ~ name           = "redundant-router-offering" -> "redundant-router-offering2"
        # (11 unchanged attributes hidden)
    }

Plan: 0 to add, 1 to change, 0 to destroy.

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: yes

cloudstack_system_service_offering.router: Modifying... [id=41794c08-592b-48d2-878c-2f8fceef2dd6]
cloudstack_system_service_offering.router: Modifications complete after 0s [id=41794c08-592b-48d2-878c-2f8fceef2dd6]

Apply complete! Resources: 0 added, 1 changed, 0 destroyed.