Database Server Role Design Considerations

Stephen Gallagher sgallagh at
Fri Dec 12 16:45:47 UTC 2014

On Fri, 2014-12-12 at 12:03 +0100, Pavel Raiskup wrote:
> On Thursday 11 of December 2014 20:52:43 Siem Korteweg wrote:
> > Stephen Gallagher schreef op 11-12-2014 18:45:
> > > 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.
> >
> > 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.
> Not a Server SIG member, but FWIW - I don't think I would love Cockpit
> making such decisions for me (on the box db/docker/VM/remote db).  IMO,
> either we should allow user to decide which approach is going to be used
> (and potentially support all scenarios), or support only the basic
> configuration on the bare metalĀ¹.

I think you misunderstand. Nothing prevents you from just installing
packages and making all the choices yourself. What we're discussing here
is the rolekit/Cockpit "Server Role" implementation. The idea here is
that we (the Server SIG) will come up with what we feel is a
"best-practice" implementation and make it easy (ideally trivial) to set
up that way.

In short, whichever way we pick to do it, it will be possible for users
to simply decide not to use our tool and do whatever they please, as
they have always done.

(BTW, the Server SIG is open to all and all voices are listened to).

-------------- 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