Fedora server implementation straw man

[Miloslav Trmač]

2014-03-06 23:01 GMT+01:00 Stephen Gallagher <sgallagh at redhat.com>:

> > So, I'm leaning towards a design where fedora-server-$role is not
> > a package for a /specific version/ of a role, but for /all past
> > versions/.  Therefore:
> >
> > * The user can always (yum update) a role package,
> > non-interactively, without actually deploying an updated version of
> > a role.
>
> I'm really not sure what the mechanics of this would look like. Could
> you go into some more detail here?
>

fedora-server-role-postgresql.rpm contains all of:
/usr/share/fedora-roles/postgresql/__init__.py # common metadata
/usr/share/fedora-roles/postgresql/1/role.py # implementation, major
version 1
/usr/share/fedora-roles/postgresql/2/role.py # implementation, major
version 2
/usr/share/fedora-roles/postgresql/3/role.py # implementation, major
version 3

Adding a major version would add a subdirectory / subclass, not remove any
of the previous ones.  (Well, we would probably feel the pressure to remove
the very old ones so that we don't have to keep porting them to new Python
versions and the like.)

> * "Minor" updates (no functionality loss, no human involvement)
> > could happen automatically from a %post or %posttrans script.
>
> Please no.
>
> I, for one, have been working hard these last weeks on eliminating
> scripts from packages wherever possible. %post scripts make life very
> difficult for things like virt-sysprep and the proposed Fedora Atomic
> initiative.


So %post vs. non-%post and automated vs. maual is a completely separate
discussion.  We seem to be in agreement about actually making minor updates
automatically, are we?

Nevertheless... I don't think "%post is bad" approach makes sense.  We can
have stateless storage of software (as opposed to configuration or data),
but *the computer* is not stateless!

Moving the scripts to auto-started systemd units still means that there are
scripts affecting state, only they are now harder to find and harder to
manage.

Also, the restriction to stateless storage of software is limiting and
leads to optimizing things the wrong way: we save time and complexity
during software installation ("only place a file in this directory") and
pay for it on every application start ("read all the files, resole
conflicts, build an in-memory index for speed") or in maintenance overhead
("don't forget to run update-cache-file or your changes won't be
visible").  Having an API
"add-this-information-to-the-system-wide-database" invoked during
installation would allow more validation checking, and maintaining the
information in a file format optimized for run-time efficiency.


> * (fedora-role-deploy --upgrade) or something similar could be used
> > in an interactive context (CLI / Cockpit) to actually perform a
> > major update, with the above-mentioned ability of a role to perform
> > a feasibility check, to ask for more information, or to confirm
> > that the administrator can accept a downtime needed for
> > non-trivial migration (asking interactively or using an updated
> > deployment configuration file provided as input).
>
> This would be nice-to-have, but until I see some more concrete
> information about how one might handle this at the filesystem and
> service level, I remain skeptical.
>

I'm not sure what information you are looking for; below is what I was
thinking of in more detail, though perhaps this is all trivial.

>From the POV of the shared infrastructure:

# role_name = "postgresql"
role = System.get_role(role_name)
installed_version = role.installed_major_version
latest_version = role.latest_major_version
while installed_version < latest_version:
    next_version = installed_version + 1
    role_major = role.major_version[next_version]
    try:
        role_major.upgrade(role, deployment_descriptor) # checking and
possible interaction happens here
    except (UpgradeAborted, UpgradeFailed):
        break
    role.installed_major_version = next_version
    installed_version = next_version

(i.e. we only need to support upgrades "one step at a time")

>From the POV of the role implementation, the "upgrade" method would be
driving all of this (assuming postgresql-$old_version and
postgresql-$new_version can be installed in parallel):

   - (Optionally) verify consistency of the current installation
   - (Optionally) verify features are supported in the new version
   - (Optionally) ask the user for confirmation if migration has not been
   pre-approved in the deployment descriptor
   - Ensure that postgresql-$the_next_version is installed
   - Tell postgresql-$old_version to start refusing write requests, or just
   stop the postgresql-$old_version service altogether
   - Migrate data; whether this is in-place or to a copy is up to the role
   implementation.
   - Stop and disable postgresql-$old_version, start and enable
   postgresql-$new_version


> * fedora-server-$role could not depend on versions of the
> > underlying packages that it supports; it would need to install them
> > from fedora-role-deploy in the worst case.  (In the common case,
> > the user would ask for a $role comps group, and get both
> > fedora-server-$role and the appropriate versions of the underlying
> > packages.)
> >
>
> Mandating that packages are installed from fedora-role-deploy would
> have serious negative repercussions on trying to do things in anaconda
> %post.
>

For the anaconda %post case, the user would be expected to list an
appropriate comps group in %packages.
     Mirek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/server/attachments/20140307/701cb082/attachment.html>