-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 07/03/2014 09:23 AM, Miloslav Trmač wrote:
----- Original Message -----
On 02.07.2014 15:06, Miloslav Trmač wrote:
----- Original Message -----
Is there (will there be) any concept in rolekit of mulitple instances of a role on a server?
I know that this certainly doesn't apply to some services like IPA Domain Controller.
But for others, such as databases it may be a limitation later on.
I don’t think we need it; roles always can support multiple server instances within a single role, and I guess this would be the right thing to do for non-specialist admins (in particular this gives the _role implementation_ the option to choose for the user whether to implement multiple instances as multiple configurations within a process, multiple processes within a data store, or completely separate data and configuration instances).
Fair enough, that's Fedora's call to make. Cockpit will want to go well beyond this, however.
Oh, that would be rather unfortunate; Cockpit and Fedora Server are targeting roughly the same audience so we should end up with similar decisions. I just might be wrong about this :)
When someone runs more than one instance of a Service (think MongoDB database, or JBoss EAP instance), they would ideally like to know how each individual instance is doing:
- What is the load (cpu, io, memory) of this service? * Is the
data storage for that service running out of disk space? * What critical events have occurred? * Does this need software security updates? * Diagnosis like: is this service accessible from the network, or blocked by the firewall?
All good points, even for “instances” that would be best implemented as configurations within a single process even. (The security updates are typically applicable to all instances equally.)
I’m not sure how easy it would be to expose this in rolekit, and whether we can get it done for F21, though. I suppose 1) Differentiate between “role type” and “role instance” (conceptual, no code needed directly) 2) Give user-manageable names to role instances (defaulting to the “role type” name perhaps with a numerical suffix) 3) Allow listing types and instances separately 4) Separate the type-specific API (e.g. deploy, query firewall services) and the instance-specific API (e.g. start, undeploy) 5) Deal with multiple instances of referenced items (systemd units, firewalld services) $somehow.
- and 5) would need some work and time to design it seems. Mirek
Thomas, Mirek and I discussed this on #fedora-server for a while this morning.
The general agreement is that, yes, we do need the API to support multiple instances of Roles, but in F21 we will restrict them to one instance.
We're going to rework the API model slightly so that there will be a Role Factory object from which we can instantiate from role types. These role types will be allowed to prevent multiple-instantiation and a calling application *must* honor this.
A full design will be forthcoming next week.