If your deployment also requires STS or EKS Authentication endpoints (for example, for IRSA or EKS Pod Identity), create those separately before running the bootstrap script.
This gives no steps, no AWS CLI command, and no link for how to actually create those endpoints.
Atleast a reference link could be included if that makes sense from the scope of this guide
Playbook: Elasticsearch 6.8 to OpenSearch 3.5 on EKS (existing VPC)
How about a playbook for ES 7.x to OpenSearch 3.x
This is see more frequently in the field
Additional debugging information
It would also be useful to get and attach info about "which --version/image tags are actually running"
I faced this issue
he workflow submit command automatically
Is there any suggestion to stop/delete the workflow instead of repeated "workflow submit"
The console pod does not run under a service account named migration-console. The chart uses migration-console-access-role.
Can be rephrased to make it more clear. I believe this is an example issue. But to tther reader it may be a bit confusing.
The EKS deployment creates a role named <eks-cluster-name>-migrations-role. To find the role, run the following command:
This does not align with the naming pattern mentioned on page: Deploy on Amazon EKS"
migration-console-access-role and argo-workflow-executor
Transform field types
Should this too be listed under "Breaking changes"?
Amazon OpenSearch Service: Upgrade Guidance
This link is not a "Breaking change".
It is a reference link.
Mixing reference links into a list titled "Relevant breaking changes" is a little confusing.
small enough
What is small enough, can a number be put for this
New VPC pinned to a specific release
Once MA installation is successful, it will take you inside the MA console.
So this command needs to be run from the cloud shell.. may be make it clear if you think it is needed
To deploy into a new VPC using the latest published release, run the following command:
ran into two issues with the --version pinning flow that I think are worth fixing:
Running the bootstrap script without --version defaults to the latest release (currently 3.3.5), but the traffic-capture-proxy image for 3.3.5 isn't published in the public ECR registry (MANIFEST_UNKNOWN error). Might be worth checking if that release is missing an image push. Following the doc's own example and pinning --version 3.2.1 hits a second issue: the bootstrap script downloaded via releases/latest/download/aws-bootstrap.sh doesn't match the file layout of the 3.2.1 Helm chart — it looks for infra/mirror/private-ecr-manifest.yaml, which isn't in that archive. Seems like the script expects a newer repo structure than what 3.2.1 actually has.
Step 1: Download the bootstrap script
Where do I run this? Cloud shell, it would be better to mention it
Amazon EKS on AWS
How about private networking for AWS
Use a managed-cloud path (Amazon EKS on AWS or GKE on GCP) if you also want the deployment tooling to prepare the cloud environment around the migration.
This statement can come after the "If you answered “yes” to most". It kind of breaks the checklist flow
Supported migration paths
How about "elasticsearch-9.0.0"?
1 Is Migration Assistant right for you?
"Assess your migration" link is missed. If I follow these steps instead of "Getting Started", I might miss "Assess your migration"
Getting started
Why the 6 links are repeated in Getting Started section and in the below section. It may confuse.
what you migrate to
Target is already fixed as "OpenSearch", so this part of the statement is not required.