backend/tikv: Add TiKV as remote state backend

[yufeiminds]

Hello,

We are working in progress about tikv as a remote state backend. Locking is supported.

Additional information:

TiKV is an open-source, distributed, and transactional key-value database.

The design of TiKV ('Ti' stands for titanium) is inspired by some great distributed systems from Google, such as BigTable, Spanner, and Percolator, and some of the latest achievements in academia in recent years, such as the Raft consensus algorithm.

TiKV is an incubating project of the Cloud Native Computing Foundation (CNCF).

Question:

There is some problem with the dependencies in vendor, tikv client has used the different version of github.com/ugorji/go package, it will cause the error about this:

panic: codecgen version mismatch: current: 8, need 10. Re-generate file: /Users/yufeiminds/code/learn/terraform/vendor/github.com/coreos/etcd/client/keys.generated.go

In this PR, etcd has been removed ugorji/go as dependencies. So can we upgrade the version of etcd to the latest? Should we put it into another pull request, or in this?

NOTE: we had resolved conflict error by upgrading etcd version to v3.3.18.

Looking forward to your reply and code review.

Best Regards.

[hashicorp-cla]

All committers have signed the CLA.

[wangrzneu]

We update etcd version to v3.3.18 and fix the github.com/ugorji/go version conflict issue.

[yufeiminds]

@pselle @jbardin

Anyone can help us to review the tikv backend? Thanks 😄

Looking forward to your reply and code review.

[wangrzneu]

@danieldreier
Can you help to review this PR? Thanks.

[danieldreier]

Hello @yufeiminds and @wangrzneu -

I really appreciate you making an effort to contribute to Terraform, and to build an integration with an exciting project. I’m personally very excited about TiKV - it seems architecturally well thought out, seems to have a lot of adoption in China in particular, and the idea of a really scalable cross-cloud open source KV store is really exciting. Unfortunately, we’re not going to be able to accept this PR, and I want to explain why, and what your options are.

When we adopt new state backends in Terraform core, we take on significant responsibility, because problems with state backends significantly impact users. At the same time, it’s very difficult for us to maintain community-contributed state backends, because we have to maintain code and handle bug reports for integrations we lack domain knowledge in. We’ve tried, and it has been unsatisfactory for our users, open source contributors, and our engineers.

For example, we’ve found that subtle locking bugs are almost inevitable: even very good engineers often miss them, and when we accept community-contributed state backends, we end up responsible for testing and validation of distributed systems that we lack domain knowledge in. This part of the codebase is relatively hard to get right, and bugs in it have an extremely high impact on users. Our experience has been that we cannot guarantee the high quality that users need when we accept third party state backends, and so we have made the difficult decision to stop accepting new community-contributed state backends.

In the future, we are hoping to build a plugin system, similar to the provider system, for allowing external contributors to build state backend plugins that are not built into Terraform core. When that happens, I hope you will build a state backend for TiKV.

Until we have built a plugin system, we will not be accepting any new state backends that are not maintained by HashiCorp employees, and so I am closing this pull request. If you would like to discuss this further, feel free to reach out to me at ddreier@hashicorp.com or to Petros Kolyvas, our Product Manager, at petros@hashicorp.com.

[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.