Allow order of execution to be determined by "DependsOn" param of CloudfFormation
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 25/100
- Issue type
- Feature
- Clarity
- Mostly clear
- Activity status
- Stale
- Tech stack
- aws, ruby
- Domain
- cloud, devops, infrastructure
Research direction
Start in /lib/cfn_manage/cf_start_stop_environment.rb, especially resource_start_priorities, and trace how the CloudFormation stack resources are ordered. Investigate how DependsOn values can be traversed and mapped to startup order. Done means specified dependencies are honored instead of relying only on fixed service-type priorities.
Written by the indexing model from the issue text.
Description
We have identified an issue with dependencies and startup order.
ISSUE:
One of our EC2 instances requires that a Container in ECS is fully available at the time of its startup/provisioning stage. From my understanding, the execution order is hardcoded in /lib/cfn_manage/cf_start_stop_environment.rb by "resource_start_priorities". Currently, EC2 instances start first, and THEN ECS instances... I suspect this is because the ECS startup will fail if the respective EC2 servers hosting Containers are not available first..? Regardless, this is causing issues for us since we must have one of our EC2 instances spin up only AFTER a specific ECS Container is fully available.
PROPOSED CHANGE:
Could you please consider traversing the Cloudformation Stack to compile a map of dependencies based on any "DependsOn" parameters of resources. Then, you could modify the execution order based on this mapping. This will ensure that any specified dependencies in the Stack are honoured, instead of following a fixed execution order based on service type.
TEMP WORKAROUND UNTIL FIXED:
Currently, we are using a temp workaround of invoking EC2 API commands after the cfn_manage execution to terminate the instances which have a dependency on ECS containers. Then, the ASG will spin up new instances shortly after this termination, thus having those instances with dependencies be created AFTER ECS is finished starting up.
Thank you for the open-source resource!
- Dominant language
- Ruby
- Stars
- 11
- Forks
- 14
- PR merge metrics
- No merged PRs in 30d
Getting set up
- Ships a Dockerfile or Docker Compose file
- No pull request template
- No contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from base2Services/cfn-start-stop-stack
-
add ability to lookup multiple cloudformation stacks by tagPossibly taken @lohgannash claimed this 1769 days ago. Opencfn-manage enhancement wontfix
Difficulty 3/5 1-2 days Newbie friendliness 25/100
-
cfn-manage enhancement
Difficulty 3/5 1-2 days Newbie friendliness 35/100
-
cfn-manage enhancement
Difficulty 3/5 1-2 days Newbie friendliness 35/100
base2Services/cfn-start-stop-stack#36 · 1 reaction ·
-
cfn-manage enhancement
Difficulty 4/5 3-5 days Newbie friendliness 35/100
base2Services/cfn-start-stop-stack#25 · 1 comment ·
-
Unit testsOpenhelp wanted
Difficulty 3/5 1-2 days Newbie friendliness 35/100
All issues in base2Services/cfn-start-stop-stack
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
FinanceFlash/unvibecode#273 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
-
[Bug Report] Concurrent runs sharing a cold cache fail with JSON::ParserErrorPossibly taken @sarankumar1325 claimed this today. Openbug
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
we-promise/sure#4481 ·
Maintainers usually reply within 1 day