Recode all current resources following this scheme

[QuentinBrosse]

Rename all current resources following this scheme :

scaleway_{namespace}_{product}_{resource}

The old resources will be kept but deprecated. This will allow the creation of resources for our new products.

Ressources

Storage

• scaleway_bucket → scaleway_object_bucket [doc: deprecate scaleway_bucket #153, feat: added scaleway_storage_object_bucket resource #150]

Compute

• scaleway_server → scaleway_instance_server [doc: deprecate resource_server #165, feat: add validationStringNotInSlice and update SDK #177, feat: scaleway_compute_instance_server #174, feat: placement group #192, feat: make volume and ip work with servers #186, doc: scaleway_compute_instance_ip #178, doc: scaleway_compute_instance_server #193]
• scaleway_ip → scaleway_instance_ip [doc: deprecate scaleway_ip #179, doc: scaleway_compute_instance_ip #178, feat: add scaleway_compute_instance_ip resource #161]
• scaleway_ip_reverse_dns → DEPRECATED (moved into scaleway_instance_ip) [doc: deprecate scaleway_ip_reverse_dns #180]
• scaleway_security_group → scaleway_instance_security_group [doc: deprecate scaleway_security_group #181, feat: add scaleway_compute_instance_security_group #189]
• scaleway_security_group_rule → DEPRECATED moved into scaleway_instance_security_group) [doc: deprecate scaleway_security_group_rule #182]
• scaleway_volume → scaleway_instance_volume [feat: added resource scaleway_compute_instance_volume #164, doc: deprecate scaleway_volume #176, doc: fix deprecate scaleway_volume #183, feat: make volume and ip work with servers #186]
• scaleway_volume_attachment → DEPRECATED (moved into scaleway_instance_server) [doc: deprecate scaleway_volume_attachment #185]
• scaleway_user_data → DEPRECIATED (moved into scaleway_instance_server) [doc: deprecate scaleway_user_data #184]
• scaleway_ssh_key → scaleway_account_ssh_key [doc: deprecate scaleway_ssh_key #148, feat: add scaleway_account_ssh_key #240]

MISC

• scaleway_token → DEPRECATED [doc: deprecate scaleway_token #145]

[abitrolly]

This will make Terraform files more verbose. What kind of servers are expected to make sense of additional namespace information in scaleway_compute_instance_server ?

[QuentinBrosse]

Hi @abitrolly,

Our provider will support more products in the near future, that's why weed need to namespace our resources. Example of another type of server who will arrive soon: scaleway_compute_baremetal_server. :)

[abitrolly]

That makes sense, yes. ) Although I would leave it as scaleway_baremetal vs scaleway_server vs scaleway_container (for kubernetes).

[QuentinBrosse]

We prefer to be a bit more explicit with this consistent scheme: scaleway_{category}_{productName}_{resourceName}.

You are right, it's a bit more verbose but it has the advantage to don't leave room for ambiguity.

[abitrolly]

If Python puts readability first, because people read code more often than write, then for Terraform it is even more important, because you have to type resource names in command line quite often too. At least I had to type "aws_instance" a few times a month on my previous job. Now I will need to remember "scaleway_compute_instance_server", "scaleway_compute_instance" or whatever..

I think it is possible droping to "scaleway_compute_instance" and "scaleway_compute_baremetal", because "server" is to vague. DevOps could use more fine grained terminology already.

[QuentinBrosse]

@abitrolly we are in reflexion to remove the product category from the resource name. The scaleway_{category}_{productName}_{resourceName} scheme could became scaleway_{productName}_{resourceName}..

It is not acted yet, but we are thinking about it.

[QuentinBrosse]

@abitrolly we will do it: scaleway_{category}_{productName}_{resourceName} scheme became scaleway_{productName}_{resourceName}.