Docs feedback - feature proposal: Terraform backend supporting multiple workspaces
Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.
Problem to solve
My current workflow with Terraform is to have multiple workspaces for each environment, say dev/staging/prod for example, or even going to the level dynamic workspaces for completely emphemeral review app environments. The HTTP backend support currently provided does not allow for multiple workspaces, preventing me from being able to use GitLab as my state backend. This feature maybe was never intended to compete with something like terraform cloud, but even the s3 backend allows multiple workspaces. A list of backends that support multiple workspaces can be found here: https://www.terraform.io/docs/state/workspaces.html
Intended users
User experience goal
Proposal
Implement a more fully featured backend that can support the backend interface that allows for managing multiple workspaces, and the separate states of those workspaces.
This appears to be the interface: https://github.com/hashicorp/terraform/blob/master/backend/backend.go
The other option would be to see about contributing changes back upstream to the HTTP backend that allow it to support workspaces. This might be the easier approach if workspace management over REST isn't very difficult.
Further details
Allowing for multiple backends lets the same terraform code be exercised across a dev or staging environment before pushing the same terraform change to production. Without workspaces, this is not currently possible to do within a project based on it appearing that a single project has a single state store.
This is a good resource on describing some more uses for multiple workspaces: https://www.terraform.io/docs/state/workspaces.html#when-to-use-multiple-workspaces
Permissions and Security
I expect this to impact the following group sets.
-
Add expected impact to members with no access (0) -
Add expected impact to Guest (10) members -
Add expected impact to Reporter (20) members -
Add expected impact to Developer (30) members -
Add expected impact to Maintainer (40) members -
Add expected impact to Owner (50) members
I would assume that following the existing security standards, it would require maintainer privileges to create and destroy workspaces.
Documentation
This will require updating the existing GitLab Terraform state backend docs to reflect the different backend type and the support for multiple workspaces. The current docs don't actually call out the lack of multiple workspace support, so that might be a good update as well.
Availability & Testing
What does success look like, and how can we measure that?
I would expect success would look like the ability to use GitLab as a Terraform state store that has workspace support. I guess you would measure if there is more uptake on using the GitLab state store?
What is the type of buyer?
¯\＿(ツ)＿/¯
Is this a cross-stage feature?
¯\＿(ツ)＿/¯