Resources tag required input parameters as optional, fail to build

[schwaboy]

I've noticed this problem on both v1.0.0 and v1.1.0 of the provider when building thunder_partition and thunder_server resources. I suspect there are several more resources to which this may apply. Using thunder_partition resources as an example, the documentation lists no required parameters, and the following parameters as optional

• application_type
• id1
• partition_name
• shared_vlan
• template
• user_tag
• uuid

However, in order to build a partition successfully, you need at least the partition_name and id1 parameters defined. If you attempt to build a partition with only partition_name, Terraform will let you run a plan, and apply it.

  partition_name = "test_partition"
#  id1 = 1
}

The load balancer itself will fail to build the partition and return an error, and Terraform will add an invalid resource to the state file.

Acquiring state lock. This may take a few moments...
module.example_com.module.servers["real_server_2"].thunder_server.current: Refreshing state... [id=example_server_002]
module.example_com.module.servers["real_server_1"].thunder_server.current: Refreshing state... [id=example_server_001]
module.example_.module.servicegroup["service_group_1"].thunder_service_group.current: Refreshing state... [id=example_com_service_group1]
module.example_com.module.servicegroup["service_group_2"].thunder_service_group.current: Refreshing state... [id=example_com_service_group2]
module.example_com.module.vip.thunder_virtual_server.virtual_server: Refreshing state... [id=example_com_virtual_server_1]

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:

  # thunder_partition.current will be created
  + resource "thunder_partition" "current" {
      + id             = (known after apply)
      + partition_name = "test_partition"
    }

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

thunder_partition.current: Creating...
╷
│ Error: PostPartition  --->  Partition does not exist (object: partition)
│
│   with thunder_partition.current,
│   on main.tf line 11, in resource "thunder_partition" "current":
│   11: resource "thunder_partition" "current" {
│
╵
Releasing state lock. This may take a few moments...

This not only causes problems creating resources, but breaks the state file. Fixing it requires manually editing the state file.

Acquiring state lock. This may take a few moments...
thunder_partition.current: Refreshing state... [id=test_partition]
module.example_com.module.servers["real_server_2"].thunder_server.current: Refreshing state... [id=example_server_002]
module.example_com.module.servers["real_server_1"].thunder_server.current: Refreshing state... [id=example_server_001]
module.example_com.module.servicegroup["service_group_1"].thunder_service_group.current: Refreshing state... [id=example_com_service_group1]
module.example_com.module.servicegroup["service_group_2"].thunder_service_group.current: Refreshing state... [id=example_com_service_group2]
module.example_com.module.vip.thunder_virtual_server.virtual_server: Refreshing state... [id=example_com_virtual_server_1]

Planning failed. Terraform encountered an error while generating this plan.

╷
│ Error: GetPartition  --->  Object partition {test_partition} does not exist
│
│   with thunder_partition.current,
│   on main.tf line 11, in resource "thunder_partition" "current":
│   11: resource "thunder_partition" "current" {
│
╵
Releasing state lock. This may take a few moments...

It seems to me that the way to fix this would be to set particular input parameters to required, rather than optional. Again, I've noticed this on both `thunder_partition` and `thunder_server` resources. I suspect it happens on several other resources as well.

[schwaboy]

This issue was resolved in v1.2.1