Skip to content
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] Upgrade Provider to Use Native Terraform Schema #161

Closed
jmurillo9 opened this issue Feb 27, 2024 · 3 comments
Closed

[FEATURE] Upgrade Provider to Use Native Terraform Schema #161

jmurillo9 opened this issue Feb 27, 2024 · 3 comments
Labels
enhancement New feature or request

Comments

@jmurillo9
Copy link

jmurillo9 commented Feb 27, 2024

Is your feature request related to a problem?

  • The majority of the resources available in the 2.2.0 provider require you to use an heredoc syntax where you have to put an entire JSON blob to provision the resource in question. It would be amazing if we could update the schema of all the resources so that they following the standard Terraform schema of key:value pairs.

  • The audit_config resource is already setup correctly.

What solution would you like?

  • Make all the resources follow the standard Terraform schema of key:value pairs

What alternatives have you considered?

As of right now, I have to rely on the templatefile function to render a JSON blob that works with the resource in question so that I can deploy things at scale. While I've gotten by so far, it's made the complexity of the code that much more complex and having to deal with a lot of nested objects.

@prudhvigodithi
Copy link
Member

[Triage]
Hey @jmurillo9 thanks and I agree we should transform the terraform schema of key:value pairs as much as possible but sometimes relying on templatefile or JSON blob is better for cases where we dont have to worry about adding/modifying key:value based on the OpenSearch resource changes, with this the terraform resource will not break if there is an update from OpenSearch resource. I'm open for discussion if we have to go half and half based on the scenarios. We can also discuss this in OpenSearch public slack https://opensearch.org/slack.html.

Adding @rblcoder @bbarani

@jmurillo9
Copy link
Author

Thank you for reviewing this @prudhvigodithi and the explanation. That makes sense. I suppose I didn't realize how frequent the OpenSearch resource itself would be actually changing.

@prudhvigodithi
Copy link
Member

prudhvigodithi commented Apr 2, 2024

Thanks @jmurillo9, the change depends on the release, but OpenSearch follows strict SemVer so any breaking change would be in major release. For the OpenSearch terraform provider we already have the branching
https://github.com/opensearch-project/terraform-provider-opensearch?tab=readme-ov-file#version-and-branching
https://github.com/opensearch-project/terraform-provider-opensearch/blob/main/COMPATIBILITY.md
where we can update the provider accordingly ( with add/remove/modify key:value pairs) and release it.
WDYT @jmurillo9 ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants