Undocumented retries and inability to remove that functionality
- Dominant language
- Go
- Stars
- 167
- Forks
- 21
- Avg merge
- 58m
- Merged PRs (30d)
- 1
Description
By default, the ec2-macos-init application will retry execution of failed sections. This doesn't appear documented anywhere, and can cause unexpected side effects. As an example, I have a script that configures MacOS certificates and registers the instance as a runner. As the line of my shell script failed came after registration, the machine registered itself with gitlab 101 times before finally stopping. This behavior needs to be modifiable and well documented, as it can cause serious side effects if not known.
Example TOML added:
```[[Module]]
Name = "Execute_Startup"
PriorityGroup = 3 # Fourth group
RunOnce = true # Run once, ever
FatalOnError = false # Stop running Init if there is an error
[Module.Command]
Cmd = ["/usr/local/aws/ec2-macos-init/startup.sh"] # A simple command
RunAsUser = "ec2-user" # Run as ec2-user
```
And the shell script:
```
#!/bin/bash
curl -L https://www.apple.com/certificateauthority/AppleWWDRCAG3.cer > g3.cer
sudo security authorizationdb write com.apple.trust-settings.admin allow
sudo security add-trusted-cert -d -r trustAsRoot -k /Library/Keychains/System.keychain g3.cer
security set-key-partition-list -S apple-tool:,apple: -s -k "${password}" login.keychain-db
/usr/local/opt/gitlab-runner/bin/gitlab-runner register --non-interactive --url 'REDACTED'--executor 'shell' --run-untagged='false' --tag-list 'mac' --registration-token REDACTED
git lfs install
```
Note that `git lfs install` failed due to a missing $HOME env var, causing it to import the certificate many times and register itself with gitlab 100 times.
My recommended fix would be to accept a 'RetryCount' option in the TOML to make this configurable, and explicitly set the default within the TOML, removing the const variable.
Contributor guide
Research direction
Start by tracing retry handling in the ec2-macos-init application and the TOML Module configuration shown in the issue, including FatalOnError and RunOnce. Determine how a RetryCount option would interact with failed sections, make the default and behavior explicit in the configuration documentation, and verify that repeated side effects are prevented when the configured limit is reached.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go, shell
- Domain
- cloud, documentation, operating-systems
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100