Description of problem

The Machine API's Machine controller currently fails to launch new Machines on AWS when the Machine(Set) is configured to use a deprecated AMI.

Version-Release number of selected component

4.17.28

How reproducible

Every time.

Steps to Reproduce

1. Find (or create?) a deprecated AMI.
2. Create a Machine(Set) requesting the deprecated AMI by ID.

Actual results

The Machine controller will fail to create the Machine instance, with logs like:

I1020 22:37:48.995701       1 instances.go:218] Using AMI ami-0dd8411ece8c06dae
...
E1020 22:37:49.342154       1 instances.go:284] No image for given AMI was found

Expected results

Successful instance creation.

Additional info

Seems like this code getting tripped up. Although I'm not entirely clear on why, because it seems to be using the AMI ID, and AWS docs say:

For AMI users, the deprecated AMI does not appear in DescribeImages API calls unless you specify its ID or specify that deprecated AMIs must appear.

One factor suggesting deprecated AMI access being an issue worth fixing is those same AWS docs:

By default, the deprecation date of all public AMIs is set to two years from the AMI creation date. You can set the deprecation date to earlier than two years. To cancel the deprecation date, or to move the deprecation to a later date, you must make the AMI private by only sharing it with specific AWS accounts.

Factors suggesting deprecated AMI access might not be worth fixing include:

• The eventual move from Machine APIs to Cluster APIs. I haven't checked for similar code in the Cluster API Machine controller.
• Work by the machine-control operator on actively managing AMI references, e.g. 4.19 going GA with the managedBootImages property for MachineSet management, although work here continues, like MCO-1007's tech-preview ControlPlaneMachineSet boot image management.