Secondry volume handling

[sirhopcount]

Hi, I ran into an issue while trying to create a module to provision servers on Scaleway.

Provisioning a VC1S server works like a charm but when I try to provision a VC1M server I get the following error.

* scaleway_server.server: StatusCode: 400, Type: invalid_request_error, APIMessage: The total volume size of VC1M instances must be equal to 100GB

(side note: When I check the console the server has been created, with just the 50G volume)

Apparently there are some requirements when provisioning certain server types as described here and here.

The VC1M needs a minimum of 100G of volumes attached. When creating a server via the console it automatically fills the gap by attaching the required volume.

The problem (for me at least) is that I cannot use the volume parameter in the scaleway_server resource because that would prevent me from provisioning VC1S types as these do not allow extra volumes (50G is the maximum).

I tried to working around it by creating a scaleway_volume and scaleway_volume_attachment resource and only provision them based on the type (by using count and mappings based on the type) but this doesn't prevent the error (maybe because the volume is attached after the server is create?).

Is there anyway for the provider to use the same logic as the console/scw? Ideally I would just specify the type and the provider attaches the necessary volume to meet the requirement.

---

Versions:
Terraform v0.10.7
provider.scaleway ~> 0.1.1

[nicolai86]

@sirhopcount thank you for this question.
As you said you can not use scaleway_volume_attachment due to them being attached after the server is created.

I think for now you only have the option to create two modules, one for VC1S and one for all the other types.

I want to avoid the terraform scaleway provider creating resources you did not explicitly request as this is very unexpected and confusing.

For the future this could be improved by allowing volumes with a size of 0 to disable the additional volume. This way your module could use a map and use 0 as the size of VC1S, and X for all other types.

Do you think this would solve your issue?

[sirhopcount]

hi @nicolai86, I thought about creating two modules but it didn't seem like a "clean" solution. I do understand your concern about putting the logic in the controller so it seems the best solution for now.

Allowing a volume size of 0 would indeed solve my issue.

[nicolai86]

@sirhopcount the change just landed in master - if you compile the provider yourself you can use it already, otherwise you need to wait until the next release is published.