Description
Hello,
Current Terraform Version
Terraform v1.4.0-dev
Use-cases
Let the HTTP backend support workspaces
Attempted Solutions
Adding a new URL parameters and use OPTIONS and DELETE HTTP methods to call remote HTTP endpoint to handle workspaces.
Proposal
Here is another take to HTTP remote backend workspace handling by passing workspace information as query param.
I worked on this prior viewing #26032 .
Nevertheless, this version was influenced by the lock implementation that pass the LockID information as query parameter on all subsequent requests.
Therefore, this version passes the workspace also as query parameter to all operations if workspace is not the default one, enabling the remote HTTP endpoint to act accordingly with minimal user configuration:
No need to specify a workspace path parameter, implementation is left to the remote HTTP endpoint.
If workspaces_address is enabled, Terraform act as if workspaces are enabled and will:
- use by default the
OPTIONSHTTP method to list current workspaces. - use the
DELETEHTTP method to remove a workspace.
If workspaces_address is not enabled, workspace are disabled.
A simple backend configuration could then be:
terraform {
backend "http" {
address = "http://myrestapi.example.com/foo"
lock_address = "http://myrestapi.example.com/foo"
unlock_address = "http://myrestapi.example.com/foo"
workspaces_address = "http://myrestapi.example.com/foo"
}
}Also, workspaces handling can be enabled on default address through the workspaces setting.
terraform {
backend "http" {
address = "http://myrestapi.example.com/foo"
lock_address = "http://myrestapi.example.com/foo"
unlock_address = "http://myrestapi.example.com/foo"
workspaces = true
}
}My draft pull request can be found here : #26796
References
I opened this issue so that we can discuss as suggested in the contribute guide