Zonewizard #67

poddm · 2023-08-07T23:10:38Z

Zone wizard resources:

cloudstack_zone
cloudstack_pod
cloudstack_cluster
cloudstack_physical_network
cloudstack_traffic_type
cloudstack_storage_pool
cloudstack_secondary_storage
cloudstack_vlan_ip_range
cloudstack_network_service_provider_state

Also, updated data source cloudstack_zone to work with the uuid vs. name (as the id).

--
Note -

this requires the latest cloudstack-go client.

Adding getRawValue to CreateZone api cloudstack-go#68

traffic_type is fully idempotent.

see addTrafficType/listTrafficTypes fields cloudstack#7837

harikrishna-patnala · 2023-09-13T06:30:01Z

cloudstack/provider.go

 		ResourcesMap: map[string]*schema.Resource{
 			"cloudstack_affinity_group":       resourceCloudStackAffinityGroup(),
 			"cloudstack_autoscale_vm_profile": resourceCloudStackAutoScaleVMProfile(),
+			"cloudstack_cluster":              resourceCloudStackCluster(),


great work @poddm. I'll try testing these changes.

Do we also need to add "cloudstack_zone" here ?

@harikrishna-patnala - cloudstack_zone was partially added in a previous merge. I extended the resource to support all of the fields and updated the ID from name to uuid.

poddm · 2023-11-28T19:31:07Z

Added additional resources

cloudstack_vlan_ip_range
cloudstack_network_service_provider_state

This also requires the following cloudstack-go change. apache/cloudstack-go#75

kiranchavala · 2024-03-06T05:04:13Z

@poddm could you please help in resolving the conflicts

poddm · 2024-04-26T02:56:18Z

@poddm could you please help in resolving the conflicts

Update - I'd still like to get these merged once the cloudstack SDK is updated.

cloudstack go SDK changes

rohityadavcloud · 2024-04-26T04:24:22Z

@poddm can you address conflicts on the PR?

rohityadavcloud · 2024-10-20T07:25:23Z

@poddm can you review/rebase the PR & look at failing tests. Thanks.

poddm · 2024-10-29T17:50:42Z

@rohityadavcloud @vishesh92. This is now rebased and updated to the latest cloudstack library.

the ACC tests are failing here. Is there a way to bypass this storage pool check in the simulator?

=== RUN   TestAccCloudStackStoragePool_basic
    resource_cloudstack_storage_pool_test.go:29: Step 1/2 error: Error running apply: exit status 1
        
        Error: CloudStack API error 530 (CSExceptionErrorCode: 9999): Failed to add data store: No host up to associate a storage pool with in cluster 1
        
          with cloudstack_storage_pool.test,
          on terraform_plugin_test.tf line 37, in resource "cloudstack_storage_pool" "test":
          37: resource "cloudstack_storage_pool" "test" {
        
--- FAIL: TestAccCloudStackStoragePool_basic (53.68s)
FAIL
FAIL    github.com/terraform-providers/terraform-provider-cloudstack/cloudstack 55.537s
FAIL

resource "cloudstack_storage_pool" "test" {
	name         = "acc_primarystorage1"
	url          = "nfs://10.147.28.6/export/home/sandbox/primary11"
	zone_id      = cloudstack_zone.test.id
	cluster_id   = cloudstack_cluster.test.id
	pod_id       = cloudstack_pod.test.id
	scope        = "CLUSTER"
	hypervisor   = "Simulator"
	state        = "Maintenance"
	tags         = "XYZ,123,456"
}

…tack_vlan_ip_range

poddm · 2025-09-11T03:01:40Z

@kiranchavala, I saw the devlist you were releasing v0.6.0. I'd like to get traction here - i've had this PR open for quite awhile and am using it in our internal fork.

I've rebased from the latest and a number of these resources have been added since. However, there are some minor issues in regards to implementation and provider conventions: https://developer.hashicorp.com/terraform/plugin/best-practices.

some of the resources have ambiguous fields that don't align to the API . For example zone, is it an ID or Name? I've back ported this PR change these instance to zone_id following terraform's best practices.
minor but cloudstack_physicalnetwork vs cloudstack_physical_network

Function names should be all lowercase and use underscores to separate words. The built-in functions in the Terraform language do not use underscores for historical reasons, but all functions defined in providers should use underscores to improve readability.

Physical network module was previously keyed off the name field instead of id. I believe this may cause issues where nested dependent resources are not recreated. Example -

resource "cloudstack_zone" "foo" {
  name = "terraform-zone"
  dns1 = "8.8.8.8"
  internal_dns1 = "8.8.4.4"
  network_type = "Advanced"
}

resource "cloudstack_physical_network" "foo" {
  name = "terraform-physical-network"
  zone = cloudstack_zone.foo.name # ----> If the name is the same the phsyical network wont be recreated
  broadcast_domain_range = "ZONE"
  isolation_methods = ["VLAN"]
}

kiranchavala · 2025-09-11T06:15:31Z

Thanks @poddm for the suggestion

Henceforth, we will check the pr for proper naming conventions

kiranchavala

@poddm

Hitting the following exception when i delete the following resources

resource "cloudstack_network_service_provider_state" "virtualrouter" {
    name                  = "VirtualRouter"
    physical_network_id   = cloudstack_physical_network.test.id
    enabled                 = false
}


resource "cloudstack_storage_pool" "test" {
	name         = "acc_primarystorage1"
	url          = "nfs://10.0.32.4/acs/primary/ref-trl-9433-k-Mol8-kiran-chavala/ref-trl-9433-k-Mol8-kiran-chavala-kvm-pri1/test"
	zone_id      = "05d9863d-bd94-41c2-bba8-251aab44637a"
	cluster_id   = "110d6845-647d-4339-b084-8f9d278fc568"
	pod_id       = "6079c0a3-e6d5-4eaf-ab47-551f657e5379"
	scope        = "CLUSTER"
	hypervisor   = "KVM"
	state        = "Maintenance"
	tags         = "XYZ,123,456"
}



The storage pool goes into up state 



cloudstack_pod.test: Destruction complete after 2s
╷
│ Error: Error deleting storage pool: CloudStack API error 431 (CSExceptionErrorCode: 4350): Unable to delete storage due to it is not in Maintenance state, pool: StoragePool {"id":8,"name":"acc_primarystorage1","poolType":"NetworkFilesystem","uuid":"8378d30a-9c47-3f13-a3c9-63bf9a0ac607"}
│ 
│ 
╵
╷
│ Error: Undefined error: {"errorcode":431,"errortext":"Network Service Provider id=28doesn't exist in the system"}

poddm · 2025-09-12T16:00:35Z

@kiranchavala - updates on these errors:

cloudstack_secondary_storage, did you terraform apply maintenance mode before running destroy? If you set the state on create to maintenance, its only available in the update API portion so a subsequent apply would resolve it. This is a limitation of the API.

Also, for the service provider error something deleted it. Did you happen to use cloudstack_network_service_provider and cloudstack_network_service_provider_state together? When creating a physical network many of the service providers are already created but in a disabled state.

cloudstack_network_service_provider_state was only meant to toggle them enabled/disabled. When destroying a service provider I set the provider to set it as disabled.

Here are the service providers I see created as part of a new initialized physical network.

{
    "listnetworkserviceprovidersresponse": {
        "count": 7,
        "networkserviceprovider": [
            {
                "name": "ConfigDrive",
                "physicalnetworkid": "220ed3ff-eb74-41b3-9547-e4995975e4e5",
                "state": "Disabled",
                "id": "5af78cb7-3486-4eaa-940f-3af93c4b1cc2",
                "servicelist": [
                    "UserData"
                ],
                "canenableindividualservice": false
            },
            {
                "name": "Tungsten",
                "physicalnetworkid": "220ed3ff-eb74-41b3-9547-e4995975e4e5",
                "state": "Disabled",
                "id": "ad858b62-7935-404f-9469-a1a023503d51",
                "servicelist": [
                    "Dhcp",
                    "Dns",
                    "Firewall",
                    "Lb",
                    "SourceNat",
                    "StaticNat",
                    "PortForwarding",
                    "SecurityGroup"
                ],
                "canenableindividualservice": true
            },
            {
                "name": "InternalLbVm",
                "physicalnetworkid": "220ed3ff-eb74-41b3-9547-e4995975e4e5",
                "state": "Disabled",
                "id": "262247b7-7366-4c07-ba3b-0be10192f464",
                "servicelist": [
                    "Lb"
                ],
                "canenableindividualservice": true
            },
            {
                "name": "BaremetalPxeProvider",
                "physicalnetworkid": "220ed3ff-eb74-41b3-9547-e4995975e4e5",
                "state": "Disabled",
                "id": "76913e03-e263-4a54-be98-80c06b1580a6",
                "servicelist": [],
                "canenableindividualservice": false
            },
            {
                "name": "VpcVirtualRouter",
                "physicalnetworkid": "220ed3ff-eb74-41b3-9547-e4995975e4e5",
                "state": "Disabled",
                "id": "06113b93-f532-4002-9b3d-20787d7479b7",
                "servicelist": [
                    "Vpn",
                    "Dhcp",
                    "Dns",
                    "Gateway",
                    "Lb",
                    "SourceNat",
                    "StaticNat",
                    "PortForwarding",
                    "UserData"
                ],
                "canenableindividualservice": true
            },
            {
                "name": "SecurityGroupProvider",
                "physicalnetworkid": "220ed3ff-eb74-41b3-9547-e4995975e4e5",
                "state": "Disabled",
                "id": "34a5dac1-1599-484a-9ded-7a54fa92593b",
                "servicelist": [
                    "SecurityGroup"
                ],
                "canenableindividualservice": false
            },
            {
                "name": "VirtualRouter",
                "physicalnetworkid": "220ed3ff-eb74-41b3-9547-e4995975e4e5",
                "state": "Enabled",
                "id": "aa37a9cc-6638-4d72-a6b5-0da241df1e8d",
                "servicelist": [
                    "Vpn",
                    "Dhcp",
                    "Dns",
                    "Gateway",
                    "Firewall",
                    "Lb",
                    "SourceNat",
                    "StaticNat",
                    "PortForwarding",
                    "UserData"
                ],
                "canenableindividualservice": true
            }
        ]
    }
}

Here is my local destroy output.

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

Terraform will perform the following actions:

  # cloudstack_network_service_provider_state.virtualrouter will be destroyed
  - resource "cloudstack_network_service_provider_state" "virtualrouter" {
      - enabled             = true -> null
      - id                  = "d97959df-be50-4ec0-a888-ffc898d9b935" -> null
      - name                = "VirtualRouter" -> null
      - physical_network_id = "3eabff91-debb-42f0-bb97-63da296bc1b4" -> null
    }

  # cloudstack_physical_network.test will be destroyed
  - resource "cloudstack_physical_network" "test" {
      - broadcast_domain_range = "ZONE" -> null
      - id                     = "3eabff91-debb-42f0-bb97-63da296bc1b4" -> null
      - isolation_methods      = "VLAN" -> null
      - name                   = "test01" -> null
      - network_speed          = "1G" -> null
      - tags                   = "vlan" -> null
      - zone_id                = "8e1e5ae2-37dd-4215-a5cf-d6b223e94cba" -> null
        # (2 unchanged attributes hidden)
    }

  # cloudstack_zone.test will be destroyed
  - resource "cloudstack_zone" "test" {
      - allocation_state       = "Disabled" -> null
      - dhcp_provider          = "VirtualRouter" -> null
      - dns1                   = "8.8.8.8" -> null
      - dns2                   = "8.8.8.8" -> null
      - domain                 = "cloudstack.apache.org" -> null
      - id                     = "8e1e5ae2-37dd-4215-a5cf-d6b223e94cba" -> null
      - internal_dns1          = "8.8.4.4" -> null
      - internal_dns2          = "8.8.4.4" -> null
      - local_storage_enabled  = false -> null
      - name                   = "acctest" -> null
      - network_type           = "Advanced" -> null
      - security_group_enabled = false -> null
        # (4 unchanged attributes hidden)
    }

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

Do you really want to destroy all resources?
  Terraform will destroy all your managed infrastructure, as shown above.
  There is no undo. Only 'yes' will be accepted to confirm.

  Enter a value: yes

cloudstack_network_service_provider_state.virtualrouter: Destroying... [id=d97959df-be50-4ec0-a888-ffc898d9b935]
cloudstack_network_service_provider_state.virtualrouter: Destruction complete after 0s
cloudstack_physical_network.test: Destroying... [id=3eabff91-debb-42f0-bb97-63da296bc1b4]
cloudstack_physical_network.test: Destruction complete after 0s
cloudstack_zone.test: Destroying... [id=8e1e5ae2-37dd-4215-a5cf-d6b223e94cba]
cloudstack_zone.test: Destruction complete after 0s

Destroy complete! Resources: 3 destroyed.
$

kiranchavala · 2025-09-15T04:59:11Z

@kiranchavala - updates on these errors:

cloudstack_secondary_storage, did you terraform apply maintenance mode before running destroy? If you set the state on create to maintenance, its only available in the update API portion so a subsequent apply would resolve it. This is a limitation of the API.

Also, for the service provider error something deleted it. Did you happen to use cloudstack_network_service_provider and cloudstack_network_service_provider_state together? When creating a physical network many of the service providers are already created but in a disabled state.

cloudstack_network_service_provider_state was only meant to toggle them enabled/disabled. When destroying a service provider I set the provider to set it as disabled.

Here are the service providers I see created as part of a new initialized physical network.

{
    "listnetworkserviceprovidersresponse": {
        "count": 7,
        "networkserviceprovider": [
            {
                "name": "ConfigDrive",
                "physicalnetworkid": "220ed3ff-eb74-41b3-9547-e4995975e4e5",
                "state": "Disabled",
                "id": "5af78cb7-3486-4eaa-940f-3af93c4b1cc2",
                "servicelist": [
                    "UserData"
                ],
                "canenableindividualservice": false
            },
            {
                "name": "Tungsten",
                "physicalnetworkid": "220ed3ff-eb74-41b3-9547-e4995975e4e5",
                "state": "Disabled",
                "id": "ad858b62-7935-404f-9469-a1a023503d51",
                "servicelist": [
                    "Dhcp",
                    "Dns",
                    "Firewall",
                    "Lb",
                    "SourceNat",
                    "StaticNat",
                    "PortForwarding",
                    "SecurityGroup"
                ],
                "canenableindividualservice": true
            },
            {
                "name": "InternalLbVm",
                "physicalnetworkid": "220ed3ff-eb74-41b3-9547-e4995975e4e5",
                "state": "Disabled",
                "id": "262247b7-7366-4c07-ba3b-0be10192f464",
                "servicelist": [
                    "Lb"
                ],
                "canenableindividualservice": true
            },
            {
                "name": "BaremetalPxeProvider",
                "physicalnetworkid": "220ed3ff-eb74-41b3-9547-e4995975e4e5",
                "state": "Disabled",
                "id": "76913e03-e263-4a54-be98-80c06b1580a6",
                "servicelist": [],
                "canenableindividualservice": false
            },
            {
                "name": "VpcVirtualRouter",
                "physicalnetworkid": "220ed3ff-eb74-41b3-9547-e4995975e4e5",
                "state": "Disabled",
                "id": "06113b93-f532-4002-9b3d-20787d7479b7",
                "servicelist": [
                    "Vpn",
                    "Dhcp",
                    "Dns",
                    "Gateway",
                    "Lb",
                    "SourceNat",
                    "StaticNat",
                    "PortForwarding",
                    "UserData"
                ],
                "canenableindividualservice": true
            },
            {
                "name": "SecurityGroupProvider",
                "physicalnetworkid": "220ed3ff-eb74-41b3-9547-e4995975e4e5",
                "state": "Disabled",
                "id": "34a5dac1-1599-484a-9ded-7a54fa92593b",
                "servicelist": [
                    "SecurityGroup"
                ],
                "canenableindividualservice": false
            },
            {
                "name": "VirtualRouter",
                "physicalnetworkid": "220ed3ff-eb74-41b3-9547-e4995975e4e5",
                "state": "Enabled",
                "id": "aa37a9cc-6638-4d72-a6b5-0da241df1e8d",
                "servicelist": [
                    "Vpn",
                    "Dhcp",
                    "Dns",
                    "Gateway",
                    "Firewall",
                    "Lb",
                    "SourceNat",
                    "StaticNat",
                    "PortForwarding",
                    "UserData"
                ],
                "canenableindividualservice": true
            }
        ]
    }
}

Here is my local destroy output.

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

Terraform will perform the following actions:

  # cloudstack_network_service_provider_state.virtualrouter will be destroyed
  - resource "cloudstack_network_service_provider_state" "virtualrouter" {
      - enabled             = true -> null
      - id                  = "d97959df-be50-4ec0-a888-ffc898d9b935" -> null
      - name                = "VirtualRouter" -> null
      - physical_network_id = "3eabff91-debb-42f0-bb97-63da296bc1b4" -> null
    }

  # cloudstack_physical_network.test will be destroyed
  - resource "cloudstack_physical_network" "test" {
      - broadcast_domain_range = "ZONE" -> null
      - id                     = "3eabff91-debb-42f0-bb97-63da296bc1b4" -> null
      - isolation_methods      = "VLAN" -> null
      - name                   = "test01" -> null
      - network_speed          = "1G" -> null
      - tags                   = "vlan" -> null
      - zone_id                = "8e1e5ae2-37dd-4215-a5cf-d6b223e94cba" -> null
        # (2 unchanged attributes hidden)
    }

  # cloudstack_zone.test will be destroyed
  - resource "cloudstack_zone" "test" {
      - allocation_state       = "Disabled" -> null
      - dhcp_provider          = "VirtualRouter" -> null
      - dns1                   = "8.8.8.8" -> null
      - dns2                   = "8.8.8.8" -> null
      - domain                 = "cloudstack.apache.org" -> null
      - id                     = "8e1e5ae2-37dd-4215-a5cf-d6b223e94cba" -> null
      - internal_dns1          = "8.8.4.4" -> null
      - internal_dns2          = "8.8.4.4" -> null
      - local_storage_enabled  = false -> null
      - name                   = "acctest" -> null
      - network_type           = "Advanced" -> null
      - security_group_enabled = false -> null
        # (4 unchanged attributes hidden)
    }

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

Do you really want to destroy all resources?
  Terraform will destroy all your managed infrastructure, as shown above.
  There is no undo. Only 'yes' will be accepted to confirm.

  Enter a value: yes

cloudstack_network_service_provider_state.virtualrouter: Destroying... [id=d97959df-be50-4ec0-a888-ffc898d9b935]
cloudstack_network_service_provider_state.virtualrouter: Destruction complete after 0s
cloudstack_physical_network.test: Destroying... [id=3eabff91-debb-42f0-bb97-63da296bc1b4]
cloudstack_physical_network.test: Destruction complete after 0s
cloudstack_zone.test: Destroying... [id=8e1e5ae2-37dd-4215-a5cf-d6b223e94cba]
cloudstack_zone.test: Destruction complete after 0s

Destroy complete! Resources: 3 destroyed.
$

Thanks @poddm for the clarification

kiranchavala

LGTM , Tested the creation of the following resources

cloudstack_zone
cloudstack_pod
cloudstack_cluster
cloudstack_physical_network
cloudstack_network_service_provider_state
cloudstack_network_service_provider
cloudstack_secondary_storage
cloudstack_storage_pool
cloudstack_traffic_type
cloudstack_vlan_ip_range

poddm mentioned this pull request Aug 7, 2023

Enhancing zone resource #65

Closed

poddm force-pushed the zonewizard branch from 5aba15e to 479cb46 Compare August 18, 2023 20:48

poddm marked this pull request as ready for review August 18, 2023 20:52

rohityadavcloud requested a review from harikrishna-patnala September 12, 2023 17:52

harikrishna-patnala added this to the v0.5.0 milestone Sep 13, 2023

harikrishna-patnala reviewed Sep 13, 2023

View reviewed changes

rohityadavcloud requested review from kiranchavala and vishesh92 March 6, 2024 14:24

kiranchavala modified the milestones: v0.5.0, v0.6.0 Mar 7, 2024

poddm mentioned this pull request Apr 26, 2024

new pod resource #112

Closed

poddm force-pushed the zonewizard branch from 0b465aa to 54a6e9e Compare June 26, 2024 21:50

poddm force-pushed the zonewizard branch from b1656b1 to 990925e Compare October 21, 2024 22:09

vishesh92 closed this Jan 24, 2025

vishesh92 reopened this Jan 24, 2025

poddm added 9 commits September 10, 2025 07:16

zone wizard

d28388c

Adding resources cloudstack_network_service_provider_state and clouds…

a3089a8

…tack_vlan_ip_range

sdk v2 updates

8de7ffe

fix type enabled bool type

63d9693

updating storage pool test case

28b488b

updating storage pool test case

f24347b

updating conflicting start_ip in ACC

9190fa6

updating pod fields from string to slice

2cc91b9

Adding schema descriptions

1c47c38

rebase

b70cce4

poddm force-pushed the zonewizard branch from 5fd89d7 to b70cce4 Compare September 10, 2025 19:53

poddm added 10 commits September 10, 2025 13:00

fix formatting

4e32403

physical network conflicts

ff6d28f

traffic type conflicts

7e688e6

update tests

3e877e2

updates

2003ec4

updates

573b89a

updates

da04d93

updates

522a08a

updates

07a83b5

updates

ae52fee

kiranchavala reviewed Sep 12, 2025

View reviewed changes

kiranchavala approved these changes Sep 15, 2025

View reviewed changes

kiranchavala merged commit 460bfef into apache:main Sep 15, 2025
24 checks passed

kiranchavala mentioned this pull request Sep 15, 2025

Add cloudstack_pod & cloudstack_cluster resource #217

Closed

ianc769 mentioned this pull request Sep 15, 2025

add cloudstack_cluster data source and documentation #222

Merged

Zonewizard #67

Zonewizard #67

Uh oh!

Conversation

poddm commented Aug 7, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

harikrishna-patnala Sep 13, 2023

Choose a reason for hiding this comment

Uh oh!

poddm Oct 17, 2023

Choose a reason for hiding this comment

Uh oh!

poddm commented Nov 28, 2023

Uh oh!

kiranchavala commented Mar 6, 2024

Uh oh!

poddm commented Apr 26, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rohityadavcloud commented Apr 26, 2024

Uh oh!

rohityadavcloud commented Oct 20, 2024

Uh oh!

poddm commented Oct 29, 2024

Uh oh!

poddm commented Sep 11, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

kiranchavala commented Sep 11, 2025

Uh oh!

kiranchavala left a comment

Choose a reason for hiding this comment

Uh oh!

poddm commented Sep 12, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

kiranchavala commented Sep 15, 2025

Uh oh!

kiranchavala left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

poddm commented Aug 7, 2023 •

edited

Loading

poddm commented Apr 26, 2024 •

edited

Loading

poddm commented Sep 11, 2025 •

edited

Loading

poddm commented Sep 12, 2025 •

edited

Loading