[Fedora-packaging] Systemd guidelines architectural decisions to be made

[Toshio Kuratomi]

https://fedorahosted.org/fpc/ticket/31

Okay, we ran out of time at today's meeting so I'm going to post the list of
architectural decisions FPC needs to decide on in order to keep going on the
systemd guidelines.

Status report on bugs:
* I've submitted a patch to notting to fix the chkconfig bug introduced by
  having chkconfig fallback on calling systemctl:
  https://bugzilla.redhat.com/show_bug.cgi?id=616857
  We should be able to use chkconfig --no-redirect in our scriptlets once
  that's applied

* I've fixed a lot of bugs in the proposed scriptlets and added some notes
  about other issues discovered to the scriptlets on the guidelines.  Some
  of those issues lead to the decisions we need to make next:

= Triggers or no triggers =

notting raises the point in the Guidelines ticket that triggers are
conceptually the right tool for this job.  Additionally, I think that some
of the things we're trying to do are very difficult without triggers.  For
instance, telling the difference between a systemv init script that exists
from an old package versus a systemv init script that exists from a new
package is not possible just by using chkconfig.  So we can't tell using
just chkconfig if we are supposed to run a migration from systemv init
script to systemd or not:

foo-1.0 has only a SysV init script in /etc/init.d/foo
foo-2.0 has both a SysV init script and a unit file in
/lib/systemd/system/foo

foo-2.1 has both a SysV init script and a unit file.

If I do yum upgrade foo and it wants to install foo-2.1, how do I know if
foo-1.0 or foo-2.0 is what is being replaced in %post?  If I don't know,
then how do I know whether to try to migrate the runlevel information from
the systemv init script?

If other FPC members feel strongly that we still want to avoid triggers,
we can try to eliminate each of the corner-case scenarios and see if we can
avoid them but my present inclination is that triggers are the way to go.

= Migration of user customization =

A lot of the other discussion in the FPC ticket right now is how to migrate
information about what services are started.  This includes what runlevels
to migrate and also which commands to use to perform the migrations.  I'll
list the options that I can think of in a bit but I think the basic question
is: do we want the user's system settings to just work when they do an
upgrade or do we want them to start over with our defaults, redoing any of
their customizations?

== Starting over with the defaults ==
If the latter, the option that I think works best is to use systemctl enable
in if the package being upgraded from is a sysVinit user.  Using trigger
scripts, this would be implemented something like this:

%post
if [ $1 -eq 1 ] ; then 
    # Initial installation 
    # If a package is allowed to autostart:
    /bin/systemctl enable foo.service >/dev/null 2>&1 || :
    # No autostart:
    # /bin/systemctl daemon-reload >/dev/null 2>&1 || :
fi

# Note: the NEVR in trigger scripts should all be the version in
# which the package switched to systemd unit files and the comparision
# should be less than.  Using <= the last version with the sysV script won't
# work for several reasons:
# 1) disttag is different between Fedora releases
# 2) An update in an old Fedora release may create a newer NEVR
%triggerun -- foo < 1.0-2  
# Run this because the chkconfig --del in the SysV providing package won't
# fire unless the package is removed
/sbin/chkconfig --del bar >/dev/null 2>&1 || :
# I think that we need this as well
#     /bin/systemctl try-restart foo.service >/dev/null 2>&1 || :

# If the package is allowed to autostart, do the following
/bin/systemctl enable foo.service >/dev/null 2>&1
/bin/systemctl daemon-reload >/dev/null 2>&1 || :

(The %preun and %postun will remain as they are in the current proposal)

In this example, systemctl enable is working similarly to chkconfig --add.
It looks in the unit file for the Wanted-By entry.  Then it enables the
service in all of the targets listed there.

=== Some thoughts on this ===
Under this model, it would be most user friendly if we migrated to systemd
unit files all in one release cycle.  Failing that, it would be user
friendly to have a policy that pacakgers must not update from sysv to
systemd scripts over the course of a released Fedora.  The reasoning behind
either of those rules would be that services may be enabled or disabled when
a package updates from the systemV to the systemd version so we'd want to
minimize that happening when the user doesn't expect.

Failing either of those, this will only hit the user once per package that
they have installed that migrates from sysV to systemd which may or may not
be acceptable.

== Migrating the user's settings ==

If we do think that we should be migrating the user's settings then we need
to think about what customizations the user may have performed and how we
can migrate them to a systemd equivalent.  For the purposes of the
Guidelines, the user may have turned a service on or off in a particular
runlevel.  Of the runlevels that system v init provides, there are five that
have a definite meaning with a map into systemd: 1 => rescue, 3 =>
multi-user, 5 => graphical, 0 => poweroff, and 6 => reboot.  Of these, 0 and
6 don't seem to have any scripts in Fedora that are designed to start there
so we don't need to migrate anything that the user customized.

The other three can be migrated so that the user can use those targets under
systemd and have them start the same programs as they did when they were
using systemv initscripts.  Migrating a service for a particular target
seems to need to use explicit symlinking; systemctl doesn't appear to have
a command that does that.  The %triggerun script would look something like
this (the other scripts stay the same as the previous example):

%triggerun -- foo < 1.0-2
/sbin/chkconfig --del bar >/dev/null 2>&1 || :
if chkconfig --level --no-redirect 1 foo ; then
    ln -sf /lib/systemd/system/foo.service /etc/systemd/system/rescue.target.wants/ 2>&1 >/dev/null
multiuser=0
if chkconfig --level 3 foo; then
    ln -sf /lib/systemd/system/foo.service /etc/systemd/system/multi-user.target.wants/ 2>&1 >/dev/null
    multiuser=1
fi
if chkconfig --level 5 foo; then
    # If it's already in multi-user, it will be inherited automatically
    if [ $multiuser -eq 0 ] ; then
        ln -sf /lib/systemd/system/foo.service /etc/systemd/system/graphical.target.wants/ 2>&1 >/dev/null
    fi
else
    if [ $multiuser -eq 1 ] ; then
       # We have the option of disabling the service in graphical here to
       # match what the user explicitly customized their system to like
       # this:
       ln -sf /dev/null /etc/systemd/system/graphical.target.wants/foo.service
       # But we could also decide that this is not something that we're going
       # to migrate (as systemd itself sets graphical up as a strict
       # superset of multi-user).
    fi
fi
/bin/systemctl daemon-reload >/dev/null 2>&1 || :

= Migration between sysv and systemd settings post-package changes =
Also raised in the ticket is whether we should support moving back to
sysvinit.  My view on that is that we should allow a user installing and
customizing a systemVinit system in parallel to the systemd files without
getting in their way but we shouldn't explicitly support migration from
the default init system to another init system in the standard packaging
guidelines.  We can certainly have guidelines for each individual init
system that people who write scripts for them may follow but setting up
which runlevel-equivalents each of those start services in should be
independent of what's being done in systemd.

I think that's the basics of the issues we need to work on to keep moving
forward on the guidelines.  There's certainly more information and
informational questions that could be asked and answered to make informed
decisions here, though.  discuss away.

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/packaging/attachments/20110302/1955531f/attachment.bin