-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 03/03/2014 03:57 PM, Miloslav Trmač wrote:
(I apologize for getting to this so late.)
2014-01-27 19:33 GMT+01:00 Kevin Fenzi <kevin(a)scrye.com
<mailto:kevin@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:
Well, we've also been talking about having Cockpit provide the client
side deployment API, so we should probably consider different
terminology. Certainly Cockpit-the-webui must not be the only approach.
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.
I'm not sure exactly where the GUI is coming into play here, but the
way I envisioned things was that we'd have a command-line tool that
could talk the D-BUS API that we could invoke in the kickstart %post.
This of course assumes that such a D-BUS API listener can be running
in %post; I'm unclear on that.
We would also need to make it clear that the fedora-server-$role would
have to be in the %packages section, since installing packages in
%post is a Bad Idea.
* 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.
Major upgrades with format changes are definitely one of the larger
question marks left in this effort and certainly not something we can
punt on and hope doesn't come up.
You are probably right that we need to guarantee both
parallel-installability as well as the ability for them both to be
running at the same time (since I can certainly foresee things like a
major FreeIPA upgrade being managed by a replication service instead
of a dump-and-reload).
Unfortunately, at the moment I have nothing constructive to add to
this. I could say something hand-wavy about containers, but I don't
think that's going to be feasible for F21 at least. (And I'm not sure
if it's a solution or a hack).
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).
Yeah, I think this is clearly something we want and need to design
for. Of course, when selecting Roles to focus on, we should also be
examining a project's history for how it handles dangerous upgrades
(particularly frequency).
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?
* "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. I'd like for us to be using systemd drop-directory
snippets instead, so we can do upgrades and the like on ExecStartPre
triggers instead.
* (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.
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?)
I'm definitely +1 on limiting major upgrades to new Server releases
(until and unless we start deploying Roles in fully contained
environments like a VM or kernel namespacing).
* 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.
What do you think? Mirek
I'd like to see some of the above details filled in. I'm hesitant to
make a judgement about this yet.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird -
http://www.enigmail.net/
iEYEARECAAYFAlMY8DQACgkQeiVVYja6o6MNdwCgqn8o24QCtL9fCqHDhKhjevQx
iVsAn1mTOD94TmoQeNPYWLiUp/P9bHSO
=gEGO
-----END PGP SIGNATURE-----