Database Server Role Design Considerations
stefw at redhat.com
Fri Dec 12 11:10:00 UTC 2014
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 181 bytes
Desc: OpenPGP digital signature
More information about the server