Proposed F19 Feature: systemd features

[Bill Nottingham]

"Jóhann B. Guðmundsson" (johannbg at gmail.com) said: 
> On 01/31/2013 03:51 PM, Bill Nottingham wrote:
> >I would be tempted to say:
> >   "Anything running at a core system level where a dependence on a separate
> >cron daemon may be unwanted (or a bad idea) should be migrated, and nothing
> >else for now until we have a clearer perspective on the future."
> >
> >Given that list that would be migration of:
> >mcelog
> >mdadm
> >ovirt-node
> >prelink (?)
> >tmpwatch
> >vdsm-*
> >
> >But I'm open to other ideas.
> 
> Am I supposed to assume you are working migrating this?

I was asked people to take a look at what the functionality can do, what
it may mean to migrate, and what we want to offer to our users, in the
short and in the long term.

The thing about migrating SysV services is that we didn't have to at
the start, and yet they'd still work, in systemd, without change.
(For the most part).

And admins could use the old tools adminms were used to in SysV land
(/sbin/service, chkconfig, etc) with systemd, and they'd work and
give them consistent output for both the native services, and the ones
they hadn't got around to migrating yet.

Here, while systemd has basically subsumed the functionality of
cron (minus user jobs), it hasn't subsumed any of the infrastructure -
there's no compat.

In any case, to look at 'we have this functionality... now what':

1) migrate some cron jobs

Then, system scheduled tasks are in two places. Admins can learn and
cope, and have to go looking in multiple places and remember which tools
to deal with which scheduled task type. It's not ideal. And if we do
so, it's good to have some clear criteria to help admins decide where
to find what they're looking for. You started working here - you
suggested 'ones that come with daemons/services', I looked, and
thought perhaps 'ones that live at a level below
everything else, including the ones below daemons and services'. It's
just different ideas as to where to draw the line.

But it's still not a great interface to have users end up in - two
infrastructures running in parallel.

2) migrate all

This is cleaner, inasmuch as we can tell everyone "hey, everything
is over here now". But it's still a full break of interfaces and
paradigms, and it easily devolves to #1 as soon as something doesn't
get done, or new stuff is added. (After all, we can't remove support
for cron-format jobs.)

3) introduce compatibility

The cron and at interfaces aren't complex at all. It shouldn't be
too hard to have a generator that reads crontab and cron.*, and
the at queue, and creates the approprate timer files for systemd,
in the same way that the fstab & sysv generators run. We could
even have new versions of the crontab and at commands that do the
right thing.

That's extra work that would need to be done, and we would
have to actually be obsoleting cron here (can't have two things
running the same jobs), so it's obviously not F19 material. We'd
also need a mechanism for user jobs. But if this is where we want
the system to end up, this is what we start working towards and
writing code for. Once that lands, transitioning can actually be
done much more smoothyl with less user disruption, and having
different jobs in different formats doesn't hurt nearly as much.

Bill