Installation Roles vs. Post-installation Role Assignment (or pets vs. livestock)

[Stephen Gallagher]

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

One topic that keeps coming up on other threads that I think we need
to address first is when and where roles are assigned and whether they
can be modified after installation. There are two general trains of
thought here (maybe more; please chime in if you see other approaches).

First, for those of you who haven't heard the "pets vs. livestock"
metaphor, it goes something like this: Traditional datacenters are
like pets. You have a few beefy machines dedicated to one or more
tasks each. You maintain them, care for them and nurse them back to
health if they get into trouble, much the same way that a pet owner
would take care of their dog, cat, ferret, etc.

On the other side of the fence, you have the DevOps/Rapid
Deployment/Rapid Recovery folks who treat their environments more like
cattle. They have lots of redundant, scale-out VMs that serve a single
purpose and if they begin to have issues (memory pressure, intrusion,
chaos theory progression), they are cut down and replaced with a new,
pristine copy. This is analogous to livestock, where if one cow stops
producing milk, it's usually served as hamburgers shortly thereafter
and the farmer goes and buys another cow.

So I think we need to take a look at which of these two approaches we
want to be addressing. Or if we intend to try to handle both. It's my
understanding that the Fedora Cloud Working Group is *very* heavily
focused on addressing the "livestock" side of this argument, so we may
want to keep that in mind (and I've CCed Matthew Miller to represent
that group in this discussion).

If we choose to address the "pets" scenario (aka the traditional
infrastructure scenario), we probably need to be looking at role
assignment as an API (as suggested by Miloslav). Essentially, we
should build an interface into the system that allows us to configure
a role on demand - providing it the necessary configuration
information - and have it produce a system that corresponds to our
vision of an integrated solution. This API should be invokable either
at Kickstart time or remotely via a console such as Cockpit or
Satellite after installation and should have the same exact effect in
either case.

However, if we're looking more at addressing the "livestock" scenario,
then we probably DO only care about the initial deployment being
correct, which may be done via Kickstart or simply having a set of
pre-generated VM/Container images that can be booted with an API to
assign the configuration the first time it comes up.

These are *very* different deployment strategies, and we need to
determine which that we as the Fedora Server want to be pursuing
before we go any further, in my opinion.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlKGIxIACgkQeiVVYja6o6MFjgCfTrcFEQJXyZwwLeaiayiTEgPx
h9gAn18zpkv7gUOAJgTCY0XbVF/PllnH
=pv+C
-----END PGP SIGNATURE-----