Database Server Role Design Considerations

[Stef Walter]

On 12.12.2014 12:03, 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 lists.fedoraproject.org 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 certainly agree. Cockpit has a fundamental goal not to lock you hold
your machine hostage ... and to function well with other ways to
accomplish the same task.

> IOW, I don't think that I would use Cockpit to start database in VM
> _by default_, or as the only option.  Yes, I would start VM with Cockpit,
> why not.  I would also configure DBMS in the VM via (its own possibly?)
> Cockpit.  BTW, is there something like "recursive" feature¹ for Cockpit?
> I mean that we could handle VM's Cockpit from bare-metal's Cockpit?

This is possible today, but not as streamlined as it should be. In the
latest development versions this is getting a lot better.

Basically you manage the other machines via the first Cockpit instance,
and that connects to a small cockpit-bridge running in the other VMs.

Stef

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <http://lists.fedoraproject.org/pipermail/server/attachments/20141212/463932f9/attachment.sig>