"Jóhann B. Guðmundsson" (johannbg@xxxxxxxxx) 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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
