One of the compose files I started using recently consists of a few verifier/setup containers that exit soon after starting. Outside of getting rid of these containers from the compose file, is there another more graceful way to prevent these containers from triggering the "Stopped" status?
Compose status both "Up" and "Stopped"
-
- OMV 8.x
- resolved
- kamild1996
-
is there another more graceful way to prevent these containers from triggering the "Stopped" status?
The compose plugin shows you the status of containers. If you don't want the stopped status and you can't fix the stopped container(s), remove the stopped container(s).
-
The compose plugin shows you the status of containers. If you don't want the stopped status and you can't fix the stopped container(s), remove the stopped container(s).
But that's the thing, there's nothing to "fix" about these containers. They're working as intended, they shouldn't be running constantly alongside the proper containers running the required services.
I could remove them, but one of the operations the "verifier" container performs is making sure any new environment variables/whole new required containers/etc. are present after the main container gets updated. This means that if I remove/comment out the "verifier" container, it would be in my best interest to re-add it after each update, and remove it yet again after it's finished.
If there was a way to eg. mark such containers as "optional" within the compose file and making it so that such marked containers won't assign the "Stopped" status when they're down, it would be a great time saver.
-
-
there's nothing to "fix" about these containers. They're working as intended, they shouldn't be running constantly alongside the proper containers running the required services.
And the plugin is just showing that they are stopped which is not wrong.
If there was a way to eg. mark such containers as "optional" within the compose file and making it so that such marked containers won't assign the "Stopped" status when they're down, it would be a great time saver.
How is it saving time? It is literally just a status column. This would not be a small amount of effort, it would be more code to maintain, and it would likely slow down the Files tab for everyone because it would have to parse every compose file. Why not hide the column and look at container status in the Services or Containers tabs?
-
And the plugin is just showing that they are stopped which is not wrong.
It's technically not wrong, it's just that it reduces the usefulness of that column. In a hypothetical scenario where:
- compose file #1 has 6 critical containers and 2 optional ones, but one optional container is down,
- compose file #2 has 4 containers all critical, and one of them is down,
both compose files show up as "Up" and "Stopped", but one downed container is an actual problem only on one of them. Additionally, if a critical container does go down in compose file #1, it won't be signaled by the "Status" column, since nothing will change there.
Color-coded status badges could be used to quickly identify problems within compose files. But in its current form, the "Status" column does not seem to provide any more information than the "Uptime" column already does. The "Services" and "Containers" tabs do exist, but they lack the grouping of the "Files" tab, where one entry = one compose file = one application, so they're not as readable as the "Files" tab.
It's all just a minor UI QoL issue though. If implementing this would really be such big trouble, I won't press the issue. Thanks
-
And how would the plugin know a container is optional? I mean I understand what you are saying but you aren't running a production enterprise deployment here. If you have to check on a container, those few seconds aren't going to be a big deal.
But in its current form, the "Status" column does not seem to provide any more information than the "Uptime" column already does.
Hence why the uptime column is hidden by default. It is just there because I get that info for free.
The "Services" and "Containers" tabs do exist, but they lack the grouping of the "Files" tab, where one entry = one compose file = one application, so they're not as readable as the "Files" tab.
If you sort or filter by the project name, that should be the same grouping as a "File" unless you do something really strange in the compose file.
If implementing this would really be such big trouble, I won't press the issue
I will look at it but if it slows down my Files list or the code is too much to maintain, I don't want it.
-
-
I was able to add it for "free" with minimum code. It will just require recreating containers since that is the only time compose applies a label.
add optional container label to skip status · OpenMediaVault-Plugin-Developers/openmediavault-compose@81994c4Signed-off-by: Aaron Murray <plugins@omv-extras.org>github.comExample of what would need to be added below:
Codeservices: db-init: image: migrate/migrate restart: "no" labels: - "openmediavault.compose.optional=true"I will release it when I get a chance.
-
8.1.24 in the repo now.
-
8.1.24 in the repo now.
I grabbed it and added the label to the applicable containers, worked perfectly, didn't even have to down the containers before "upping" them up, the label caught on and the "Stopped" badge is gone.
Thank you!
-
-
kamild1996
Added the Label resolved -
kamild1996
Added the Label OMV 8.x
Participate now!
Don’t have an account yet? Register yourself now and be a part of our community!
