SSSD CIM schema

[Pavel Březina]

On 03/28/2014 03:54 PM, Jan Safranek wrote:
> On 03/28/2014 01:43 PM, Pavel Březina wrote:
> > Hi,
> > I would like to create a class that has array of references as a
> > property. However, konkretcmpi will not parse it. What is the correct
> > way please?
>
> Looking at the mof file, I must say things work little differently in CIM.
>
> There is usually a singleton, representing a 'feature' like SSSD. It's
> usually called <something>Service, for SSSD I can propose:
>
> class SSSD_Service : CIM_Service
> {
> <any global methods, if needed>
> }
>
> [or you can keep LMI_SSSD_ prefix, it just distinguishes who is the
> owner of the API - SSSD project or LMI project]
>
> Don't be scared by number of properties in CIM_Service, the class (and
> its singleton instance) should just provide high-level status if SSSD
> is  enabled or not and if it is fine or something is broken. You don't
> need to implement all the properties and methods.
>
> [Also, CIM_Service is not necessarily related to any systemd
> service/daemon/whatever, it's just where the SSSD CIM API starts]
>
> To this SSSDService object you then associate other objects, which
> describe SSSD configuration and state in detail. In CIM, we don't use
> GetServices() and GetBackends() methods, we use association classes like:
>
> [Association]
> class LMI_SSSDRunningProcess
> {
>    LMI_SSSDService REF SSSD;
>    LMI_SSSDProcess REF Process;
> }
>
> [Association]
> class LMI_SSSDAvailableDomain
> {
>    LMI_SSSDService REF SSSD;
>    LMI_SSSDDomain REF Domain;
> }
>
> CIM is designed to traverse such associations, so one can ask 'what
> SSSDProcesses are associated to this SSSDService' and get list of all of
> them. Or 'what SSSDBackends are associated to a SSSDService' and get
> just the backends.
>
> [In theory, one might also ask 'to what SSSDService this Backend
> belongs, but it is not very useful as there is just one SSSDService]
>
> Since Backends, Monitors and Services are subclasses of SSSDProcess,
> just one SSSDRunningProcess association is enough to cover all of them.
> Of course, you may create individual association classes for each
> SSSDProcess subclass, if you find it useful in your design.
>
> I hope I did not scare you too much, CIM is quite complicated, don't be
> afraid to ask. We're also on #openlmi at Freenode.
>
> Jan

Hi,
thank you for your answer. How about this schema? Am I getting closer?

http://bit.ly/1jqETRs

I'm trying to model the following relationships:

SSSD has one main process called monitor. It spawns multiple backends 
(also called data providers) and responders (sometimes called services). 
Each backend is associated with one domain from configuration file and 
zero or more discovered subdomains (they are not necessarily subdomains 
from topological view).

The relationship looks like:
                 SSSD (monitor)
                  /        \
           responders     backends
                             |
                          domains

Each part has some generic configuration and also specific configuration 
appropriate for given responder (NSS, PAM)/provider (LDAP, AD).

Is it possible to create an association with reference to a superclass 
but providing an instance of derived class? Something like:

[Association]
class LMI_SSSDAvailableDomain
{
     LMI_SSSDBackend REF Backend;
     LMI_SSSDDomain REF Domain; // points to instance of LMI_SSSDIPADomain
}

Stephen, can you review it from SSSD side please?

Thanks,
Pavel.