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 https://wiki.postgresql.org/wiki/Community_Guide_to_PostgreSQL_GUI_Tools
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.
On Tue, 09 Dec 2014 09:50:06 -0500 Stephen Gallagher sgallagh@redhat.com 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.
To be honest, while a Graphical UI of sorts would be nice I think we shouldn't have a requirement to have a WebUI/GUI to actually manage the role. We can allow to optionally install one maybe, but not require one, for one it would basically disqualify some roles because the great underlying software has no viable graphical UI, and it would also annoy admins that do not care for a webUI (unless it is part of the software on its own) and wants to maintain a small footprint.
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 https://wiki.postgresql.org/wiki/Community_Guide_to_PostgreSQL_GUI_Tools
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.
I would not like to have phpPgAdmin "forced down my throat" to be honest. Mostly because of the php dependency which I try to remove on my servers on abysmal security grounds, but also because I do not think I would use a webui on the same DB server.
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.
I think we need to first discuss if a webui is actually a requirement for roles.
My goal is to finish the design for the Database Server Role before the holidays and spend January implementing it.
Yep, no much time before F22 code completion.
Simo.
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 https://wiki.postgresql.org/wiki/Community_Guide_to_PostgreSQL_GUI_Tools
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@lists.fedoraproject.org list only.
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 https://wiki.postgresql.org/wiki/Community_Guide_to_PostgreSQL_GUI_Tools
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.
- 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.
- 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@lists.fedoraproject.org list only. _______________________________________________ server mailing list server@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/server
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
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@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¹.
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?
Pavel
¹ Well, I must still make a look at Cockpit a bit more.
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@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
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@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 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).
On Thu, 11 Dec 2014 12:45:02 -0500 Stephen Gallagher sgallagh@redhat.com wrote:
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 https://wiki.postgresql.org/wiki/Community_Guide_to_PostgreSQL_GUI_Tools
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.
Why do we need to support multiple instances ?
- 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.
Are you thinking about multiple separate postgres installations within the same machine each listening on a different port?
Or just the ability to create new databases within the single postgres instance ?
- 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.
Docker is cool, but I do not think we should wander in that direction with server roles.
HTH, Simo.
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@lists.fedoraproject.org list only.
On 12.12.2014 18:52, Simo Sorce wrote:
On Thu, 11 Dec 2014 12:45:02 -0500 Stephen Gallagher sgallagh@redhat.com wrote:
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.
Why do we need to support multiple instances ?
- 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.
Are you thinking about multiple separate postgres installations within the same machine each listening on a different port?
Or just the ability to create new databases within the single postgres instance ?
With postgres this is not so super necessary, since it supports multiple databases, namespaces, users etc. It is mostly possible to "virtual host" postgres the way you would Apache.
But with other databases like MongoDB it starts to become a clearer need. Multiple instances store distinct sets of data.
- 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.
Docker is cool, but I do not think we should wander in that direction with server roles.
I think that containers (or pods of containers) would be a great fit for server roles. A really great fit in fact. It's a shame we're not doing that already. I sorta assumed it had something to do with immaturity of the container solutions, with regard to updates etc. Note that these containers don't have to be Docker specific ...
Stef
On Fri, 12 Dec 2014 19:41:52 +0100 Stef Walter stefw@redhat.com wrote:
On 12.12.2014 18:52, Simo Sorce wrote:
On Thu, 11 Dec 2014 12:45:02 -0500 Stephen Gallagher sgallagh@redhat.com wrote:
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.
Why do we need to support multiple instances ?
- 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.
Are you thinking about multiple separate postgres installations within the same machine each listening on a different port?
Or just the ability to create new databases within the single postgres instance ?
With postgres this is not so super necessary, since it supports multiple databases, namespaces, users etc. It is mostly possible to "virtual host" postgres the way you would Apache.
But with other databases like MongoDB it starts to become a clearer need. Multiple instances store distinct sets of data.
- 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.
Docker is cool, but I do not think we should wander in that direction with server roles.
I think that containers (or pods of containers) would be a great fit for server roles. A really great fit in fact. It's a shame we're not doing that already. I sorta assumed it had something to do with immaturity of the container solutions, with regard to updates etc. Note that these containers don't have to be Docker specific ...
Well I do not want to re-invent something like mesos or kubernetes in rolekit. And this space is pretty immature still, there is no winner and even Docker is somewhat under threat of not being the final word on containers since Rocket and LXC and other things are still bubbling up every other day.
I wouldn't want to spend 6 months building something to find out at the end of the cycle that we have to start from scratch because we failed to pick the winner (and no upgrade path will then be possible so you compound failure there).
Maybe I am a bit conservative, but the server space tend to be that way and using mature components for our underlying infrastructure is the only way we can think of slowing down Fedora Server release cycle (if we still are thinking of doing that at some point) and maintain it for longer.
However I may have misunderstood our aim or maybe we need to re-discuss some of the goals of Fedora Server and get all back on the same page.
Simo.
On Fri, 2014-12-12 at 14:42 -0500, Simo Sorce wrote:
On Fri, 12 Dec 2014 19:41:52 +0100 Stef Walter stefw@redhat.com wrote:
On 12.12.2014 18:52, Simo Sorce wrote:
On Thu, 11 Dec 2014 12:45:02 -0500 Stephen Gallagher sgallagh@redhat.com wrote:
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.
Why do we need to support multiple instances ?
- 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.
Are you thinking about multiple separate postgres installations within the same machine each listening on a different port?
Or just the ability to create new databases within the single postgres instance ?
With postgres this is not so super necessary, since it supports multiple databases, namespaces, users etc. It is mostly possible to "virtual host" postgres the way you would Apache.
But with other databases like MongoDB it starts to become a clearer need. Multiple instances store distinct sets of data.
- 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.
Docker is cool, but I do not think we should wander in that direction with server roles.
I think that containers (or pods of containers) would be a great fit for server roles. A really great fit in fact. It's a shame we're not doing that already. I sorta assumed it had something to do with immaturity of the container solutions, with regard to updates etc. Note that these containers don't have to be Docker specific ...
Well I do not want to re-invent something like mesos or kubernetes in rolekit. And this space is pretty immature still, there is no winner and even Docker is somewhat under threat of not being the final word on containers since Rocket and LXC and other things are still bubbling up every other day.
I wouldn't want to spend 6 months building something to find out at the end of the cycle that we have to start from scratch because we failed to pick the winner (and no upgrade path will then be possible so you compound failure there).
Maybe I am a bit conservative, but the server space tend to be that way and using mature components for our underlying infrastructure is the only way we can think of slowing down Fedora Server release cycle (if we still are thinking of doing that at some point) and maintain it for longer.
However I may have misunderstood our aim or maybe we need to re-discuss some of the goals of Fedora Server and get all back on the same page.
Simo.
Sounds like it is time to do some prototyping. As noted, it isn't clear which container technology will be the long term winner. Or where the holes in the current container implementations are, especially around application lifecycle.
I'd like to see a comparison between traditional approaches and containers for performing a set of database tasks: installation, update, backup/restore, using the database from applications, performing DB maintenance, configuring replication, etc.
server@lists.fedoraproject.org
-
Pavel Raiskup -
Russell Doty -
Siem Korteweg -
Simo Sorce -
Stef Walter -
Stephen Gallagher