Database Server Role Design Considerations

Siem Korteweg siem.korteweg at
Thu Dec 11 19:52:43 UTC 2014

Stephen Gallagher schreef op 11-12-2014 18:45:
> 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.
> _______________________________________________
> server mailing list
> server at
Why support multiple instances per Database Server? The Database Server 
will most likely be a virtual machine. Let each VM run a single instance 
and it will reduce complexity.

Siem Korteweg

More information about the server mailing list