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://dmtf.org/sites/default/files/cim/cim_schema_v2400/cim_schema_2.40.0-P...
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.