Comments (4)
Hi, thanks for the interest! Please see the discussion here: phillbaker/terraform-provider-elasticsearch#299
The current plan is to merge the existing opensearch/opendistro resources from that provider into this repo as it has decent coverage.
I do like how you've broken out the attributes for ISM policy, instead of using just a json text blob: https://github.com/Ferlab-Ste-Justine/terraform-provider-opensearch/blob/main/provider/resource_opensearch_ism_policy.go
Perhaps we can take a look at integrating that work into this provider!
from terraform-provider-opensearch.
I'm glad to hear it. I was afraid there would be a lot of opacity around the progress of this project and that we'd have to support our own provider separately for a while longer before ultimately switching.
While not a universally popular opinion I'm sure, I'm personally relieved to hear that this provider will be focused on opensearch given that increasingly, opensearch and elasticsearch will diverge (it is actually the main reason why I decided to start our own repo instead of contributing back to your repo as I was unsure of the long term prospect of supporting both in the same provider). It will keep things simpler I think.
I'll be happy to assist in any way you require with the integration of what we've done with the ism policy (or anything else really) once you are ready.
Two points that I'll mention:
- I initially tried your provider before starting our own, I had an opensearch version error with our on prem opensearch 2.2.1 (https://github.com/Ferlab-Ste-Justine/kvm-opensearch-server)
- I'm wondering what the sdk situation will be. There is an official opensearch one, but it is incomplete (ex: opensearch-project/opensearch-go#94), otherwise I would probably have used that one my end. I guess there will be some focus on adding missing functionality to it and ultimately using it?
from terraform-provider-opensearch.
Sorry for the slow reply.
I had an opensearch version error with our on prem opensearch 2.2.1
Hi, yes, that's likely due to this line: https://github.com/phillbaker/terraform-provider-elasticsearch/blob/1ff79e7de71161651f5fe64d73366aab778ea663/es/provider.go#L478. We don't have testing support yet for OpenSearch 2.x and it does have breaking api features, so the provider hasn't incorporated support for it.
I'm wondering what the sdk situation will be
This is a great question. As you alluded to, there's not a great solution currently. For now, my thinking is that the sdk is an implementation detail which should not impact the external API of the provider. To that end, as things improve, we can consider replacing the current olivere/elastic client with something that's maintained and specific to opensearch.
What do you think?
from terraform-provider-opensearch.
Sorry for the slow reply.
No worries.
Hi, yes, that's likely due to this line: https://github.com/phillbaker/terraform-provider-elasticsearch/blob/1ff79e7de71161651f5fe64d73366aab778ea663/es/provider.go#L478. We don't have testing support yet for OpenSearch 2.x and it does have breaking api features, so the provider hasn't incorporated support for it.
So far, I validated manually on a local terraformed libvirt/kvm setup for opensearch 2.2.1 (it has worked well enough for my solo development efforts, but I'll be the first to admit that it doesn't scale the way automated integration/functional tests do when many developers with varying amounts of meticulousness get involved).
I don't think the libvirt/kvm setup, while practically like production in our case, would be great for a testing pipeline, but we could have a more lightweight dockerized setup integrated directly into github actions.
If you point me to a shared working space, I could look into integrating that after I'm back from vacation if you like.
This is a great question. As you alluded to, there's not a great solution currently. For now, my thinking is that the sdk is an implementation detail which should not impact the external API of the provider. To that end, as things improve, we can consider replacing the current olivere/elastic client with something that's maintained and specific to opensearch.
What do you think?
Makes sense.
I started on our end implementing missing pieces of the opensearch sdk in our provider for what we needed. I'll see what adapting them to the official sdk and getting them merged will entail when I'm back.
I guess as soon as the missing api surface is implemented, we can more seriously consider swapping.
from terraform-provider-opensearch.
Related Issues (20)
- [BUG]Provider produced inconsistent final plan HOT 2
- [BUG] Allow host_override outside of AWS
- [UPGRADE] Update the Project go version to 1.22 HOT 1
- [BUG] dependency when destroy a component_template and it usage in a composable_index_template HOT 1
- [BUG] Terraform state for opensearch_index resource should include aliases on import HOT 1
- [FEATURE] possibility to attach user to role (not backend role) HOT 7
- [BUG] Invalid character '<' looking for beginning of value HOT 6
- [BUG] panic: set item just set doesn't exist HOT 5
- [BUG] Cannot create index with opensearch serverless collection HOT 4
- Release v2.3.0 OpenSearch Terraform Provider. HOT 3
- [FEATURE] retries implemented, or max_retries configable if retry already implemented HOT 1
- [BUG] With version 2.3.0 of the provider, the ressource opensearch_channel_configuration cannot be applied when assuming an iam role in the provider HOT 3
- [BUG] what is "registry.terraform.io/hashicorp/opens" HOT 1
- [FEATURE] Add cluster.routing.allocation.awareness.force.zone.values to the provider as a cluster setting HOT 1
- [FEATURE] Terraform support for ML commons plugin HOT 1
- [BUG] Intermittent checksum failures with provider break CI/CD pipelines HOT 1
- [BUG]: Opensearch dashboard creation through terraform HOT 10
- [Bug] Add support for NDJSON files for opensearch_dashboard_object creation HOT 2
- [BUG] NoCredentialProviders for assuming role in provider HOT 1
- [FEATURE] Add GPG key for use with OpenTofu's registry
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from terraform-provider-opensearch.