Proposal: FreeIPA Role for Fedora Servers Using Cockpit

[Stephen Gallagher]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 12/09/2013 07:45 PM, Simo Sorce wrote:
> On Mon, 2013-12-09 at 14:53 -0500, Stephen Gallagher wrote:
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>> 
>> As mentioned before, I've attempted to put together a
>> user-perspective on what "roles" should look like in Fedora
>> Server, using FreeIPA as a representative example. I want to
>> thank Andreas Nilsson of the Cockpit project for helping out
>> substantially with the mock-ups.
>> 
>> The proposal is fairly wordy, so I put it up on my blog for
>> perusal. I can copy it into the Server WG blog later, if we agree
>> it's not completely off-base.
>> 
>> http://sgallagh.wordpress.com/2013/12/09/proposal-freeipa-role-for-fedora-servers/
>
>> 
> Uhmmmm let me try to decipher what a role is in your view, based on
> the process you described.
> 
> 1. A set of packages 2. A configuration mechanism to make a basic
> configuration of such packages, including pre-requisites. 3. A UI
> (whether graphical or command line base doesn't matter) to drive 
> the process.
> 
> Is that all ?
> 


I was too focused on the user experience explanation that I missed a
few conceptual pieces I wanted to talk about. I'll write a second blog
post on that in a little while, but here is the basic gist of it:

== Mechanism ==
 * We want to have a role inventory so that we can trivially query
which roles are deployed on a target system (with additional per-role
meta-data). Ideally, I'd like to see us also presenting this inventory
via discovery mechanisms like Avahi or OpenSLP for other monitoring
tools to consume.
 * We should support role dependencies and conflicts. For example,
it's acceptable to have both the "BIND 9" role in our tool belt, as
well as the "FreeIPA DNS Server" role (which uses BIND 9 under the
hood but integrates its operation with FreeIPA). The latter should
only be possible to deploy to a server that already has the FreeIPA
role deployed, whereas the BIND 9 role could be deployed to a machine
without FreeIPA installed.


== Policy Compliance ==
We talked a bit about having strict upgrade policies and
backwards-compatibility guarantees. I'd like to highlight a few
specific policies we should require:
 * Updates must occur without requiring user intervention beyond
initiating it. No questions should be posed to the user.
 * Updates must be atomic; if a role incorporates multiple underlying
technologies (e.g. FreeIPA with 389 and MIT Kerberos), the complete
set must be upgraded together with a complete set of tested
components. Do not update piecemeal; it usually breaks.
 * *Upgrades* to major new releases that offer substantially different
functionality and that have no fully automatic upgrade path should NOT
be considered an update to the current role. E.g. a BIND 9 role must
not upgrade to a BIND 10 role. Instead, it should be expected that a
new role is created and tools *may* be offered to port the
configuration. (Note: Upgrade tools are absolutely not a short-term
goal. In practice, most environments would likely just deploy a new
role on a new [physical|virtual] machine anyway).

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlKnBWoACgkQeiVVYja6o6MCvgCgoatvVbIm/zx5LqD7qYakZXLz
5VAAoKcxF9qPIgfT2KyohmOsJvT2bdSP
=kB+c
-----END PGP SIGNATURE-----