You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Apr 22, 2020. It is now read-only.
If all 3 attempts to docker pull fail, the boot process is aborted and the instance then proceeds to do nothing. We should either retry the pull infinitely (with a backoff), or implement the solution proposed in #441 and terminate the instance.
The text was updated successfully, but these errors were encountered:
The suggestion in #441 wasn't to "terminate the instance". It was describing a problem where this doesn't happen, because LB configuration is special.
I wonder in which context did you see this issue? Why wasn't it terminated after "proceeding to do nothing", i.e. not sending success signal to the CF and not responding to health check?
OK, that's an important detail. In any case it wouldn't make sense to me to try to terminate instance from taupage (not even sure if that's possible, or at least would require to grant permission to terminate any EC2 instance in the VPC to every instance profile role of every app).
I'm not sure if rebooting would be any better — if the instance is somehow broken (e.g. spawned on a faulty hypervisor, ran out of space so the init scripts can't proceed or the volume is corrupted beyond repair) it'd be better to just terminate it and let the ASG to spawn a healthy one instead of just rebooting in a loop. We can make it configurable, though.
If all 3 attempts to
docker pull
fail, the boot process is aborted and the instance then proceeds to do nothing. We should either retry the pull infinitely (with a backoff), or implement the solution proposed in #441 and terminate the instance.The text was updated successfully, but these errors were encountered: