feat: added doc for migrate es to os #109
Conversation
WalkthroughA comprehensive migration guide document is added detailing two primary paths for migrating from Elasticsearch to OpenSearch: ES 7.10 to OpenSearch 3.x via snapshot restore, and ES 8.x/9.x to OpenSearch 3.x via reindex from remote. The guide includes prerequisites, step-by-step procedures, YAML examples, and client migration compatibility information. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Pull request overview
This PR adds comprehensive documentation for migrating from Elasticsearch to OpenSearch, covering multiple migration paths depending on source and target versions.
Changes:
- Added detailed migration guide documenting two primary scenarios: ES 7.10 → OS 2.x → OS 3.x using Snapshot & Restore, and ES 8.x/9.x → OS 3.x using Reindex from Remote
- Included step-by-step procedures with configuration examples for plugin installation, S3 credentials setup, snapshot creation, restoration, and cluster upgrades
- Provided client migration guidance with references to official OpenSearch clients for multiple programming languages
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| curl -k -X POST "https://localhost:9200/_snapshot/migration_repo/snapshot_1/_restore" \ | ||
| -u "admin:admin" \ |
There was a problem hiding this comment.
The command references hardcoded credentials 'admin:admin'. For production documentation, consider adding a note about replacing these with actual credentials or referencing environment variables to avoid users accidentally using default credentials in production environments.
| 1. **Elasticsearch 7.10 → OpenSearch 2.x → OpenSearch 3.x**: Using Snapshot & Restore (two-phase migration) | ||
| 2. **Elasticsearch 8.x/9.x → OpenSearch 3.x**: Using Reindex from Remote | ||
|
|
||
| It also includes client migration guides for Java, Python, and Golang. |
There was a problem hiding this comment.
The introduction mentions "Java, Python, and Golang" but the clients table later includes many more languages (JavaScript, Ruby, PHP, .NET, Rust, Hadoop). Either update the introduction to reflect all supported languages or clarify that only Java, Python, and Golang are covered in detail.
| It also includes client migration guides for Java, Python, and Golang. | |
| It also includes client migration guides, with detailed examples for Java, Python, and Golang. |
| ``` | ||
|
|
||
| :::note | ||
| All three approaches will trigger a rolling restart of nodes to load the newly installed plugin. |
There was a problem hiding this comment.
The note mentions "All three approaches" but only two approaches are shown in the surrounding context: ES 7.10 Helm Chart configuration and OpenSearch Operator configuration. This reference is unclear and may confuse readers.
| All three approaches will trigger a rolling restart of nodes to load the newly installed plugin. | |
| Both approaches will trigger a rolling restart of nodes to load the newly installed plugin. |
| bootstrap: | ||
| pluginsList: | ||
| - https://artifacts.opensearch.org/releases/plugins/repository-s3/2.19.3/repository-s3-2.19.3.zip | ||
| general: | ||
| additionalConfig: | ||
| s3.client.default.endpoint: "http://minio.example.com:9000" | ||
| s3.client.default.region: "us-east-1" | ||
| s3.client.default.path_style_access: "true" | ||
| pluginsList: | ||
| - https://artifacts.opensearch.org/releases/plugins/repository-s3/2.19.3/repository-s3-2.19.3.zip | ||
| ``` |
There was a problem hiding this comment.
The pluginsList is duplicated in both the bootstrap and general sections with the same URL. This redundancy may cause confusion. Typically, pluginsList should be specified in one location (either bootstrap.pluginsList or general.pluginsList) in the OpenSearchCluster CR.
| nodeSets: | ||
| - name: default | ||
| count: 3 | ||
| config: |
There was a problem hiding this comment.
The YAML configuration is missing a colon after the 'config:' field on line 393. This will cause a YAML parsing error. The line should likely contain configuration values or be removed if not needed.
| config: | |
| config: {} |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 Fix all issues with AI agents
In
`@docs/en/solutions/ecosystem/opensearch/How_to_Migrate_from_Elasticsearch_to_OpenSearch.md`:
- Around line 376-414: The YAML for the Elasticsearch resource has mis-indented
fields under the nodeSet named "default": the config and podTemplate blocks must
be nested under the same list item for nodeSets (the block starting with - name:
default) so that podTemplate and config are children of that nodeSet; fix the
indentation to move config: and podTemplate: beneath the "- name: default" entry
(or remove the empty config: if you don't need it) so the Elasticsearch kind's
nodeSets, config, and podTemplate structure is valid.
- Around line 504-510: Update the reference URLs in the References section so
they use the correct docs.opensearch.org domain: replace
`https://opensearch.org/docs/latest/upgrade-or-migrate/` with
`https://docs.opensearch.org/latest/upgrade-or-migrate/` and
`https://opensearch.org/docs/latest/api-reference/document-apis/reindex/` with
`https://docs.opensearch.org/latest/api-reference/document-apis/reindex/`; also
scan the remaining links in the same list (`Snapshot and Restore`, `Keystore
Management`, `OpenSearch Clients`) and change any
`https://opensearch.org/docs/...` occurrences to
`https://docs.opensearch.org/...` so all reference URLs use the proper domain.
- Around line 126-142: The YAML example redundantly lists the same repository-s3
plugin under spec.bootstrap.pluginsList and spec.general.pluginsList; remove the
spec.bootstrap.pluginsList entry so the plugin is only declared under
spec.general.pluginsList (keep the
https://artifacts.opensearch.org/.../repository-s3-2.19.3.zip line in
spec.general.pluginsList and delete the duplicate under
spec.bootstrap.pluginsList) to avoid duplicate installation and
bootstrap-related reliability issues.
🧹 Nitpick comments (4)
docs/en/solutions/ecosystem/opensearch/How_to_Migrate_from_Elasticsearch_to_OpenSearch.md (4)
11-11: Clarify operator version applicability.The version statement indicates "OpenSearch Operator ~= 2.8.*", but the examples throughout the document use OpenSearch versions 2.19.3 and 3.3.1. Ensure this version constraint accurately reflects the tested/supported operator versions. If the guide supports a broader range of operator versions, consider updating this line.
228-234: Consider documenting asynchronous snapshot creation for large datasets.The example uses
wait_for_completion=true, which may cause timeout issues for large clusters. Consider adding a note that users can setwait_for_completion=falseand monitor progress separately using the Snapshot Status API for production environments with large datasets.
273-280: Use placeholder credentials in documentation examples.The example uses hardcoded
admin:admincredentials. While these are example credentials for documentation purposes, consider using placeholders like<username>:<password>to avoid confusion and prevent accidental copy-paste of insecure credentials in production environments.📝 Suggested improvement
-curl -k -X POST "https://localhost:9200/_snapshot/migration_repo/snapshot_1/_restore" \ - -u "admin:admin" \ +curl -k -X POST "https://localhost:9200/_snapshot/migration_repo/snapshot_1/_restore" \ + -u "<username>:<password>" \ -H 'Content-Type: application/json' -d'
305-313: Consider usingjqfor more robust JSON parsing.The sed-based approach to extract mappings (line 306-307) is fragile and may break with formatting changes or unexpected JSON structure. Consider using
jqfor more reliable JSON manipulation.🔧 More robust alternative using jq
-# 1. Get the original index mapping and extract the mappings object using sed -curl -s -X GET "https://localhost:9200/migration_test/_mapping" -u "admin:admin" -k | \ - sed 's/^{"migration_test"://' | sed 's/}$//' > mapping.json +# 1. Get the original index mapping and extract the mappings object using jq +curl -s -X GET "https://localhost:9200/migration_test/_mapping" -u "<username>:<password>" -k | \ + jq '.migration_test' > mapping.jsonThis also addresses the hardcoded credentials issue.
📜 Review details
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
docs/en/solutions/ecosystem/opensearch/How_to_Migrate_from_Elasticsearch_to_OpenSearch.md
🧰 Additional context used
🪛 Gitleaks (8.30.0)
docs/en/solutions/ecosystem/opensearch/How_to_Migrate_from_Elasticsearch_to_OpenSearch.md
[high] 273-274: Discovered a potential basic authorization token provided in a curl command, which could compromise the curl accessed resource.
(curl-auth-user)
[high] 288-288: Discovered a potential basic authorization token provided in a curl command, which could compromise the curl accessed resource.
(curl-auth-user)
[high] 291-291: Discovered a potential basic authorization token provided in a curl command, which could compromise the curl accessed resource.
(curl-auth-user)
[high] 306-306: Discovered a potential basic authorization token provided in a curl command, which could compromise the curl accessed resource.
(curl-auth-user)
[high] 310-311: Discovered a potential basic authorization token provided in a curl command, which could compromise the curl accessed resource.
(curl-auth-user)
[high] 316-317: Discovered a potential basic authorization token provided in a curl command, which could compromise the curl accessed resource.
(curl-auth-user)
[high] 325-325: Discovered a potential basic authorization token provided in a curl command, which could compromise the curl accessed resource.
(curl-auth-user)
[high] 326-327: Discovered a potential basic authorization token provided in a curl command, which could compromise the curl accessed resource.
(curl-auth-user)
[high] 339-339: Discovered a potential basic authorization token provided in a curl command, which could compromise the curl accessed resource.
(curl-auth-user)
[high] 363-363: Discovered a potential basic authorization token provided in a curl command, which could compromise the curl accessed resource.
(curl-auth-user)
[high] 364-364: Discovered a potential basic authorization token provided in a curl command, which could compromise the curl accessed resource.
(curl-auth-user)
🔇 Additional comments (3)
docs/en/solutions/ecosystem/opensearch/How_to_Migrate_from_Elasticsearch_to_OpenSearch.md (3)
150-211: LGTM! Clear security-focused credential management.The section correctly emphasizes using keystore/secrets instead of including credentials in API request bodies. The examples for both Elasticsearch and OpenSearch are clear and follow security best practices.
344-356: LGTM! Clear upgrade procedure.The upgrade procedure correctly updates both the OpenSearch version and the matching repository-s3 plugin version. The operator will handle the rolling upgrade automatically.
1-510: Well-structured comprehensive migration guide.This document provides thorough coverage of ES to OpenSearch migration scenarios with clear, actionable steps. The two-phase approach for ES 7.10 migration is well-explained, and the inclusion of client migration guidance adds significant value.
Strengths:
- Clear compatibility warnings preventing common pitfalls
- Comprehensive examples for different deployment methods (Helm, Operator, ECK)
- Appropriate security practices (keystore/secrets over hardcoded credentials)
- Well-organized with logical flow and helpful diagrams
Areas addressed in review comments:
- Technical accuracy improvements (YAML syntax, JSON parsing)
- Documentation best practices (credential placeholders)
- Verification requests for external dependencies
✏️ Tip: You can disable this entire section by setting review_details to false in your review settings.
| ```yaml | ||
| apiVersion: opensearch.opster.io/v1 | ||
| kind: OpenSearchCluster | ||
| metadata: | ||
| name: my-cluster | ||
| spec: | ||
| bootstrap: | ||
| pluginsList: | ||
| - https://artifacts.opensearch.org/releases/plugins/repository-s3/2.19.3/repository-s3-2.19.3.zip | ||
| general: | ||
| additionalConfig: | ||
| s3.client.default.endpoint: "http://minio.example.com:9000" | ||
| s3.client.default.region: "us-east-1" | ||
| s3.client.default.path_style_access: "true" | ||
| pluginsList: | ||
| - https://artifacts.opensearch.org/releases/plugins/repository-s3/2.19.3/repository-s3-2.19.3.zip | ||
| ``` |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
OpenSearch Operator CRD schema pluginsList bootstrap general
💡 Result:
Short answer: The OpenSearch Kubernetes Operator CRD (ClusterSpec) exposes plugin configuration in both the general and bootstrap sections — each supports a pluginsList (array of plugin names). The relevant fields are defined on ClusterSpec as General (GeneralConfig) and Bootstrap (BootstrapConfig); both accept pluginsList (string[]), and you can also use additionalConfig under those sections for extra opensearch.yml entries. See the operator API and docs for exact names and examples. [1][2][3]
References
- Operator API (ClusterSpec → General / Bootstrap types). [1]
- OpenSearch Operator docs / Helm values showing bootstrap.general pluginsList example. [2]
- Community discussion and bug notes about bootstrap/plugins/ additionalConfig. [3]
Sources
[1] pkg.go.dev — github.com/opensearch-project/opensearch-k8s-operator/opensearch-operator/api/v1 (ClusterSpec, GeneralConfig, BootstrapConfig).
[2] OpenSearch Kubernetes Operator documentation / Helm examples (bootstrap.pluginsList, general.pluginsList).
[3] OpenSearch forum / GitHub issues discussing bootstrap installing plugins and general.additionalConfig behavior.
🌐 Web query:
OpenSearchCluster CR specification pluginsList configuration
💡 Result:
Short answer — pluginsList is an array of plugin names (string[]) you put in the OpenSearchCluster spec where the operator expects it (commonly under spec.general or under the dashboards/bootstrap sections depending on your operator/chart). The operator will ensure those plugins are installed on cluster nodes (bootstrap pod or image build depending on operator version).
Example (typical OpenSearchCluster CR):
apiVersion: opensearch.opster.io/v1
kind: OpenSearchCluster
metadata:
name: my-cluster
spec:
general:
version: "2.14.0"
serviceName: my-cluster
pluginsList: ["repository-s3","opensearch-knn"]
dashboards:
version: "2.14.0"
enable: true
pluginsList: ["opensearch-dashboards-reports"]
Notes:
- Field type: list of strings. Use the plugin package names (e.g., repository-s3). [1]
- Some deployments also accept pluginsList in bootstrap/Helm values (bootstrap pod installs at startup); behavior can vary by operator/chart version. If plugins fail to install during bootstrap you may need operator/chart-specific tweaks. [2][3]
Sources:
- OpenSearch Operator API (OpenSearchCluster spec shows PluginsList as []string). [1]
- Example CR with general.pluginsList. [2]
- Discussion about bootstrap/pluginsList behavior in Helm values. [3]
🏁 Script executed:
# Search for OpenSearch Operator related files in the repo
find . -type f -name "*opensearch*" -o -name "*OpenSearch*" | head -20Repository: alauda/knowledge
Length of output: 151
🌐 Web query:
OpenSearch Operator bootstrap vs general pluginsList difference when to use
💡 Result:
Short answer — bootstrap.pluginsList is for installing plugins during the cluster bootstrap/init phase; general.pluginsList (or general.pluginsList in Helm/ClusterSpec) is the normal list applied to the running OpenSearch nodes. Use bootstrap.pluginsList only when a plugin must be present during initial bootstrap (for example if bootstrap actions or security/conf-management require the plugin). For most plugins, put them in general.pluginsList so they are installed for the cluster nodes and Dashboards. Note: there are known operator/ bootstrap timing issues (some users report bootstrap not installing plugins reliably), so if you rely on bootstrap-time installation test it or prefer installing via general/plugins on the node image or using general.pluginsList as a safer path. [1][2][3]
Sources:
- OpenSearch Operator ClusterSpec (shows General vs Bootstrap sections). [1]
- Official OpenSearch Helm/docs (shows pluginsList under general configuration). [2]
- Community/Forum reports about bootstrap plugins not being installed and suggested workarounds. [3]
🌐 Web query:
OpenSearch Operator CRD bootstrap BootstrapConfig pluginsList documentation
💡 Result:
Short answer and links
-
The OpenSearch Kubernetes Operator lets you specify plugins to be installed during the bootstrap phase via the cluster resource (bootstrap/BootstrapConfig) using a pluginsList array (e.g. bootstrap.pluginsList: ["repository-s3"]). See the operator docs for the CRD / examples. [1]
-
Example (values/CR) snippet:
bootstrap:
pluginsList: ["repository-s3"]Note: plugins can also be configured at the general/cluster level (general.pluginsList) depending on the chart/CR you use. [1]
-
Practical notes:
- The operator’s bootstrap pod runs plugin installation; some users have reported bootstrap not installing plugins in certain versions and posted workarounds on the project forum. If a plugin isn’t installed on bootstrap, check operator/helm values, bootstrap logs, and network/permissions. [2]
- For plugin names and compatibility, refer to the OpenSearch plugin docs (how to list/install plugins and compatibility guidance). [3]
Sources
[1] OpenSearch Kubernetes Operator / Operator docs and examples.
[2] OpenSearch forum thread: "Bootstrap Does not install Plugins" (user reports and troubleshooting).
[3] OpenSearch documentation — Installing / managing plugins (list, install, compatibility).
Remove redundant pluginsList entry from bootstrap section.
The example specifies the same repository-s3 plugin in both spec.bootstrap.pluginsList (lines 133-134) and spec.general.pluginsList (lines 140-141). While both sections are valid in the OpenSearch Operator CRD, having the same plugin in both is redundant. For most plugins, configure them only under spec.general.pluginsList since bootstrap plugin installation has known reliability issues in some operator versions.
🧹 Suggested fix
spec:
- bootstrap:
- pluginsList:
- - https://artifacts.opensearch.org/releases/plugins/repository-s3/2.19.3/repository-s3-2.19.3.zip
general:
additionalConfig:
s3.client.default.endpoint: "http://minio.example.com:9000"
s3.client.default.region: "us-east-1"
s3.client.default.path_style_access: "true"
pluginsList:
- https://artifacts.opensearch.org/releases/plugins/repository-s3/2.19.3/repository-s3-2.19.3.zip📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| ```yaml | |
| apiVersion: opensearch.opster.io/v1 | |
| kind: OpenSearchCluster | |
| metadata: | |
| name: my-cluster | |
| spec: | |
| bootstrap: | |
| pluginsList: | |
| - https://artifacts.opensearch.org/releases/plugins/repository-s3/2.19.3/repository-s3-2.19.3.zip | |
| general: | |
| additionalConfig: | |
| s3.client.default.endpoint: "http://minio.example.com:9000" | |
| s3.client.default.region: "us-east-1" | |
| s3.client.default.path_style_access: "true" | |
| pluginsList: | |
| - https://artifacts.opensearch.org/releases/plugins/repository-s3/2.19.3/repository-s3-2.19.3.zip | |
| ``` |
🤖 Prompt for AI Agents
In
`@docs/en/solutions/ecosystem/opensearch/How_to_Migrate_from_Elasticsearch_to_OpenSearch.md`
around lines 126 - 142, The YAML example redundantly lists the same
repository-s3 plugin under spec.bootstrap.pluginsList and
spec.general.pluginsList; remove the spec.bootstrap.pluginsList entry so the
plugin is only declared under spec.general.pluginsList (keep the
https://artifacts.opensearch.org/.../repository-s3-2.19.3.zip line in
spec.general.pluginsList and delete the duplicate under
spec.bootstrap.pluginsList) to avoid duplicate installation and
bootstrap-related reliability issues.
|
|
||
| Deploy an Elasticsearch 8.x cluster using ECK Operator: | ||
|
|
||
| ```yaml | ||
| apiVersion: elasticsearch.k8s.elastic.co/v1 | ||
| kind: Elasticsearch | ||
| metadata: | ||
| name: es-cluster | ||
| spec: | ||
| http: | ||
| service: | ||
| spec: | ||
| type: NodePort | ||
| version: 8.17.5 | ||
| nodeSets: | ||
| - name: default | ||
| count: 3 | ||
| config: | ||
| podTemplate: | ||
| spec: | ||
| containers: | ||
| - name: elasticsearch | ||
| resources: | ||
| limits: | ||
| cpu: "2" | ||
| memory: 4Gi | ||
| requests: | ||
| cpu: "1" | ||
| memory: 4Gi | ||
| volumeClaimTemplates: | ||
| - metadata: | ||
| name: elasticsearch-data | ||
| spec: | ||
| accessModes: | ||
| - ReadWriteOnce | ||
| resources: | ||
| requests: | ||
| storage: 5Gi | ||
| ``` |
There was a problem hiding this comment.
Fix YAML indentation in Elasticsearch deployment example.
Lines 392-393 have incorrect indentation. The config: and podTemplate: fields should be properly nested under the default nodeSet.
🔧 Corrected YAML structure
nodeSets:
- name: default
count: 3
- config:
+ config:
+ node.store.allow_mmap: false
podTemplate:
spec:
containers:
- name: elasticsearchNote: The config section appears empty in the original. If no specific configuration is needed, you can remove this field entirely. If configuration is required, add the appropriate settings.
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| Deploy an Elasticsearch 8.x cluster using ECK Operator: | |
| ```yaml | |
| apiVersion: elasticsearch.k8s.elastic.co/v1 | |
| kind: Elasticsearch | |
| metadata: | |
| name: es-cluster | |
| spec: | |
| http: | |
| service: | |
| spec: | |
| type: NodePort | |
| version: 8.17.5 | |
| nodeSets: | |
| - name: default | |
| count: 3 | |
| config: | |
| podTemplate: | |
| spec: | |
| containers: | |
| - name: elasticsearch | |
| resources: | |
| limits: | |
| cpu: "2" | |
| memory: 4Gi | |
| requests: | |
| cpu: "1" | |
| memory: 4Gi | |
| volumeClaimTemplates: | |
| - metadata: | |
| name: elasticsearch-data | |
| spec: | |
| accessModes: | |
| - ReadWriteOnce | |
| resources: | |
| requests: | |
| storage: 5Gi | |
| ``` | |
| Deploy an Elasticsearch 8.x cluster using ECK Operator: | |
🤖 Prompt for AI Agents
In
`@docs/en/solutions/ecosystem/opensearch/How_to_Migrate_from_Elasticsearch_to_OpenSearch.md`
around lines 376 - 414, The YAML for the Elasticsearch resource has mis-indented
fields under the nodeSet named "default": the config and podTemplate blocks must
be nested under the same list item for nodeSets (the block starting with - name:
default) so that podTemplate and config are children of that nodeSet; fix the
indentation to move config: and podTemplate: beneath the "- name: default" entry
(or remove the empty config: if you don't need it) so the Elasticsearch kind's
nodeSets, config, and podTemplate structure is valid.
| ## References | ||
|
|
||
| - [OpenSearch Migration Guide](https://opensearch.org/docs/latest/upgrade-or-migrate/) | ||
| - [Snapshot and Restore](https://opensearch.org/docs/latest/tuning-your-cluster/availability-and-recovery/snapshots/snapshot-restore/) | ||
| - [Reindex API](https://opensearch.org/docs/latest/api-reference/document-apis/reindex/) | ||
| - [Keystore Management](https://opensearch.org/docs/latest/security/configuration/security-settings/) | ||
| - [OpenSearch Clients](https://opensearch.org/docs/latest/clients/) |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# First, check if the file exists and view the content around lines 504-510
if [ -f "docs/en/solutions/ecosystem/opensearch/How_to_Migrate_from_Elasticsearch_to_OpenSearch.md" ]; then
echo "File found. Content at lines 500-515:"
sed -n '500,515p' "docs/en/solutions/ecosystem/opensearch/How_to_Migrate_from_Elasticsearch_to_OpenSearch.md"
else
echo "File not found. Listing docs directory structure:"
find docs -name "*OpenSearch*" -o -name "*opensearch*" 2>/dev/null | head -20
fiRepository: alauda/knowledge
Length of output: 829
🌐 Web query:
OpenSearch documentation URL: https://opensearch.org/docs/latest/upgrade-or-migrate/
💡 Result:
The OpenSearch "Migrate or upgrade" documentation is available at: https://docs.opensearch.org/latest/upgrade-or-migrate/ — it covers snapshot & restore, rolling upgrades, and the Migration Assistant. [1]
Sources
[1] OpenSearch docs — Migrate or upgrade. https://docs.opensearch.org/latest/upgrade-or-migrate/
🌐 Web query:
OpenSearch Reindex API documentation: https://opensearch.org/docs/latest/api-reference/document-apis/reindex/
💡 Result:
The OpenSearch Reindex API copies documents from one index (or query) into another index—useful for reindexing, transforming documents with a script, or moving data between clusters. The main endpoint is POST _reindex and supports options such as source/target index, query, script, conflicts handling, slices (parallelization), and wait_for_completion/requests_per_second. See the official docs for full syntax, examples and all parameters. [1]
Sources
- OpenSearch Reindex API documentation. [1] https://docs.opensearch.org/latest/api-reference/document-apis/reindex/
🌐 Web query:
OpenSearch Snapshot and Restore: https://opensearch.org/docs/latest/tuning-your-cluster/availability-and-recovery/snapshots/snapshot-restore/
💡 Result:
Here’s a concise summary of OpenSearch Snapshot & Restore (how to set up, take, restore, and key tuning points) with docs cited.
-
Purpose: snapshots store point-in-time copies of index data (incremental after the first snapshot) and cluster metadata; useful for backups, migration, and disaster recovery. [1]
-
Register a repository (required first step): POST/PUT /_snapshot/ — types: fs, s3, hdfs, etc.; settings include location, chunk_size, compress, max_snapshot_bytes_per_sec and max_restore_bytes_per_sec (throttling). Verify repository after registering. [2]
-
Take a snapshot:
- Create snapshot API: PUT /_snapshot//<snapshot_name>
- Options: indices, include_global_state, partial, metadata, ignore_unavailable. Snapshots are incremental (only new/changed segments stored). [1]
-
Restore a snapshot:
- Restore API: POST /_snapshot//<snapshot_name>/_restore
- Options: rename_pattern/replace, index settings (settings and mappings), include_global_state, partial restore, ignore_unavailable. Check cluster/index health and adjust allocation/settings before/after restore as needed. [1]
-
Automate snapshots: Snapshot Management (SM) plugin/API to create scheduled policies (create/delete schedules, retention rules, notifications). SM handles retries, non-concurrent operations per policy, and stores policy metadata in cluster. [3]
-
Tuning & best practices (high-level):
- Use repository throttling (max_snapshot_bytes_per_sec / max_restore_bytes_per_sec) to limit IO impact. [2]
- Keep snapshots incremental and retain only needed snapshots (use SM deletion rules). [1][3]
- Avoid many concurrent snapshot operations; don’t schedule overlapping policies against same indexes/repo. [3]
- For large repositories, ensure cluster-manager node has enough memory for repository metadata. [3]
- Test restores regularly and validate repository ACLs/permissions for storage backends (S3, NFS, etc.). [1][2]
Sources:
- Take and restore snapshots — OpenSearch docs. [1]
- Registering or updating a snapshot repository (API). [2]
- Snapshot Management API (scheduling/retention automation). [3]
🌐 Web query:
OpenSearch security settings keystore: https://opensearch.org/docs/latest/security/configuration/security-settings/
💡 Result:
Summary — OpenSearch keystore (security settings)
-
Purpose: secure storage for sensitive OpenSearch settings (passwords, keys) used by the Security plugin; separate from JKS/PKCS12 keystore & truststore files used for TLS. [1][2]
-
Location: $OPENSEARCH_HOME/config/opensearch.keystore (created by the opensearch-keystore utility). [1]
-
Common commands (opensearch-keystore):
- create, list, add , add-file , remove , upgrade, passwd, has-passwd. [1]
-
Passwords / startup:
- You can password-protect the keystore (opensearch-keystore passwd or create -p). At startup OpenSearch prompts for the keystore password or you can set KEYSTORE_PASSWORD to avoid prompt. [1]
-
How entries are used:
- Keystore entries become available as OpenSearch settings (refer in opensearch.yml with the keystore key name). Example: plugins.security.ssl.http.pemkey_password_secure: ${plugins.security.ssl.http.pemkey_password_secure}. [1]
-
TLS vs keystore settings:
- TLS for transport/HTTP can use PEM files or JKS/PKCS12 keystore & truststore files; those TLS keystore file settings (filepath, type, alias, password) are configured via plugins.security.ssl.* settings in opensearch.yml and are distinct from the opensearch.keystore utility. [2]
-
Using with securityadmin:
- securityadmin.sh accepts -ks/-kspass/-kst/-ksalias and -ts/-tspass to point at keystore/truststore files when applying security config. [3]
Sources:
[1] OpenSearch keystore — OpenSearch Docs.
[2] TLS / Keystore & truststore settings — OpenSearch Docs.
[3] Using securityadmin with keystore/truststore — OpenSearch Docs.
🌐 Web query:
OpenSearch clients documentation: https://opensearch.org/docs/latest/clients/
💡 Result:
The OpenSearch "Clients" documentation lists official language clients, notes legacy compatibility guidance, and links to each client’s docs:
- Official clients: Python (high- and low-level + opensearch-py-ml), Java (new Java client), JavaScript (Node.js), Go, Ruby, PHP, .NET (high- and low-level), Rust, and Hadoop.
- Notes: the Java high-level REST client is deprecated starting OpenSearch 3.0.0 (use the new Java client).
- Legacy clients: guidance for using Elasticsearch OSS 7.10.2-era clients with OpenSearch 1.x and a compatibility table/recommendations.
See the full page and links to each client’s docs for installation and API details. [1]
Source: OpenSearch documentation — Language clients. [1] https://opensearch.org/docs/latest/clients/
Correct the reference URLs to use the proper OpenSearch documentation domain structure.
Several reference URLs use an incorrect domain structure. The official OpenSearch documentation is hosted at docs.opensearch.org, not opensearch.org/docs. Update the following URLs:
- Line 506: Change
https://opensearch.org/docs/latest/upgrade-or-migrate/tohttps://docs.opensearch.org/latest/upgrade-or-migrate/ - Line 508: Change
https://opensearch.org/docs/latest/api-reference/document-apis/reindex/tohttps://docs.opensearch.org/latest/api-reference/document-apis/reindex/
Verify the remaining URLs follow the correct domain structure as well.
🤖 Prompt for AI Agents
In
`@docs/en/solutions/ecosystem/opensearch/How_to_Migrate_from_Elasticsearch_to_OpenSearch.md`
around lines 504 - 510, Update the reference URLs in the References section so
they use the correct docs.opensearch.org domain: replace
`https://opensearch.org/docs/latest/upgrade-or-migrate/` with
`https://docs.opensearch.org/latest/upgrade-or-migrate/` and
`https://opensearch.org/docs/latest/api-reference/document-apis/reindex/` with
`https://docs.opensearch.org/latest/api-reference/document-apis/reindex/`; also
scan the remaining links in the same list (`Snapshot and Restore`, `Keystore
Management`, `OpenSearch Clients`) and change any
`https://opensearch.org/docs/...` occurrences to
`https://docs.opensearch.org/...` so all reference URLs use the proper domain.
Summary by CodeRabbit
✏️ Tip: You can customize this high-level summary in your review settings.