-
Notifications
You must be signed in to change notification settings - Fork 9.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature/mysql state backend #24647
Feature/mysql state backend #24647
Conversation
…dron/terraform into feature/mysql-state-backend
…feature/mysql-state-backend
…raform into feature/mysql-state-backend
Hi @dihedron - I really appreciate you making an effort to contribute to Terraform, and to build a MySQL state backend. Your motivation here makes sense to me - a lot of people use MySQL, and it's available just about everywhere. 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 is available, I hope you will build a MySQL state backend in that system. 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. We do understand why people want to store state in additional backends, so it was difficult to come to this conclusion. I apologize for how long it has taken me to respond to your PR. If you would like to discuss this further, feel free to reach out to me at [email protected] or to Petros Kolyvas, our Product Manager, at [email protected]. |
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. |
This pull requests provides an implementation of the MySQL remote state backend, with support for locking; it is largely based on the PostgreSQL backend, with small changes to the SQL syntax and to the advisory locks which are slightly different; we are testing it on our development systems.
Please see issue #23531 where I made the proposal.
Hope this helps!