Database Server Role Design Considerations

[Simo Sorce]

On Fri, 12 Dec 2014 19:41:52 +0100
Stef Walter <stefw at redhat.com> wrote:

> On 12.12.2014 18:52, Simo Sorce wrote:
> > On Thu, 11 Dec 2014 12:45:02 -0500
> > Stephen Gallagher <sgallagh at redhat.com> wrote:
> >> Unlike the Domain Controller role, the Database Server role will
> >> almost certainly need to support multiple instances. There are a
> >> couple ways that we can do this, both with their own pluses and
> >> minuses.
> > 
> > Why do we need to support multiple instances ?
> > 
> >> 1) Similar to the Domain Controller role, we can install the
> >> postgres packages on the local machine and then have each role
> >> instance create and manage a specific database within the server.
> >> This would be the easiest to implement, although I'm not sure what
> >> the start/stop semantics would have to be for the role instances,
> >> since we almost certainly don't want to stop all databases at the
> >> same time.
> > 
> > Are you thinking about multiple separate postgres installations
> > within the same machine each listening on a different port?
> > 
> > Or just the ability to create new databases within the single
> > postgres instance ?
> 
> With postgres this is not so super necessary, since it supports
> multiple databases, namespaces, users etc. It is mostly possible to
> "virtual host" postgres the way you would Apache.
> 
> But with other databases like MongoDB it starts to become a clearer
> need. Multiple instances store distinct sets of data.
> 
> >> 2) We could instead use Docker to create discrete postgres
> >> containers for each database we wanted to create. The advantages
> >> here would be better isolation and service control as well as
> >> protection against unwanted version upgrades. Containerized
> >> databases might be easier to move between machines as well. The
> >> primary disadvantages would be that the containers wouldn't be
> >> able to share a single port on the system, upgrades for security
> >> and bugfixes might be harder and that Docker is only currently
> >> supported on x86_64.
> > 
> > Docker is cool, but I do not think we should wander in that
> > direction with server roles.
> 
> I think that containers (or pods of containers) would be a great fit
> for server roles. A really great fit in fact. It's a shame we're not
> doing that already. I sorta assumed it had something to do with
> immaturity of the container solutions, with regard to updates etc.
> Note that these containers don't have to be Docker specific ...

Well I do not want to re-invent something like mesos or kubernetes in
rolekit. And this space is pretty immature still, there is no winner
and even Docker is somewhat under threat of not being the final word on
containers since Rocket and LXC and other things are still bubbling up
every other day.

I wouldn't want to spend 6 months building something to find out at the
end of the cycle that we have to start from scratch because we failed
to pick the winner (and no upgrade path will then be possible so you
compound failure there).

Maybe I am a bit conservative, but the server space tend to be that way
and using mature components for our underlying infrastructure is the
only way we can think of slowing down Fedora Server release cycle (if
we still are thinking of doing that at some point) and maintain it for
longer.

However I may have misunderstood our aim or maybe we need to re-discuss
some of the goals of Fedora Server and get all back on the same page.

Simo.

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