Fedora server implementation straw man

[Miloslav Trmač]

(I apologize for getting to this so late.)

2014-01-27 19:33 GMT+01:00 Kevin Fenzi <kevin at scrye.com>:

> * The roles use cockpit to manage and configure the server role post
>   install.


Cockpit should be *a* mechanism, but not the only mechanism:
fully-automated, kickstart-driven installs need to be possible.  One thing
that would work is an executable (fedora-role-deploy?) that accepts a
possibly empty kickstart-like service-specific "deployment configuration";
kickstart can invoke this directly, perhaps with a here-doc, and cockpit
can generate the configuration from a GUI and call that executable.  To get
even more fancy, fedora-role-deploy could interactively ask if something is
missing in the deployment configuration, but that's perhaps inviting too
much complexity.

* We create a new fedora-server-$role package for each role. This role
>   package contains the 'glue' we add to turn this into a fedora server
>   role from just a install with the packages and local config. We will
>   need to come up with guidelines and what these packages will contain,
>   but:
>
>   7. We may have a fedora-server-base or fedora-server-common package
>   to contain common/base stuff all roles need/user and make the role
>   packages require it. We would need to be very careful about updates
>   of this however.
>

Ability to cleanly upgrade is a significant concern here.  I think the
worst case is a major update to something like a database, involving a
format change, where you need to keep the old version running to do a data
dump, and have the new version installed at the same time to receive the
data dump.  That would require:

   - The old and new version of the underlying software (not necessarily
   the role) need to be parallel-installable.  (This does not mean that
   *every* two versions of the underlying software need to be
   parallel-installable.)
   - A role package that defines the new version needs to be installable
   while the old version of the underlying software is still running.  So, no
   Conflicts:, at least not always.  To extend this, the role system might
   simultaneously want to still be able to handle the old version of the role,
   so that e.g. monitoring or backups still work while the dump is in progress.

Another desirable feature would be to have a non-destructive upgrade
opportunity: install a newer version of the role package, ask it to do an
upgrade, and have the role package refuse an upgrade because it would lead
to data loss (or require non-trivial downtime or administrator's manual
involvement).

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.
   - "Minor" updates (no functionality loss, no human involvement) could
   happen automatically from a %post or %posttrans script.
   - (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).

Downsides:

   - We would need another mechanism to notify the user that the
   interactive package update is insufficient and (fedora-role-deploy
   --upgrade) needs to be run.  (Or would we limit the major upgrades only to
   new Fedora Server releases?)
   - 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.)

What do you think?
    Mirek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/server/attachments/20140303/2f287749/attachment.html>