2014-03-06 23:01 GMT+01:00 Stephen Gallagher <sgallagh@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