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

[Miloslav Trmač]

Hello,
(Choosing a fairly random point in the thread, just because this
happens to illustrate my point.)

On Fri, Nov 15, 2013 at 6:28 PM, "Jóhann B. Guðmundsson"
<johannbg at gmail.com> wrote:
> On 11/15/2013 04:53 PM, Kevin Fenzi wrote:
> >
> > A home server/small business setup may have 5 different things
> > installed on a single server. We can easily do this with a netinstall
> > base to boot from and then they select the things they want via
> > installer or post install (via yum/comps).
> >
> Or they can just install a single role into a container or a run it in a VM
> on the " *one* beefy machine"

And... what OS does the "one beefy machine" run?  Is it a pet or livestock?

> We truly should not play blender here because the outcome will be just that
> a mess.

Actually, I'd say our role _is_ that of the blender.  Or,
alternatively, I think I'm arguing that the pet vs. livestock question
is irrelevant and possibly misleading in what we are trying to do
here.


There is a difference between pets and livestock, but _every site has both_:
* Even the pure-cloud, throw-all-instances-away deployments have a
critical pet component (the shared storage mechanism that keeps the
company/user's data).
* In a sense, every single startup of a daemon is a "livestock"
process that can be just restarted if it crashes[1]

Or, from another angle: for each application/deployment, there is a
scale of how automated the deployment is, and how much state is stored
locally and mustn't be lost, and how little manual work is required
from the sysadmins, all the way from "prototype being reconfigured by
changing #defines in the source code" (0%) to "completely stateless
arch-independent ISO image" (100%).

On this scale, there is a fairly definite point when pets become
livestock, and it is fairly close to the "completely stateless ISO
image" end.  _But that doesn't make all the rest of the scale (pets)
equivalent_.


We do need comprehensive, reliable, and easy to use software that
helps with configuration and deployment; we do need to minimize
manually managed state; we do need to remove manual work from the
sysadmins in general; and _that's_ the core of the work, both for
Server and Cloud, and whether any specific machine or VM this runs on
ends up as a "pet" or a "livestock".

Historically for servers we've found it acceptable to get perhaps to
60% of the scale, and Cloud wants to get to 95% so that it can be
called "livestock".  In the meantime, we're talking about a Server
product that does more for the administrators, perhaps getting us to
80-85%.

In any case, this is a _shared_ problem between Server and Cloud, and
it should be a shared design allow us to share work results.


I'm really not that worried about the pet/livestock difference,
because it's "only" a matter of getting bits to run.  As suggested
above, every single running process is, in a sense, a piece of
livestock [2], and every cloud deployment as a group is a pet; from
the point of user interaction

If, given anaconda source code and a repository of RPMs, getting to a
working interactive installation method, or kickstart installation
method, or image deployment method, is about a man-month of work (a
completely made up number), getting Fedora from 60% on the automation
scale to 95% will certainly take man-years (hopefully shared between
many people).

Focusing on the pets/livestock divide between Server/Cloud obscures
the work that we should be doing together.  We already have methods to
get the bits to run, let's start working on having useful bits.[3]


(Or, Stephen, to more directly address your post: In any case we need
a configuration API, and software that implements requests by that
API.  Whether that API is working with pets or livestock is not that
important in its design; if having that API shared between Server and
Cloud required some changes to how we treat server roles on an already
installed machine, that would probably be well worth it.)
     Mirek

[1] ... if it hasn't corrupted the "pet" data storage mechanism.
Corner cases always kill analogies.
[2] And we _can_ actually implement the various server roles in that
way, using a "server+cloud mail server configuration tool" to create
$data and use said $data to set up the mail server role; to
reconfigure the server, load $data back into the tool, modify it to
get $data_v2, and "unistall+reinstall" the server role using $data_v2.
 There doesn't need to be any huge difference between the underlying
Cloud and Server mechanism.
[3] This is of course somewhat hand-wavy and actual
installation/deployment does need a lot of careful thought and effort;
this is not meant to denigrate that work.