Fedora server implementation straw man

[Simo Sorce]

On Fri, 2014-02-21 at 11:43 -0500, Stephen Gallagher wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 02/21/2014 11:29 AM, Simo Sorce wrote:
> > On Thu, 2014-02-13 at 09:39 -0700, Kevin Fenzi wrote:
> >> On Tue, 11 Feb 2014 18:29:37 +0000 Colin Walters
> >> <walters at verbum.org> wrote:
> >> 
> >>> Hi,
> >>> 
> >>> What about discussing implementation after we choose a few
> >>> roles?
> >>> 
> >>> I think FreeIPA has been mentioned before - it would make a
> >>> good first featured role, and I think it's also probably
> >>> something to which one would reasonably dedicate a machine.
> >>> (As opposed to e.g. putting it in a Docker)
> >> 
> >> Well, we already decided our first role would be a freeipa
> >> server. ;)
> >> 
> >> I don't know how far we want to go on the first cut, but it might
> >> be worth picking 1 or 2 more so we can also look at how roles
> >> interact.
> > 
> > What would be the next thing you instal once you have a netowrk
> > and identity infrastructure?
> > 
> > To be honest I'd refrain from "fileserver" now because I know how 
> > complicated storage becomes very quickly, so before we tackle such
> > a role I think we need to work on a few easier ones that do not
> > have the huge variability a "file server" may have.
> > 
> 
> So let's take a look at what people use Fedora (or RHEL) servers for
> today.
> 
> The server platform is there so that people can deploy their own apps
> on it. So for us to have value, our Roles should be providing tools
> that make these apps simpler. So let's look at commonalities.
> 
> Most apps these days need to talk to a database of some sort (be it
> traditional like MariaDB or PostgreSQL or the new stuff like MongoDB).
> A lot of web applications these days will also use a centralized
> memcached host to accelerate their responses.
> 
> Naturally, there's also the plain old 'webserver', but that's probably
> in a similar level of complexity to "fileserver", so we may want to
> hold off on that for now.
> 
> I'd suggest that the second Role we might want to offer would be a
> standard Database role. We can pick either MariaDB or PostgreSQL (by
> majority vote) and run with it. (That's not to say we couldn't offer
> both eventually, but let's not split our attention initially).
> 
> This should be relatively straightforward since setting up the
> databases really requires only configuring authentication and starting
> up the service. We can do a little integration work to ensure that the
> auth works reasonably well with our identity management system and
> then work on a configuration API to simplify creating new databases
> and permissions on them. Probably not an insurmountable amount of work.
> 
> Thoughts?

I was thinking on similar lines, though I am not a DBA and my experience
with databases is limited, just enough to hate one (multiple data
losses) and be comfortable with the other (just works :)

Do we have anyone on this list that have reasonable experience with
setting up SQL databases ?

Any reason why we should, instead, choose something else ?

Simo.

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