NAS-131763 / 25.04 / Improve app status reporting #14668
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
bugclerk
changed the title
yocalebo
reviewed
Oct 13, 2024
yocalebo
approved these changes
Oct 13, 2024
|
Tested nextcloud and immich which both have some dependencies. Also installed 2 custom apps, one that runs once and exits 0 and one that exits 1. Same on reboot. Also tried stopping/starting. Statuses look good. LGTM |
stavros-k
approved these changes
Oct 14, 2024
This was referenced Oct 16, 2024
|
This PR has been merged and conversations have been locked. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR aims to improve how we report in what state the app is in right now. Before we get to what we are doing in this PR, some context here - so when we have a compose file which has multiple dependencies, the services dependent on the service running right now won't start unless the service they depend on finishes gracefully - in this case docker does create containers for these services which are waiting to start but does not actually start them.
What was happening with our earlier logic was that when we started an app - we reported it as deploying -> crashed -> deploying -> running (for some apps), this happened because there were some dependencies involved and when 1 dependency finished executing, there wasn't another container running atm and we marked it as crashed which is obviously not true.
So what we have done now is, that we account for 2 more container states i.e crashed/created. Crashed is that a container exited but with a non-zero exit code and created is that it is up and waiting for the service it is dependent on to finish it's execution so this one can start. Using these 2 new states, we see if we have any crashed container - we mark that app as failed and then if we have any container in created status or in starting status (healthcheck not green which we say is starting) we mark it as deploying and finally if exited containers (containers which exited with 0 exit code) plus running containers is the total number of containers we have, then we mark it as running.