Is the Fedora Server one product?

[Miloslav Trmač]

On Fri, Nov 1, 2013 at 11:08 AM, "Jóhann B. Guðmundsson"
<johannbg at gmail.com> wrote:
> "Fedora Server WG where we discover product solutions that work well for our
> users, our administrators, our developers and our project."
> --> T-shirt anyone <-- ;)
>
> We should be identifying which server applications work well on their own or
> work well with each other out of those 500+ we have ( think of them as
> ingredients ).
>
> Once we have done that we add a Fedora secret sauce ( what we feel they are
> lacking for the 21 century which for example could be that missing
> configuration api ) and form a PRD for that recipe and implement it.

I agree with the focus on "product solutions" and the end-user-visible goal.


>From an implementation point of view, I don't think creating many
individual "recipes" is optimal.

If you look at user's interaction, and correspondingly
implementation/packaging/integration complexity, for a server-provided
service (e.g. a daemon), and at the underlying "infrastructure" (for
lack of better word), it basically goes like this:
- The service: set up access rights 1-5 primary parameters (mail
server: place to store mail; DB server: place to store the database,
access rights; ...)
- The underlying server "infrastructure": set up
  - Networking (several parameters per interface, perhaps bonding/vLANs / ...
  - Storage (arbitrarily complex stack)
  - Identity database
  - Setting up updates
...

(Obviously the situation is actually more complex than "1-5 primary
parameters" for the service, there may be dozens or hundreds of
tunables, but the same is true for the underlying server
infrastructure components, so the relationship holds.)

So, it doesn't make much sense to me to make individual recipes
starting with the application, and potentially diverging in the
"infrastructure"; rather, the "infrastructure" should be common and
the base of the product, with the various services being treated more
like "applications" for the infrastructure (potentially some "bundled"
and some separate).  That doesn't mean that the
services/"applications" are less important, but it does mean that the
"infrastructure" is the same for all of them (which may require
adjusting both the "applications" and the "infrastructure").
     Mirek