You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This sort of relates to [FEATURE] Upgrade Provider to Use Native Terraform Schema #161 that I recently submitted. Within the OpenSearch UI, you are able to configure a handful of items and export them as JSON which might be why the current state of the provider is the way it is. Trying to perform complex loops within "native Terraform (HCL)" could become cumbersome at times and so having a multi-language provider could potentially help make things easier using native programming languages?
What solution would you like?
Allow for multi-language support when provisioning resources within OpenSearch. TypeScript first would be ideal followed by Python then GoLang.
What alternatives have you considered?
Continue using the current provider as is (which I am and very thankful for 🙂 ).
Do you have any additional context?
I'm not sure if this will open up a can of worms because of licensing, etc. so I apologize in advance and thank you for taking the time to review this.
For AWS customers, we have the ability to deploy a new OpenSearch domain using the AWS provider but then are at a standstill. The IaC provisioning process ends there. Luckily, we have this provider ( opensearch-project/opensearch) which now enables customers to continue configuring their environment using similar standards that they would with anything else they deploy in AWS. The AWS provider has been updated recently to support multi-language for those people who want to take more of a native programming approach.
Does it make sense to add multi-language support into this provider?
This one will might get some backlash but has there been any conversations in the past about whether or not to add this into the AWS provider itself? I'm not promoting one way or the other, mostly just curious.
The text was updated successfully, but these errors were encountered:
[Triage]
Hey @jmurillo9 thanks for opening this issue, I'm open to learn and explore adapting to multi-language OpenSearch provider if that helps making the provider more robust and easy to use. Also @jmurillo9 since you are familiar with multi-language provider can you please put the advantages and required code changes for this, so that we can brainstorm the ideas and if you are interested you can contribute to this multi-language provider. We can also discuss this in OpenSearch public slack https://opensearch.org/slack.html
Thanks
Adding @bbarani@rblcoder
Is your feature request related to a problem?
What solution would you like?
What alternatives have you considered?
Do you have any additional context?
I'm not sure if this will open up a can of worms because of licensing, etc. so I apologize in advance and thank you for taking the time to review this.
opensearch-project/opensearch
) which now enables customers to continue configuring their environment using similar standards that they would with anything else they deploy in AWS. The AWS provider has been updated recently to support multi-language for those people who want to take more of a native programming approach.The text was updated successfully, but these errors were encountered: