Update README.md #662
Update README.md #662
Conversation
README.md
Outdated
| @@ -21,6 +21,11 @@ Things which are out of scope for provider: | |||
|
|
|||
| We now have Terraform provider for Elastic Stack https://github.com/elastic/terraform-provider-elasticstack which should be used for any operations on Elastic Stack products. | |||
|
|
|||
| ## Support | |||
|
|
|||
| Support tickets related to the terraform provider can be opened with Elastic, however, since terraform is a 3rd party tool (by Hashicorp) which Elastic has no full control over, we will not be able to treat support requests as severity-1(immediate time frame). Also, since urgent production-related terraform issues can be resolved via regular API or UI interaction, we ask customers to resort to such methods in case of urgent deployment downtime or issue. | |||
There was a problem hiding this comment.
So we don't publicly announce such a policy on other client repositories. I'm curious about why we need to do so here?
however, since terraform is a 3rd party tool (by Hashicorp) which Elastic has no full control over
I don't think it's helpful to base the policy on this. The same argument could be made for Elasticsearch, the operating system is a 3rd party tool we have no control over. There's a clearly defined API between Terraform and the provider, we test against that API, in theory we should stand behind that testing. This argument just sounds like we're terrible software engineers.
Also, since urgent production-related terraform issues can be resolved via regular API or UI interaction, we ask customers to resort to such methods in case of urgent deployment downtime or issue.
If we're to have this caveat on the repo, we should base it on this. The initial aim for sev1's is to restore normality by any means available, since we can restore normality by bypassing Terraform, a provider bug can't be classed as a sev1.
Related to that, let's assume there was a provider bug which resulted in deployments being terminated. A customer should quite rightly be able to open a sev1 about such a bug. There is no public facing API to restore a terminated deployment, and we would absolutely work on fixing the provider bug immediately.
It's not clear why we need this caveat in the provider repos, but not in other clients? I think it's potentially misleading i.e there's situations where a sev1 is likely the right thing to do.
Finally, the logic presented in this PR is IMO damaging to the reputation of our engineering team. If we need to include this warning, we should do so based on the availability of alternate management methods, not because we don't trust our product to adhere to an API.
There was a problem hiding this comment.
@Kushmaro
Sorry to trouble you directly.
Similar to the terraform provider - elastic stack one (elastic/terraform-provider-elasticstack#346), Toby and I had an internal discussion and he suggested asking for your follow up on how we want to organize the public statement.
The comment for reference - https://github.com/elastic/terraform-provider-ec/pull/662/files#r1217586538
Please let us know if anything is not clear or if you prefer to discuss this internally and thanks!
Also thanks @tobio for the detailed comment and internal discussion! 🙏
Update to complete the support related statement
There was a problem hiding this comment.
@tobio
Sorry for the delay.
I updated the statement based on our internal discussion.
When you have time, may I ask for your help to give a 2nd review please? 🙏
Thanks!
Description
Per an internal discussion earlier.
Related Issues
Motivation and Context
How Has This Been Tested?
Types of Changes
Readiness Checklist