Update deployment script to point to current MCP AMI

[jl-0]

Fixing nightly deployment which referenced only SSM parameter.

Looks like MCP removed the /mcp/amis/aml2-eks-1-29 AMI and replaced it with /mcp/amis/aml2023-eks-1-29. The nightly deploy script removes the SSM parameter before creating it again and since the reference SSM didn't exist the unity SSM "/unity/account/eks/amis/aml2-eks-1-29" was removed.

@jpl-btlunsfo, @LucaCinquini is it OK to keep the old "Unity" SSM name or do we need to update it to aml2023 in all the scripts?

[jpl-btlunsfo]

If we're trying to support older versions/deployments, no- we'd be using the old name.

Once I've wrapped up the 1.32 troubleshooting, we should be able to kick SPS's eks_module ref up to the latest (and drop 1.29 altogether).

[LucaCinquini]

Yes I think @jpl-btlunsfo is right: we should wait for his updates before moving this SSM key altogether.

[jl-0]

@jpl-btlunsfo, the link you sent is referencing the /mcp parameter directly, so it will also be broken by MCP renaming to aml2023-eks-1-29.

@LucaCinquini, what was the behavior you experienced? Looking at the scripts, it seems like MCP renaming the parameter should only have resulted in a warning. I don't see any Terraform that attempts to access /unity/account/eks/amis/aml2-eks-1-29

[LucaCinquini]

I think it was some of our TF code that invoked that parameter? I don't have the error any more.

[jpl-btlunsfo]

We're also pointing at the /unity/account/eks/amis/ area here (where we're tracking tag unity-sps-2.5.0). This is the spot that ideally will be fixed by taking a more current tag from the unity-cs-infra eks_module.