Add workspaces support to HTTP backend

[lenaing]

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 OPTIONS HTTP method to list current workspaces.
• use the DELETE HTTP 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

• backend/http workspace support #26032
• Add workspaces support to HTTP backend #26796

I opened this issue so that we can discuss as suggested in the contribute guide

[pkolyvas]

Thanks for submitting this proposal @lenaing

I just wanted to chime in here that we are currently in the rundown to our 0.14 GA release.

What that means here is that we can't promise any focused attention for the next 4-6 weeks. It doesn't mean you won't get any, but rather I just wanted to make sure that it didn't look like we were ignoring your work here while our focus is elsewhere.

We very much appreciate you taking the time to offer a proposal for discussion here.

[thor]

Is there anything the community can assist with that relates to this issue, @pkolyvas?

[tchiotludo]

Anyone from hashicorp here ?
There is 2 different PR without any review and it's a real need for everyone that can't trust actual backend.
HTTP backend is the only solution and workspace is must have.

[zeitounator]

Are there any plans to review the 2 related PRs and propose a support for workspaces for the http backend any time soon? All of this was proposed in Aug-Nov 2020, we are more than a year later. At the very least, can you give us some official light on the subject. Thanks in advance.

[pacecreative]

With Gitlab supporting Gitlab-hosted state files, it's only available with an http backend. So workspaces is a no-go currently and we have to choose between keeping S3 or changing our codebase to remove all references to workspaces. Would really prefer to use Gitlab state files without needing to change our pipelines and our codebase.

[fstamour]

I'm in the exact same situation as @quixoticotech . Workspaces support for the http backend is a must.

[anatoli-klamer]

The same issue with gitlab, we can't use workspaces without support for http backend

[brittandeyoung]

Any traction on this? We currently write our own custom module registry and would like to do the same for state storage; however, not being able to use work spaces is not an option for us.

I would be glad to help support this in any way including writing code for this support and supporting it.

The fact that the contributors guide states that no new backends will be accepted, and there is no backend that doesn't require remote execution that supports workspaces is a real bummer.

[bephinix]

The Terraform team is not merging PRs for new state storage backends at the current time. Our priority regarding state storage backends is to find maintainers for existing backends and remove those backends without maintainers.

Please see the CODEOWNERS file for the status of a given backend. Community members with an interest in a particular standard backend are welcome to help maintain it.

AFAICS, HTTP Backend is currently maintained by Terraform Core.
Providing assistance for supporting workspaces for http backend seems to be in accordance to the contributors guide for me.

@lenaing Is your PR still functional?

Support for Workspaces using the HTTP Backend would be great.
Maybe we can revive this issue. 👍🏻

[lenaing]

Hello there.

Just rebased from main for this 2 years birthday 🍰 : #26796

Edit: From Terraform v0.14.0-dev to Terraform v1.4.0-dev ✨🎉!

Kind regards,

[djmcgreal-cc]

Surely HTTP backend is popular enough to warrant workspace support? Who can we @?

[djmcgreal-cc]

Guess not!

[soar]

This problem became more actual because of the latest changes in some cloud services plans.

[fstamour]

Just want to add that I've been forced recently to switch from S3 backend to an http backend and the lack of workspaces makes my life much much more painful :(

[durcon]

After 4 years, is there any plan to solve this issue? Any roadmap?