-
Notifications
You must be signed in to change notification settings - Fork 58
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
[BUG] Index replacement with dynamic properties #175
Comments
This is arguably not a breaking version. |
Hi same issue here. We use a separate |
As a workaround, we are trying to ignore mapping changes with:
Still under test though. |
Above has worked for us. |
When there are no documents present in the index, updating the index mapping through terraform code works as expected. The index mapping is updated successfully. Using the following terraform code, when I first create the index
The index mapping
gives
Then, I insert a document using REST API
Now the mapping is
Now when I run terraform plan
Mappings has
causing the index to be recreated on re-apply. terraform-provider-opensearch/provider/resource_opensearch_index.go Lines 368 to 373 in 174c272
OpenSearch documentation on Create or update mappings Now if I remove "ForceNew: true,"
Now the mapping still is
If documents are present in the index, we need to consult the documentation |
aws_dynamodb_table resource recommends using lifecycle ignore_changes for some arguments in certain situations https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/dynamodb_table |
What is the bug?
When mappings allows dynamic fields, a re-apply of an unchanged opensearch_index resource will detect dynamically added fields and will try to replace the index.
How can one reproduce the bug?
First create and index:
Then add a document with a field:
Re-apply the initial resource.
What is the expected behavior?
No change should be detected.
What is your host/environment?
Opensearch provider 2.2.1
Do you have any screenshots?
Do you have any additional context?
Versions before 2.2.1 of the provider do not detect changes.
I think it is related to this PR: #145
The text was updated successfully, but these errors were encountered: