Is it possible to give some pointers to packagers how systemd timers should look like in openSUSE?
I've spent a few minutes searching the wiki if there is dedicated information on it but haven't found anything.
openSUSE:Systemd packaging guidelines does not have anything on timers.
Could easily be that I missed it but I think this tracking bug is a good place to indicate some pointers packagers could use if they have not been in touch with systemd-timers much.

Thanks for bringing this idea. I've created a systemd timers section at opensuse wiki [1]. It covers the basic packaging schema. I suppose that it can happen that each package can need a little bit different approach as the purpose of the former cron entry can be various.

So anybody can enhance this wiki page when he/she encounters a situation that can be interesting for other packagers dealing with the cron->timers migration. 

[1] https://en.opensuse.org/openSUSE:Systemd_packaging_guidelines#Systemd_timers

Disclaimer: I personally have no strong objections against systemd in general. Thus I don't want to open yet another systemd discussion.

But my concern for this particular case is that systemd is not started in containers while it would be possible to start cronie in a container.

Were there any considerations about this?

Maybe I'm overlooking something but e.g. accepting this request would make unbound unusable in a docker container:

https://build.opensuse.org/request/show/653901

But especially a DNS recursor is something you likely want to run in a elastic container deployment.

(In reply to Michael Ströder from comment #3)
> But my concern for this particular case is that systemd is not started in
> containers while it would be possible to start cronie in a container.

I'm not a container expert so this is probably a question for Flavio. 

@Flavio: Can you please help here? Thanks!

It is true that running systemd inside of an **application** container (like one started by Docker) is tricky. However this isn't something really needed on a daily basis. Application containers have a completely different use case from system containers (like the ones created by LXC and LXD).

Because of that I would find really really wrong to have someone running cron jobs inside of application containers.

I think you don't have to worry about containers (neither application, nor system) in this discussion.

Disclaimer: I'm not a container expert.

(In reply to Flavio Castelli from comment #5)
> It is true that running systemd inside of an **application** container (like
> one started by Docker) is tricky.

AFAIK it is not recommended to modify a container setup to allow running systemd because of some security implications. Thus there won't be systemd available in normal container setups.

> However this isn't something really needed
> on a daily basis. Application containers have a completely different use
> case from system containers (like the ones created by LXC and LXD).
> 
> Because of that I would find really really wrong to have someone running
> cron jobs inside of application containers.

Frankly I don't understand your answer.

Personally I think that running a DNS resolver like unbound in a Docker container on e.g. an elastic Kubernetes cluster is something users definitely want. Thus requiring systemd for installing and using unbound package is a real obstacle for such a setup.

> I think you don't have to worry about containers (neither application, nor
> system) in this discussion.

I strongly disagree.

General info for packagers dealing with the migration: Please see [1] for more information about enabling timers and mainly how to pick the correct preset package where to put your timer (systemd-presets-common-SUSE or systemd-presets-branding-openSUSE).

[1] https://en.opensuse.org/openSUSE:Systemd_packaging_guidelines#Enabling_systemd_unit_files

openSUSE will systemd.timers.
But will the user systemd.timers too?
I think not.
So we should offer both ways, so that the user can self decide what he/she want use.