Multiple 'role' instances?

[Stef Walter]

So this may be way out there ... I'm looking ahead to how Cockpit would
implement roles, and combine them with other concepts such as
containerized server applications...

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.

For example MongoDB has one database. If you want more than one, you run
more than one MongoDB on more than one port. These run as seperate
systemd instances etc...

Another example is PostgresQL. Although it supports multiple databases,
it only supports one authentication scheme. If you want distinct
authentication domains in postgres, you run it more than once.

A general example is containerized services. If at some point we do
implement a role using containers, having multiple containers filling
the same "role" (eg: EAP node) is common.

Anyway, I'm not saying that this is a *must have* aspect of rolekit. I
wanted to raise the issue. It's certainly something we have to consider
at the Cockpit level.

Cheers,

Stef

[Miloslav Trmač]

----- 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).

Exposing multiple instances within a role does have limitations (what is the state of a
role in which 90 instances run successfully and 1 has crashed?), but it seems to me that
users running into these instances would usually be those running a very large number of
instances (e.g. hosting them for customers as a business), i.e. specialist cases which are
not the primary taret of Fedora Server.
    Mirek

[Stef Walter]

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.

>  Exposing multiple instances within a role does have limitations
> (what
>  is the state of a role in which 90 instances run successfully and 1
>  has crashed?), but it seems to me that users running into these
>  instances would usually be those running a very large number of
>  instances (e.g. hosting them for customers as a business), i.e.
>  specialist cases which are not the primary taret of Fedora Server.  
This is exactly the use case that we're coming up against in Cockpit.
And it's not at all a specialist case. Let me explain:

In Cockpit we're talking about reworking our navigation and workflows so
they center around the services that the server is providing. These take
the form of Roles (in Fedora Server), Server Applications (by others) or
Containerized Services (by the docker crowd), but the essence is the
same. These are the things the server has been deployed to "do".

I'm going to use the term "service" here for lack of a better all
encompassing term. When I talk about these below, I'm not talking about
all the systemd internal services ... but services that the server
provides, and the raison d'etre for the server.

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?

We aim to show clear status on the above questions and more in the
Cockpit UI centered around the various services being provided, and
where possible, each *instance* of those services.

Now I understand that not all services can (due to software limitations)
or should (due to sanity, ie: IPA) be deployed with multiple instances
... but many are capable of this, and will be deployed that way.

So rolekit would be limiting itself if it doesn't support multiple
instances, and Cockpit would need to try to find a way around rolekit in
cases where the underlying role implementation really is running
multiple services.

Cheers,

Stef

[Miloslav Trmač]

----- 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

[Stephen Gallagher]

-----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.
>  
>  4) 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.

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlO1aoIACgkQeiVVYja6o6PDOwCfYPFIxzjw+G77t4mPf6roTnsg
> dSMAn1jopGI3/ZEwqZ01BTMn7uVoeDiU
> =6ymB
> -----END PGP SIGNATURE-----

[Stef Walter]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03.07.2014 16:36, Stephen Gallagher wrote:
>  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.
>  
> > 4) 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. 
Sounds great. Yes, I'm totally fine with an implementation restricted
to one instance per role for now.

/me wonders how we'll verify that the API doesn't have problems
preventing it from working for multiple instances later ... but I
guess the API isn't set in stone.

Stef
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlO1cacACgkQe/sRCNknZa9AQACfVRYo0f+A/mqLpHM6Rj8Ez4Tq
> Xd0An26b3b7Dryq5i/Or8aKbDHjzVCOh
> =WRv+
> -----END PGP SIGNATURE-----