Can't supply an AMI ID in the interactive interface

[snay2]

Describe the bug
Supplying my own AMI ID directly via flags works fine, but trying to supply one via the interactive interface fails.

Steps to reproduce

1. Run simple-ec2 launch -i
2. Follow all the prompts but select an ARM instance type, such as t4g.micro (This might not be necessary, but the AMI ID I'm using is ARM64)
3. When you get to the AMI selection screen, paste in ami-088e1f338c3b87d1a

Result: simple-ec2 crashes.

Expected outcome
simple-ec2 should accept that AMI ID and continue on

Workaround:

Supplying the AMI ID directly on the command line works fine, such as

simple-ec2 launch -t t4g.micro -m ami-088e1f338c3b87d1a ...

Environment

• App Version: 0.6.0
• OS/Arch: MacOS 12.2 Intel

[icarthick]

One simple way to fix this is by updating this method to also accept architecture as a filter input when building ec2.DescribeImagesInput. This will ensure when images are queired for, only images matching the selected architecture will be retrieved. This also would need to be updated so that it matches both x86 and ARM images

[icarthick]

Happy to work on this and provide a PR

[snay2]

One simple way to fix this is by updating this method to also accept architecture as a filter input when building ec2.DescribeImagesInput.

@icarthick That sounds like a good solution for #52, but I don't think it would solve this defect. Feel free to open a PR for that fix at your leisure!

[icarthick]

@snay2 Interesting, I thought if you receive t4g.micro as the chosen instance (user lets say choses it in interactive mode), then using instanceTypeInfo.ProcessorInfo.SupportedArchitectures we can pass the architecture and along with the changes mentioned above would solve this particular defect. Let me know what am missing here.

[snay2]

This issue (#51) is that the user can't type in a full AMI ID in interactive mode. It has nothing to do with the instance architecture per se. Issue #52 is about presenting the user with architecture-appropriate AMIs after they've selected an instance type, and your solution sounds like it would solve that defect. I agree we should try your approach, I just think this discussion should take place on #52 instead of here.

[brycahta]

Is this not the intended design with --interactive mode? It's a quick-start/guided tour for users less familiar with EC2 and/or not sure what they want and guarantees launching a working Instance.

[AustinSiu]

Running through the interactive experience, I see that it provides a set of images compatible with the instance type selected, something like this:

+--------+------------------+-----------------------+--------------------------+
| OPTION | OPERATING SYSTEM |       IMAGE ID        |      CREATION DATE       |
+--------+------------------+-----------------------+--------------------------+
| 1.     | Amazon Linux 2   | ami-0fe23c115c3ba9bac | 2022-04-28T21:39:49.000Z |
| 2.     | Ubuntu           | ami-03390b9b1e9af4bf2 | 2022-05-06T19:22:35.000Z |
| 3.     | Amazon Linux     | ami-0abc8b47f68e77491 | 2022-05-04T21:38:22.000Z |
| 4.     | Red Hat          | ami-078cbc4c2d057c244 | 2022-05-13T11:53:05.000Z |
| 5.     | SUSE Linux       | ami-0f123feeffce6b4ef | 2022-04-27T09:35:45.000Z |
| 6.     | Windows          | ami-096f34d096a3c671f | 2022-05-11T06:38:48.000Z |
+--------+------------------+-----------------------+--------------------------+

If I enter the image id of any of the above when prompted, Simple EC2 continues on.
The issue is somewhat unclear to me; was ami-088e1f338c3b87d1a, from the issue example, not one of the image ids Simple EC2 found, but we expect it to accept?

[snay2]

Before #52 was fixed, the fact that this prompt only accepted certain AMI IDs meant that simple-ec2 was not able to successfully launch an instance if you chose an ARM instance type. You could type in a full AMI ID yourself, but if it did not match one already in the menu, the program failed out unceremoniously, even if it would have worked with that instance type, and even though the ones in the menu were not valid for that instance type.

This issue is less important now since we've fixed that, but I still see it as an escape hatch or a power-user feature. It's not readily discoverable, but it does allow the user to continue using interactive mode even if our defaults don't fit their needs. That is a lower barrier to entry than forcing the user to convert to command-line flags as soon as any one of their choices no longer fits the interactive mode prompts.

That said, I see where you're coming from--this opens the door to more failure modes the user may not anticipate. Perhaps it would be better if we added some validation that the AMI they selected (whether or not from our curated menu) will work with their chosen configuration. That way, we allow the user more options but we keep the guarantees of being able to launch a working instance. What do you think?

---

EDIT: TL;DR We currently allow the user to supply arguments on the command line that we do not accept in interactive mode. I think they should be the same. So this issue basically boils down to "let the user enter any AMI ID in interactive mode, even if it's not in the menu." However, Bryan's argument is valid. In order to maintain the guarantees of being able to launch an instance successfully, we will also need to add new validation if they enter an AMI ID we haven't already vetted, to ensure that it will work.

[brycahta]

Appreciate the context, I think I'm just of the mind that a power-user wouldn't be using --interactive mode, but just send args via cli flags. Also, I'm not sure how many users will know their AMI and nothing else (worst case) and if it's worth the effort of additional validations and potentially inconsistent CX (i.e. can't paste for other prompts... unless?). Last consideration, will the TUI model allow for both cursor selection and input?

Just some thoughts off the dome; you prob want a more senior opinion though

[brycahta]

@AustinSiu

If I enter the image id of any of the above when prompted, Simple EC2 continues on.

I think this is a bug. If you enter an invalid input, then press enter (edit: press enter twice) I believe it might try to use latest AL2 and move on. Did you confirm what image the instance launched with?

[ any image id ]: Select the image id
AMI [Latest Amazon Linux 2 image]:  exodia-oblit
Input invalid. Please try again.


[ yes / no ]
Persist EBS volume(s) after the instance is terminated? [no]:

The issue is somewhat unclear to me; was ami-088e1f338c3b87d1a, from the issue example, not one of the image ids Simple EC2 found, but we expect it to accept?

Correct-- this was AMI from @snay2:

Supplying my own AMI ID directly

[snay2]

I'm not sure how many users will know their AMI and nothing else

Good point. The value is limited to power users who are more likely to use CLI flags anyway.

potentially inconsistent CX (i.e. can't paste for other prompts... unless?)

The only other prompt that allows direct input is the instance type selection, which has validation and only allows the instance types that are available in that region. If we do allow the user to type an AMI ID in interactive mode, we should probably implement a similar level of validation to maintain the guarantee of being able to launch an instance successfully.

[LikithaVemulapalli]

I think this is a bug. If you enter an invalid input, then press enter (edit: press enter twice) I believe it might try to use latest AL2 and move on. Did you confirm what image the instance launched with?

Yes if we hit enter twice it considers the default AL2 value instead of the incorrect one that we enter. We get the launch confirmation options at the end after adding all the required options, I cross-checked in the confirmation table at the end, it will select the default value and not the incorrect one!

[brycahta]

If we do allow the user to type an AMI ID in interactive mode, we should probably implement a similar level of validation to maintain the guarantee of being able to launch an instance successfully.

Agreed and we should be able to re-use validation (both formatting and compatibility) regardless of interactive mode or not

[LikithaVemulapalli]

Thanks for all the suggestions. We are closing this issue as we don't require interactive terminal to accept image id's other than the default ones. In the interactive terminal we can select the Image from the default images fetched for each OS based on the instance type and region that we had chosen earlier. Additionally, user has an option to pass the AMI ID in the flag when launching an interactive terminal. Below command is the sample one if user knows the AMI ID and wants to launch an instance using interactive terminal.

simple-ec2 launch -i -m ami-xxxxxx