-----BEGIN PGP SIGNED MESSAGE-----
On Tue, 10 Dec 2013 07:13:30 -0500
Stephen Gallagher <sgallagh(a)redhat.com> wrote:
I was too focused on the user experience explanation that I missed
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.
I think we should be very very careful there not to provide too much
help to attackers. :) "Oh, that machine is telling me it's the FreeIPA
server version foo. Cool"
* 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.
What implementation do you see for this? packages? config file?
== 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.
Yeah, or if it is peicemeal, make sure anything that goes out is tested
to not break things.
* *Upgrades* to major new releases that offer substantially
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 v2.0.22 (GNU/Linux)
-----END PGP SIGNATURE-----