On 03/31/2014 01:18 PM, Jan Safranek wrote:
On 03/31/2014 12:45 PM, Pavel Březina wrote:
> 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
>
It's getting better. In CIM, everything what's not an association should
be a subclass of CIM_ManagedElement (or even better, find more concrete
subclass, e.g. CIM_LogicalElement).
You may consider subclassing CIM_EnabledLogicalElement for
LMI_SSSDProcess as it provides enabled/disabled/change state functionality.
It depends how CIM-ish (=ugly) you want to be. There is whole heap of
predefined classes, which may resemble something you are designing.
Remember, you do not need to implement all properties/methods from the
CIM classes, just those you find usable. It's hard to find appropriate
CIM class to subclass, following links may be useful:
http://schemas.dmtf.org/wbem/cim-html/2.40.0+/
http://dmtf.org/sites/default/files/cim/cim_schema_v2400/cim_schema_2.40....
I must say I'm having moral issues inheriting from a class where I won't
implement most of its part. Is it really a common practice? I have
chosen to stay with CIM_ManagedElement for this version.
I renamed LMI_SSSDProcess to LMI_SSSDComponent, I think it better says
what it is really about. Even though it is currently implemented as a
separate process, it is not the important thing about it.
I also discarded LMI_SSSDBackend class and use LMI_SSSDDomain instead,
since that is more common terminology for our users. Each domain can
have associated one or more subdomains
New version:
http://bit.ly/1gNAeIP
> 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
> }
Assuming 'class LMI_SSSDIPADomain:LMI_SSSDDomain {}', then yes, it's
perfectly valid and widely used. Not only in CIM associations, but also
in method calls and similar cases, just like in C++ / Java.
Thanks, I will use it in some future version.
Jan