[FEATURE] Project id (Service name) should not be required

[zZHorizonZz]

Description

I suggest making service_name optional, as it can be set via other methods (environment variable), the current implementation results in linting errors. Additionally, using project or project_id might better clarify the field's purpose instead of service_name.

Affected Resource(s) and/or Data Source(s)

• Most if not all public cloud resources.

[amstuta]

Hello @zZHorizonZz, thanks for your issue.

Making the service_name optional is not something we plan to do as we think the right solution is to:

• Use a variable to define this property in your resources
• Declare this variable either in your .tf files, or in an environment variable using the "real" Terraform way (export TF_VAR_service_name=...)

This way you won't have the linting errors and you're still able to define your variables from env, but the field is still required in the schemas (as it is really required to use the resources, keeping it required in the schemas seems clearer for users).

For your second point, I agree with you that it would be clearer to use project_id instead of service_name. Unfortunately, service_name is the name used everywhere across the API today, see https://eu.api.ovh.com/console/?section=%2Fcloud&branch=v1#get-/cloud/project/-serviceName- . As a result, I think we'll keep service_name for now to be consistent between the API and the terraform provider. On the bright side, the future products that will be released under cloud projects in the V2 of our API will be named correctly, see https://eu.api.ovh.com/console/?section=%2FpublicCloud&branch=v2#get-/publicCloud/project/-projectId- :)

Does that answer your remarks ?

[zZHorizonZz]

Making the service_name optional is not something we plan to do as we think the right solution is to:

Use a variable to define this property in your resources Declare this variable either in your .tf files, or in an environment variable using the "real" Terraform way (export > > TF_VAR_service_name=...)

I decided to specify the project ID and then pass it as a variable to each resource.

On the bright side, the future products that will be released under cloud projects in the V2 of our API will be named correctly, see https://eu.api.ovh.com/console/?section=%2FpublicCloud&branch=v2#get-/publicCloud/project/-projectId- :)

Nice! I didn't know a new API was in the works. It seems much cleaner than the current one, at least to me. 👍

[amstuta]

I decided to specify the project ID and then pass it as a variable to each resource.

Great, this seems like the right solution.

Nice! I didn't know a new API was in the works. It seems much cleaner than the current one, at least to me. 👍

Thanks for your feedback, having a cleaner / easier to use as-code API is our main objective ! 🙂