Location: LATAM
Remote: Yes
Willing to relocate: Yes
Technologies: Have a look at the CV, please! :)
Résumé/CV: https://hackmd.io/@WCIqDpwQQ_uC3Zv3IPK-0A/cv_hn_aug_2021
Email: pplanel@gmail.com
workspaces are specifically _not_ intended to be used as environment replacements. And it wouldn't have caught the OPs issue to begin with. His problem was he didn't read the plan, because it's pretty basic that any change of a resource name or a change of type equates deletion and TF will report back saying it will destroy a resource that is missing in the config but in the state.
To solve his problem, after switching to the data source type from resource he needed to manually run `terraform state rm` to get rid of the resource from the state.
> workspaces are specifically _not_ intended to be used as environment replacements.
From Terraform's "An Overview of Our Recommended Workflow"[1]:
"The best approach is to use one workspace for each environment of a given infrastructure component. Or in other words, Terraform configurations * environments = workspaces."
So 1 workspace != 1 environment but workspaces are indeed intended to handle multiple environments.
I've personally struggled with managing multiple environments using Terraform so I'm interested in what the best practices are.
Can you elaborate on why terraform workspaces are not intended to be used for environments? I use it exactly for this use case. Same terraform config deploying to production and staging, each maintaining its own state in a separate workspace.
