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
The lack of Elasticsearch 5 as a source prevents users from performing multi-version hops during migrations to the latest version of OpenSearch.
What solution would you like?
I would like all products within the migration repo to support multi-version hops, allowing users to directly migrate to the latest version of OpenSearch from ElasticSearch 5.x (which may include indices created in Elasticsearch 2.x and its equivalent Lucene version). This should be supported across all migration paths, including metadata migrations, existing data migrations with RFS, and live capture with Capture and Replay.
Additionally, while not all transformations required for metadata, existing data, and live traffic will be supported "out of the box," there should be a mechanism for users performing such migrations to add custom transformations to the OpenSearch-Migrations transformation framework. This would allow for flexibility in handling unique data structures or transformations that may be required for successful migration.
What alternatives have you considered?
An alternative would be performing step-by-step migrations through intermediate versions, but this is time-consuming, complex, and could result in increased downtime or potential data inconsistencies.
Do you have any additional context?
The feature should account for the Lucene compatibility between versions and ensure that indices created in earlier versions are properly handled without the need for manual reindexing or intermediate version upgrades. This would greatly enhance user experience and reduce migration friction across metadata migrations, data migrations using RFS, and Capture and Replay features. By providing the ability for users to add transformations to the framework, we enable a more adaptable and extensible migration path for different use cases.
The text was updated successfully, but these errors were encountered:
sumobrian
changed the title
[FEATURE] Add Support for Elasticsearch 5.x to migrate to the latest version of OpenSearch 2.<latest>
Elasticsearch 5 to OpenSearch 2
Oct 23, 2024
Is your feature request related to a problem?
The lack of Elasticsearch 5 as a source prevents users from performing multi-version hops during migrations to the latest version of OpenSearch.
What solution would you like?
I would like all products within the migration repo to support multi-version hops, allowing users to directly migrate to the latest version of OpenSearch from ElasticSearch 5.x (which may include indices created in Elasticsearch 2.x and its equivalent Lucene version). This should be supported across all migration paths, including metadata migrations, existing data migrations with RFS, and live capture with Capture and Replay.
Additionally, while not all transformations required for metadata, existing data, and live traffic will be supported "out of the box," there should be a mechanism for users performing such migrations to add custom transformations to the OpenSearch-Migrations transformation framework. This would allow for flexibility in handling unique data structures or transformations that may be required for successful migration.
What alternatives have you considered?
An alternative would be performing step-by-step migrations through intermediate versions, but this is time-consuming, complex, and could result in increased downtime or potential data inconsistencies.
Do you have any additional context?
The feature should account for the Lucene compatibility between versions and ensure that indices created in earlier versions are properly handled without the need for manual reindexing or intermediate version upgrades. This would greatly enhance user experience and reduce migration friction across metadata migrations, data migrations using RFS, and Capture and Replay features. By providing the ability for users to add transformations to the framework, we enable a more adaptable and extensible migration path for different use cases.
The text was updated successfully, but these errors were encountered: