Database Server Role Design Considerations

Simo Sorce simo at
Fri Dec 12 17:52:16 UTC 2014

On Thu, 11 Dec 2014 12:45:02 -0500
Stephen Gallagher <sgallagh at> wrote:

> On Tue, 2014-12-09 at 09:50 -0500, Stephen Gallagher wrote:
> > I'm looking into designing the plan for the Database Server Role
> > (which the Fedora Server WG previously agreed would be based on
> > PostgreSQL).
> > 
> > One of the things we didn't really discuss in the PRD was whether we
> > would have a *requirement* for the Roles to have a GUI/WebUI
> > management console for configuring their services.
> > 
> > With the use of Cockpit for our top-level system GUI, I think it
> > makes sense that we would want to be able to have a link within
> > Cockpit's UI that takes us to the Role-specific web-based
> > configuration tool. For the Domain Controller, this link is
> > obvious: it should go to the FreeIPA Web UI.
> > 
> > For the Database Server, it's less clear-cut. PostgreSQL upstream
> > does not provide a "blessed" GUI/WebUI configuration tool for
> > managing it. Many exist and are provided by the project's very
> > vibrant community. I think we need to select one of these and
> > consider making it a core part of the Database Server role.
> > 
> > A (probably incomplete) list of potential tools are provided at
> >
> > 
> > I'd like to recommend that for now we stick with one of the ones
> > that is already included in Fedora and are available via a web
> > browser (not requiring a desktop environment/X server). From a
> > quick search, that probably brings the list down to phpPgAdmin.
> > 
> > Does anyone on this list know of an alternative web-based tool that
> > they strongly prefer and would like to see us use (and possibly
> > package, if it's not already in Fedora)? I'd like to nail this down
> > fairly soon.
> > 
> > My goal is to finish the design for the Database Server Role before
> > the holidays and spend January implementing it.
> So, I was thinking about this some more this morning, and there's
> another key place we need to start thinking about.
> 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 ?

> 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'd love to hear from the wider Server SIG what their thoughts are on
> this, especially if I missed some obvious advantages or disadvantages.
> I'm also CCing the DB folks at Red Hat for their input. Please reply
> to the server at list only.

Simo Sorce * Red Hat, Inc * New York

More information about the server mailing list