SSSD CIM schema

Pavel Březina pbrezina at redhat.com
Thu Apr 10 13:15:56 UTC 2014


On 04/03/2014 11:14 AM, Pavel Březina wrote:
> On 04/02/2014 03:35 PM, Russell Doty wrote:
>> On Wed, 2014-04-02 at 14:06 +0200, Jan Safranek wrote:
>>> 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.
>>
>> Building on what Jan said, for OpenLMI you should think of the CIM
>> models as guidelines and references, not hard requirements. You will
>> need to tie in to the CIM model at some point in order to cleanly
>> integrate into the standard OpenLMI namespace, but are not required to
>> implement the CIM models.
>>
>> In general we try to follow the CIM models - there is a huge amount of
>> institutional knowledge in those models that we benefit from. We want to
>> take what is useful from CIM and also build something that works.
>>
>> Yes, there is a bit of "dynamic tension" here, in that there are
>> different ways to do things. Discussing what you are thinking about on
>> this list is a good idea.
>>
>> The approach you are currently taking, trying to fit with the CIM model,
>> is usually a good start. If it makes sense, following the CIM model
>> somewhat closely helps integrate with the rest of OpenLMI. But it isn't
>> something you absolutely have to do if it doesn't make sense.
>>>
>>> Jan
>
> Hi,
> thank you all for comments. Latest version: http://bit.ly/Po4lf3
> I added a subclass for CIM_HostedService.
>
> I would like to make this model final for the first release of this
> provider, if you don't have any objections.
>
> We are currently discussing whether to make it part of SSSD upstream or
> a part of OpenLMI upstream, Stephen put it on tomorrows agenda.
> Nevertheless I would like to get your ack for this model in either case.

Hi,
latest version of the schema: http://bit.ly/1iAgoi0

Is there anything else I should change?
To move on, I started implementing the providers with dummy data.

Thanks,
Pavel.




More information about the openlmi-devel mailing list