Fix & improve state locking of OSS backend

[mlafeldt]

While using the OSS backend with Terragrunt, which can execute many Terraform modules in parallel, I found multiple bugs in the way the backend handles state locking via Tablestore.

Current behavior

Currently, the locking works as follows:

• User creates a Tablestore table with some arbitrary primary key
• The backend discovers this primary key and always writes the fixed string "terraform-remote-state-lock" to it
• The backend then tries to update/delete rows based on this primary key alone, ignoring any other attributes

Something (PK)	Digest	Info
terraform-remote-state-lock	(empty)	{ID: ...}
terraform-remote-state-lock-md5	<hash>	(empty)

This won't work when having more than one lock in the table at a time. What the backend actually does is provide a global lock for Terraform, not per-module locking.

For the same reason, MD5 hashing is broken as there can only be one hash at a time.

New behavior

This PR changes the logic to follow the more obvious data model of DynamoDB, which requires users to create a Tablestore table with a primary key named LockID:

LockID (PK)	Digest	Info
<statefile-path>	(empty)	{ID: ...}
<statefile-path>-md5	<hash>	(empty)

Note that this breaks backward compatibility since the schema of the Tablestore table is different. I tried to fix the backend without having to change the schema, but couldn't make it work, even with additional row conditions/filters.

Tests are passing too:

$ TF_ACC=1 go test ./backend/remote-state/oss/
ok      github.com/hashicorp/terraform/backend/remote-state/oss 24.788s

cc @arafato @xiaozhu36

[mlafeldt]

I also added a test that shows the buggy behavior fixed by the PR. PTAL.

[mlafeldt]

@apparentlymart @pselle Is there anything I can do to move this forward?

[xiaozhu36]

HI @mlafeldt Thanks for your contribution and I have a question that what do you mean "this breaks backward compatibility since the schema of the Tablestore table is different. I tried to fix the backend without having to change the schema, but couldn't make it work, even with additional row conditions/filters." ? Does it effect the existing state and lock?

[mlafeldt]

Does it effect the existing state and lock?

Yes, that's what I meant with breaking backward compatibility. Users have to create a new TableStore table with a primary key named LockID (see my doc changes). As I wrote, I tried to fix the code without breaking the schema, but I don't think it's possible given that the PK is currently hard-coded.

[xiaozhu36]

@mlafeldt Ok. Thanks for you feedback.

[danieldreier]

@mlafeldt I wanted to check in here as the Terraform Core engineering manager. Thank you for contributing this improvement! @pkolyvas, our product manager, prompted @xiaozhu36 for review after you reached out, because he's the original author of the backend. I'm going to prompt the core team to review this now that he's approved it.

[jbardin]

Thanks for the contribution @mlafeldt, and the review @xiaozhu36 !

The master branch is the in-progress work for the 0.13 release, and this will be included in the next major release. This PR cannot be backported to the 0.12 release branch due to the backwards incompatible change.

Thanks!

[ghost]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.