Custom cronjobs

[Zoey2936]

For example, by triggering a script inside one of the nextcloud volumes

[szaimen]

Why would you need this?

[Zoey2936]

#1581 that would also be a usecase

[szaimen]

#1581 that would also be a usecase

could be a follow-up for #1581 then

[Zoey2936]

what do you mean?

[szaimen]

I added it to #1581 (there is a follow-up section)

[Zoey2936]

i see

[szaimen]

I thought about this a bit more and currently there are no plans to add support for this as you can use host cronjobs for this.

[szaimen]

Generally the idea would make sense but we need to also consider deployment options like the manual-install and the helm chart where the mastercontainer is not available

[gggeek]

Fair point.

So far, there are no job schedulers available at all within the stack, so adding one within the MC should not break anything that is already running / in place.
But if the non-MC containers come to rely on having jobs scheduled, we should provide an alternative to the MC being available for running them.

How to achieve that: off the top of my head I can propose this (and feel free to come up with better ideas, it does feel sub-optimal even as I type):

• manual install: when generating the yaml file, add to it the definition of one extra container which will run the jobs. When doing that, we should parse the job defs found in containers.json and add them to compose.yaml. Nothing that jq/yq can not do, even though it might look like dirty code (this might be in fact a good reason to use Ofelia as scheduler, as it is easy to bundle it as standalone container. Or maybe just build a container running crond and call it a day? But then we have to prepend to every job spec something like docker exec -t $container )

• helm charts: I am out of my depth here, as my experience with the K8s ecosystem is limited. I think there is a concept of cron jobs that can be defined, but those spin up new pods instead of running inside existing ones. Which we might possibly adopt as strategy even inside the MC-managed-stack, but it opens up an altogether different can of worms, I think, as it means checking how the AIO containers react to being started up with a different command that start.sh...

[gggeek]

As Jake would say: "I have seen the light!"
Taking a break and having some food (and coffee!) always helps with lateral thinking.
Either that, or I had too much wine :-P

The maximum-simplicity-design solution is: always run the MC container, even when in manual-install mode and in K8s contexts. But, when in those contexts, do not start its web GUI, nor its upgrade/backup crons.

This way the MC can still deliver the different services which can be considered "core" to the platform:

• acting as a docker-socket proxy for other containers (cf allow to expose docker socket via port #3230)
• acting as a job scheduler for other containers (cf Custom cronjobs #2912)
• acting as an SSO server for other containers (cf “one-time” tokens #7686)
• allow a cli user on the host to use the MC cli tool to run one-off tasks, such as unscheduled backups (cf Add a cli tool to allow easy management of the AIO stack #8156, Improve management of app containers start/stop: make it more flexible and more automatic #8158)
• act as an HARP proxy ?

[szaimen]

I fear the mastercontainer will not work with the helm chart as the docker socket is technically not accessible there afaik

[gggeek]

Ok, so in the helm chart just set up the MC not to act as docker-socket proxy.
It starts to feel that we are stretching the MC a bit in too many directions, but I would say we are still a few inches on this side of the "building a frankenmonster" precipice.