SSSD CIM schema

Jan Safranek jsafrane at redhat.com
Wed Apr 2 12:06:45 UTC 2014


On 04/02/2014 12:13 PM, Pavel Březina wrote:> On 03/31/2014 01:18 PM,
Jan Safranek wrote:
>> 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.0-PDFs.zip
>>
>
> 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.

Welcome to CIM world of utterly complex classes :). It's common practice
to implement only 'Required' properties. And there are very little of
them. Anyway, CIM_ManagedElement will do just fine.

Out of curiosity, does SSSD already have a configuration API, e.g. on
DBus or as a library? Then I would suggest to throw away all DMTF
complexity and rewrite the API 1:1 to CIM - you have only one API to
document, available through two different access protocols, DBus/library
for local and CIM for remote configuration.

Jan


More information about the openlmi-devel mailing list