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

Breaking Changes Remediation for Elasticsearch to OpenSearch Migrations #1094

Open
sumobrian opened this issue Oct 23, 2024 · 0 comments
Open
Labels
enhancement New feature or request MAv4.0

Comments

@sumobrian
Copy link
Collaborator

sumobrian commented Oct 23, 2024

Is your feature request related to a problem?

When migrating from Elasticsearch to OpenSearch, users often encounter breaking changes that disrupt the migration process. These changes can involve differences in APIs, settings, mappings, and query behavior. Users face difficulties in identifying, addressing, and validating these changes, leading to migration failures or unexpected behavior in OpenSearch.

What solution would you like?

Introduce a "Breaking Changes Remediation" feature within OpenSearch Migrations that helps users identify, address, and validate breaking changes when migrating from Elasticsearch to OpenSearch. This feature should include:

  • Automated Detection of Breaking Changes: Perform a pre-migration analysis of the source Elasticsearch cluster to detect potential incompatibilities. This analysis should list all incompatible APIs, index mappings, and configuration changes that need remediation.
  • Automated Transformations and Fixes: Offer automated adjustments to configurations, mappings, and settings to align with OpenSearch standards. This could include creating new index templates or modifying existing ones to fit OpenSearch requirements.
  • Simulated Migration Environment: Allow users to simulate their migration in a sandbox environment to validate and test the changes before applying them to production.
  • Guided Workflow with Step-by-Step Remediation Recommendations: Provide an interactive workflow with clear descriptions of detected issues, recommended solutions, and actionable steps to resolve each breaking change.

What alternatives have you considered?

  1. Manual Analysis and Remediation: Users can manually review changelogs and release notes to identify potential breaking changes, but this is error-prone and time-consuming, especially for large-scale migrations.
  2. Post-Migration Issue Resolution: Addressing issues only after the migration is complete, which can lead to downtime, performance issues, and unexpected behavior in the target OpenSearch cluster.

Do you have any additional context?

This feature would be especially valuable for users migrating from Elasticsearch versions where breaking changes are known to cause disruptions in OpenSearch. By automating the detection and remediation of these changes, this feature would significantly reduce the risk of migration failures and improve overall user confidence. For instance, integrating this feature into an existing dashboard could offer users a unified view of migration tasks, potential breaking changes, and real-time validation metrics.

@sumobrian sumobrian converted this from a draft issue Oct 23, 2024
@sumobrian sumobrian changed the title Breaking Changes Remediation [FEATURE] Breaking Changes Remediation for Elasticsearch to OpenSearch Migrations Oct 23, 2024
@sumobrian sumobrian added enhancement New feature or request and removed untriaged labels Oct 23, 2024
@sumobrian sumobrian changed the title [FEATURE] Breaking Changes Remediation for Elasticsearch to OpenSearch Migrations Breaking Changes Remediation for Elasticsearch to OpenSearch Migrations Oct 23, 2024
@sumobrian sumobrian moved this from 1+ Years to 6 Months - 1 Year in OpenSearch Migrations - Roadmap Dec 15, 2024
@sumobrian sumobrian added MAv4.0 and removed MAv4.0 labels Dec 15, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request MAv4.0
Projects
Status: 6 Months - 1 Year
Development

No branches or pull requests

1 participant