Re: Multiple 'role' instances?
----- 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.
4) and 5) would need some work and time to design it seems.
Mirek