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

[Simo Sorce]

On Sat, 2013-11-16 at 13:25 +0000, "Jóhann B. Guðmundsson" wrote:
> On 11/16/2013 03:56 AM, Simo Sorce wrote:
> > [strawman: Let me replace livestock with 'bee', as proposed by my
> > colleague Adam, bees are really throwaway from the Hive:)  ]
> >
> > My point is even simpler, the bees idea can work for some software,
> > usually purpose-built by the mentioned DEvOps to be throw-away friendly,
> > where all the state is kept on a separate redundant database or
> > filesystem and so on.
> >
> > We should work to make Fedora as friendly as possible to those
> > workloads.
> >
> > But most of the software we have now is not throw-away that way, so
> > concentrating on a system that only cares for bees would miss the point.
> >
> > Whether a Server is a pet or a bee is a choice of who installs it it
> > should work well in both roles, as well as we possibly can.
> >
> > Of course you can't expect to install 15 different roles on the same
> > machine and expect nothing conflicts and all performs great, but that is
> > not the point either.
> >
> > We build roles as collections of software and reasonable defaults in
> > configuration so that a collection of programs work together to perform
> > a well defined task. In some cases multiple roles will be able to
> > coexist (database role + web server role for example).
> >
> > In some other cases roles will conflict. In that case it will be nice to
> > be able to instantiate roles in different containers if possible, for
> > example, but in order for that to happen containers will need to improve
> > quite a lot, I do not think we can depend on that as a given yet.
> 
> What you say there is the state were we are at this time then why not 
> simply drop the effort of ServerWG altogether and leave things as they are?

Sorry to say this bu you look to me like someone with a strong case of
black-white-itis. It seem you can either conceive changing nothing or
changing everything, no compromises.

I happen to think there are tons of improvements to make to a Fedora
Server product that do not include forking the distribution, simply
creating tools and modifying parts of it to provide a better tool for
people looking for a server experience.
Namely:
- all the infrastructure to have a solid foundation for a server with,
- prepackaged roles to make it simple to install basic infra components
- excellent tools to install and maintain software stacks (both Fedora
provided and externally maintained)
- including prepackaged language stacks of various concurrent versions
- including improving containers for whole role isolation
- maybe sandboxes (but I see that more as a desktop tech)

This is what I think we need, and to do this we do not need to fork and
radically change everything in the distribution. The OS is an
infrastructure tool for others and benefits from having large amounts of
prepackaged software available (we have this now and makes no sense to
throw it away) as well as making dead easy to install your own stack
(and we lack exactly here where we should improve).

One of the main requirements to allow this is to define a stable
platform (in the APIs it uses/exposes, this is not much about how fast
it gets refreshed).

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York