Improve management of app containers start/stop: make it more flexible and more automatic

[gggeek]

Multiple discussions in this forum seem to indicate a need to improve how the "app" containers (for lack of a better name: all containers managed by the MC) are started/stopped.

• the current logic for starting/stopping them is opaque. It is not clear if the app containers get stopped when stopping the MC or if they are not
• the current logic for starting/stopping them seems to be pretty much intertwined with the backup and upgrade operations, whereas, imho, it should be possible to start/stop containers as a separate, standalone operation
• worst case scenario, it should be possible to mark a single container as 'off' (ie. enable/disable), to prevent the MC from trying to start it. This for the emergency situation of the container being in such a broken state that it is a security liability or that it goes in a boot loop consuming resources and/or preventing other containers from finishing their boot

I propose the following logic:

• the MC starts automatically the app containers on its start by default
• the MC stops automatically the app containers on its stop, instead of delegating this to docker
  • this allows for better timeout management and is surely what 99% of users expect
• for upgrading the MC container image without downtime of the app containers, it will save a "flag" variable (possibly in a file in its data volume?) that is checked by its shutdown handler and, if present, tells it not to stop the app containers
• that "flag" could be used in Compose / Kubernetes contexts, where the container shutdown would be taken car of natively by the platform

[szaimen]

Hi, i am not sure about such a change. This needs to be considered carefully and probably means a huge rewrite. For example what is the UX if the instance is not yet configured (initial steps are not done yet).

Btw you can already automate stopping and starting of sibking containers e.g. by so: https://github.com/nextcloud/all-in-one#how-to-stopstartupdate-containers-or-trigger-the-daily-backup-from-a-script-externally

[gggeek]

Related: #6454

[gggeek]

For example what is the UX if the instance is not yet configured (initial steps are not done yet).

Without going in detail, I think that this is quite easy to solve:

• web gui: do not propose the button to start the containers
• cli: the command to start them fails with an error message "initial configuration not yet done"

[gggeek]

Related: #6268

[gggeek]

Related: #6156

[gggeek]

Related: #5468

[gggeek]

Related: #1502

[gggeek]

PS: trying to make my opinion a bit more clear:

I fully appreciate all the effort that went into making the AIO experience as AutoMagic as possible.
Launch it with a single command, set it up via a GUI, and be done with it. With a couple of clicks, backups and upgrades can also be configured.
When it works, it works flawlessly.

In my opinion, the way the AIO is architected and works is not so good for users who require more "control". I would put into that category both expert syadmins who want to tweak the installation to run in enterprise-y contexts (and there seems to be a lot of those commenting here) and more casual tinkerers who simply want to be able to troubleshoot issues when things are not working as expected.

At the moment, it feels that the troubleshooting experience is not so great, and the integration story could be improved. There are many howtos and faqs, but most of them involve long lists of arcane commands, which look like they might work only in a few cases.

Could we make that better?

I do not think that we should strive for AIO to be perfectly useable by "your grandma", if that becomes detrimental to useability for the more experienced. After all, when setting it up, one should have basic notions of ports, ip addresses, disk space. A command-line is required to start AIO via Docker, and the user has to have been set up as either sudoer or be in the Docker group. One needs a license before being allowed to drive a car. With great power comes great responsibility, etc...

Designing any app in a way that is at the same time solid, featureful and extendable takes careful design.
Having the possibility of driving configuration both by env vars and via a GUI takes coding effort.
The same goes for implementing both a CLI and a GUI interface for management.
And of course, it is hard to foresee the all the crazy ways users will want to (ab)use one's software and plan for it from day one.

But having solid foundations provides both robustness and flexibility to the layers on top.

This is why I am pushing for adding more "control". Suggestions #8156, #8129, #8139, #2912 (reply in thread) all go in the same direction.