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(a)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