Cron Provider?

[Stephen Gallagher]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed 06 Mar 2013 06:59:44 PM EST, Russell Doty wrote:
>  Do we need to consider a cron Provider?
>   
Consider? Yes. Actually do it right now? No, not at all.

The issue is that cron's future is uncertain. It will remain in use in
the real world for many years at the least (and most likely we'll
retain legacy support for it in the future) but there is a new player
in this field. systemd recently added the ability to manage scheduled
events, and it does so with a language that is much closer to that of
a calendaring program's scheduling than it is to cron. So my major
concern here is that there may not be a way to model the scheduling
provider (let's call it that, rather than cron provider) in such a way
that it can account for both formats.

So yes, we *could* build a scheduling provider, but I think we want to
think very hard about what level of scheduling we want to support.
systemd's scheduler is a very large superset of what cron is capable
of, so I suppose we could build that first and then extend it later to
support the advanced systemd features.

I'm CCing openlmi-devel here to expand the conversation.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.13 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlE4ig8ACgkQeiVVYja6o6PuEQCeN5m2oEE1QQaL8rffvaF3Nxs2
> PLYAnjWSdCZje5OpkrUROQdaiHFU7+Qw
> =SNRn
> -----END PGP SIGNATURE-----

[Stephen C. Tweedie]

Hi,

On Thu, 2013-03-07 at 07:37 -0500, Stephen Gallagher wrote:
>  On Wed 06 Mar 2013 06:59:44 PM EST, Russell Doty wrote:
>  > Do we need to consider a cron Provider?
>  > 
>  
>  Consider? Yes. Actually do it right now? No, not at all.
>  
>  The issue is that cron's future is uncertain. It will remain in use in
>  the real world for many years at the least (and most likely we'll
>  retain legacy support for it in the future) but there is a new player
>  in this field. systemd recently added the ability to manage scheduled
>  events, and it does so with a language that is much closer to that of
>  a calendaring program's scheduling than it is to cron. So my major
>  concern here is that there may not be a way to model the scheduling
>  provider (let's call it that, rather than cron provider) in such a way
>  that it can account for both formats.
>  
>  So yes, we *could* build a scheduling provider, but I think we want to
>  think very hard about what level of scheduling we want to support.
>  systemd's scheduler is a very large superset of what cron is capable
>  of, so I suppose we could build that first and then extend it later to
>  support the advanced systemd features. 
Starting with cron would also have the advantage of building the most
portable code first; it would make sense to add the more
version-specific options later.

--Stephen

[Stephen Gallagher]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/07/2013 08:27 AM, Stephen C. Tweedie wrote:
>  Hi,
>  
>  On Thu, 2013-03-07 at 07:37 -0500, Stephen Gallagher wrote:
> > On Wed 06 Mar 2013 06:59:44 PM EST, Russell Doty wrote:
> >> Do we need to consider a cron Provider?
> >> 
> > 
> > Consider? Yes. Actually do it right now? No, not at all.
> > 
> > The issue is that cron's future is uncertain. It will remain in
> > use in the real world for many years at the least (and most
> > likely we'll retain legacy support for it in the future) but
> > there is a new player in this field. systemd recently added the
> > ability to manage scheduled events, and it does so with a
> > language that is much closer to that of a calendaring program's
> > scheduling than it is to cron. So my major concern here is that
> > there may not be a way to model the scheduling provider (let's
> > call it that, rather than cron provider) in such a way that it
> > can account for both formats.
> > 
> > So yes, we *could* build a scheduling provider, but I think we
> > want to think very hard about what level of scheduling we want to
> > support. systemd's scheduler is a very large superset of what
> > cron is capable of, so I suppose we could build that first and
> > then extend it later to support the advanced systemd features.
>  
>  Starting with cron would also have the advantage of building the
>  most portable code first; it would make sense to add the more 
>  version-specific options later.
>   
While I agree with that in principal, I need to make the point that
I'm not sure we can build a CIM model for cron that will extend to the
systemd approach at all. They may ultimately need to be two separate
models, at which point we'll need to figure out how to manage the
transition (which is what OpenLMI is trying to avoid).

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.13 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlE4mVEACgkQeiVVYja6o6OUMQCgmB3ltfn76/4ax0VFBOVqicT6
> 7WYAoIKpsQ6as+G9MmTXz6YPVxXdWLnp
> =4aYI
> -----END PGP SIGNATURE-----

[Tomáš Smetana]

On Thu, 07 Mar 2013 08:42:41 -0500
Stephen Gallagher <sgallagh(a)redhat.com&gt; wrote:

>  >> So yes, we *could* build a scheduling provider, but I think
> we
>  >> want to think very hard about what level of scheduling we want to
>  >> support. systemd's scheduler is a very large superset of what
>  >> cron is capable of, so I suppose we could build that first and
>  >> then extend it later to support the advanced systemd features.
>  > 
>  > Starting with cron would also have the advantage of building the
>  > most portable code first; it would make sense to add the more 
>  > version-specific options later.
>  > 
>  
>  While I agree with that in principal, I need to make the point that
>  I'm not sure we can build a CIM model for cron that will extend to the
>  systemd approach at all. They may ultimately need to be two separate
>  models, at which point we'll need to figure out how to manage the
>  transition (which is what OpenLMI is trying to avoid). 
Cron might be an interesting modelling exercise... There are user crontabs,
scripts in /etc/cron.{hourly,weekly,monthly}, package-specific crontabs
in /etc/cron.d, system-wide /etc/crontab.  And we might want to model and
monitor the running/finished jobs as well.  I admit I don't know much about
systemd timer units. However I suppose systemd might make it easier to find
logs of a particular job run at least (and this would be a required feature I
assume).

I'm only afraid that both the cron and systemd are config-files driven and we
probably won't avoid parsing/editing the files. Which is ugly.

Regards,
-- 
Tomáš Smetana
Platform Engineering, Red Hat