aws / amazon-ec2-spot-interrupter Goto Github PK

Describe the bug
The FIS experiment template persists in my AWS account after spot interruption(s) are complete.

To Reproduce

1. Run app with --clean=true (default): spoti --instance-ids i-0208a716009d70b36
2. Check AWS account > FIS > Experiment Templates
3. See template with description: "trigger spot ITN for instances [i-0208a716009d70b36]"

Expected behavior
Templates should be cleaned up if --clean=true.

Application Logs
N/A

Environment

• App Version: Latest
• OS/Arch: darwin/amd64
• Installation method: git clone

If a user is testing their application's spot handling on an OD instance, it would be useful to transfer the VM to a spot instance since FIS will only send an ITN to the Spot instance. We should explore hibernating and transferring the EBS volume to the same instance type but with a spot purchasing option.

$ ec2-spot-interrupter -i i-0123456789
⛔️ i-0123456789 is an on-demand instance
Would you like to hibernate and launch on a spot instance (y/n): y
Hibernating i-0123456789
Launching Spot instance i-9876543210
Sending Spot ITN

Add tag based instance selection to find instances to send an interruption to.

$ ec2-spot-interrupter -t Dev:my-dev

1. MyAL2Instance (i-0123456789)
2. MyOtherInstance (i-9876543210)
3. ... 

Select instances:  1-3 

I'm open to other interfaces for picking the instance types. Maybe adding an "A" for all and "R" for random ?

When i try to install the ec2-spot-interrupter i receive this error:

Error: ec2-spot-interrupter: SHA256 mismatch
Expected: b0cda18f79aace89424c8963a6d39107c9168535a9b8bd0424fb2bb57d82b531
Actual: e8a946b2b20504e3aa666bd91ae2b60c68c328712e848cb1d6520866a5865070

I tried in different linux distros and always the same.
How can i solve it?

Issue

• Started the app in --interactive mode, didn't provide a delay time (hit enter), and app exited unexpectedly:

[23/05/22 12:41:17] ➜  amazon-ec2-spot-interrupter git:(main) ✗ go run cmd/main.go --interactive -i i-0a2e78f0dcb6990c3 --region us-east-1
How long to wait before sending the interruption notifications?
Creating Interruption Experiment 
                
Press q to quit.
[23/05/22 12:41:48] ➜  amazon-ec2-spot-interrupter git:(main)

• Waited for some time, but don't think experiment actually took place

Expected Outcome

• Walk me thru and start experiment successfully

Describe the feature

• Allow for the ec2-spot-interrupter to use a user specific IAM role rather than the default generated one.
• Allow for the ec2-spot-interrupter to delete the generated IAM role.

To Reproduce
Steps to demonstrate the desired behavior:

## Generates an IAM role for FIS to use, but there is no way to delete the role from the CLI
## You would need to manually find the role to delete it.
$ ec2-spot-interrupter --instance-ids i-012335

$ ec2-spot-interrupter --role-arn arn:aws::myrole --instance-ids i-012345

Additional context
Add any other context about the problem here.

Currently, the CLI hardcodes the timing in the experiment template to 4 min. This results in a rebalance recommendation immediately and then a Spot ITN in 2 min.

$ ec2-spot-interrupter --delay 10m
✅ Experiment submitted to FIS
⏳ Waiting 10 min
...

Issue

• Events channel says Interruption will be sent in 15 seconds, but the time is usually longer by more than 5 secs (>33% of estimate).

• From ReadMe:

2022-05-18T11:39:45: ✅ Rebalance Recommendation sent
2022-05-18T11:39:45: ⏳ Interruption will be sent in 15 seconds
2022-05-18T11:40:05: ✅ Spot 2-minute Interruption Notification sent
2022-05-18T11:42:05: ✅ Spot Instance Shutdown sent

Expected Outcome

• Timestamp diff between 'will be sent' and 'sent' should be closer to 15 seconds
  OR
• Log sent to events channel updated, ex: "⏳ Interruption will be sent in 15-X seconds"

A Textual User Interface (TUI) would allow this tool to provide a rich UX for demoing or working with a large number of instances.

A library like BubbleTea could be used for this: https://github.com/charmbracelet/bubbletea

Currently, FIS Experiments are not deleted. It might be a good idea to delete them by default with this tool or at the very least add an option or command to cleanup experiments managed by this tool.