Database Server Role Design Considerations

Stephen Gallagher sgallagh at
Thu Dec 11 17:45:02 UTC 2014

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.

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.

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.

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <>

More information about the server mailing list