[ShreyaGangishetty]

What's changing and why?

Updates the Helm → EKS add-on migration for the HyperPod Inference Operator
(helm_chart/HyperPodHelmChart/charts/inference-operator/migration/). The script had drifted from the current
add-on, and several steps could leave a live cluster without metrics or with broken webhooks.

• Add-on version: installs the EKS default version for the cluster's Kubernetes version instead of the
  pinned v1.0.0-eksbuild.1, which is not available on Kubernetes 1.35+. Overridable with --addon-version.
  Configuration follows the current schema and sets inferenceGateway.enabled: false (v2.x enables it by
  default; it was never part of the Helm install).
• IAM roles: new optional --execution-role-arn, --alb-role-arn, --keda-role-arn,
  --jumpstart-gated-role-arn. Roles that are not provided are created with the add-on's trust and
  permissions, instead of copying attached policies from the Helm-era roles (which produced a KEDA role with no
  permissions when the Helm role used inline policies).
• Validation before any change: add-on version, TLS bucket name pattern, and for provided roles: trust for
  the add-on service accounts, S3 access to every TLS bucket in use, and ACM import/tag/delete. Detected
  problems are never auto-approved by --auto-approve.
• Rollback: removes the add-on with --preserve (the add-on owns the inference CRDs), re-applies the Helm
  release so the webhooks, KEDA metrics APIService and CRD conversion webhook point back at the Helm
  controllers, waits for them, then removes the add-on controllers. Deletes only roles and tags the script
  created. Model resources are saved to the backup directory and never deleted.
• metrics-server: created with --resolve-conflicts OVERWRITE and waited on before the Helm
  metrics-server is removed. Previously it went CREATE_FAILED after the Helm one was deleted, leaving the
  cluster without a metrics API.
• Dependency add-ons: use EKS default versions instead of pinned ones.
• Cleanup: fixes the namespace used for KEDA service account cleanup.
• Docs: README is now a migration guide: prerequisites, options, IAM roles (with example roles to create
  your own and alb-controller-policy.json), what to know before and after migrating, and recovery.

Before/After UX

Before:

• Installed add-on v1.0.0-eksbuild.1 with the Inference Gateway implicitly on (v2.x defaults)
• Always created new ALB/KEDA roles by copying attached policies only; no way to pass your own
• Rollback left webhooks and APIServices pointing at deleted add-on services
• metrics-server add-on could fail after the Helm metrics-server was already deleted

After:

• ./helm_to_addon.sh --cluster-name <cluster> --region <region> installs the default add-on version with the
  gateway disabled
• Bring-your-own roles via flags, validated up front; the guide lists exactly what each role needs
• Rollback returns the cluster fully to the Helm controllers without removing models
• No gap in the metrics API

How was this change tested?

End to end on a HyperPod EKS cluster (Kubernetes 1.34, us-east-1) created with the console quick-setup Helm
path, with a JumpStart model and an InferenceEndpointConfig (2 replicas each) under continuous
InvokeEndpoint load (2 req/s per endpoint):

Scenario	Result
Unsupported --addon-version	Stops at pre-flight, no changes
Helm-era KEDA role passed with --auto-approve	Stops at trust check, no changes
create-addon fails after Helm controllers are scaled down	Rollback restores Helm, created roles removed
Add-on installs fully, then reported failed	Rollback: add-on removed with --preserve, webhooks/APIService/CRD conversion back on Helm, new model deploys on Helm
Default migration	Add-on ACTIVE, models reconciled, ALB DNS names unchanged
Migration with customer-provided KEDA and ALB roles	Roles used as-is, KEDA ScaledObject Ready
Re-run after success	Exits "already installed"
New model after migration	Deploys; certificate imported and tagged; HTTPS ALB; invoke OK; delete removes endpoint, certificate, ALB and S3 objects
Add-on deleted with --preserve and recreated	ACTIVE, models unchanged

No endpoint request failed in any scenario (two failures over the whole run were the load client's own
credentials expiring). Model resource UIDs were unchanged through every migration and rollback.

Are unit tests added?

No. The script has no unit test harness; it was tested end to end as above.

Are integration tests added?

No.

Reviewer Guidelines

‼️ Merge Requirements: PRs with failing integration tests cannot be merged without justification.

One of the following must be true:

• All automated PR checks pass
• Failed tests include local run results/screenshots proving they work
• Changes are documentation-only