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?
You can find my current MOF at [1], the class that troubles me is called LMI_SSSD_Backend, at the bottom of the file.
Thanks, Pavel.
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
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?
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.
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?
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.0-P...
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.
Jan
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?
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.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.
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
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.
Jan
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 04/02/2014 08:06 AM, 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.
Jan
There's a python API that modifies SSSD's config file. See attached output of the pydoc.
On 04/02/2014 02:06 PM, 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.
We are implementing side-by-side D-Bus API.
Jan
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 _______________________________________________ openlmi-devel mailing list openlmi-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/openlmi-devel
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.
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.
On 04/10/2014 03:15 PM, Pavel Březina wrote:
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.
Hi, latest version can be found at: http://bit.ly/1iQkNjE
It completely separates domains and processes. Domains and subdomains are both of class LMI_SSSDDomain. They are distinguished only by flag and topology given by LMI_SSSDDomainSubdomain association.
On 04/24/2014 02:39 PM, Pavel Březina wrote:
Hi, latest version can be found at: http://bit.ly/1iQkNjE
It completely separates domains and processes. Domains and subdomains are both of class LMI_SSSDDomain. They are distinguished only by flag and topology given by LMI_SSSDDomainSubdomain association.
The design looks just fine. Few minor nits:
[Description("Enable this component. SSSD has to be restarted in order " "this change to take any effect.")] uint32 Enable();
If a method returns uint32, it should describe what the integer means, like:
[Description("Permanently change debug level of this component."), ValueMap { "0", "1", "2" }, Values { "Success", "Failed", "Invalid arguments" }] uint32 SetDebugLevelPermanently([In] uint16 debug_level);
Define error codes as you find appropriate, the above is just suggestion.
[Description("The output format this domain uses.")] string OutputFormat;
I have no idea what 'output of a domain' could be, it sounds really strange to me. Anyway, I just hope that the name and its description makes some sense to average SSSD user/admin, my feelings are irrelevant here.
Do you need any other help with the provider? I think the mof file does not need any further review.
Jan
On 04/25/2014 12:21 PM, Jan Safranek wrote:
On 04/24/2014 02:39 PM, Pavel Březina wrote:
Hi, latest version can be found at: http://bit.ly/1iQkNjE
It completely separates domains and processes. Domains and subdomains are both of class LMI_SSSDDomain. They are distinguished only by flag and topology given by LMI_SSSDDomainSubdomain association.
The design looks just fine. Few minor nits:
[Description("Enable this component. SSSD has to be restarted in order " "this change to take any effect.")] uint32 Enable();If a method returns uint32, it should describe what the integer means, like:
[Description("Permanently change debug level of this component."), ValueMap { "0", "1", "2" }, Values { "Success", "Failed", "Invalid arguments" }] uint32 SetDebugLevelPermanently([In] uint16 debug_level);
Fixed.
Define error codes as you find appropriate, the above is just suggestion.
[Description("The output format this domain uses.")] string OutputFormat;I have no idea what 'output of a domain' could be, it sounds really strange to me. Anyway, I just hope that the name and its description makes some sense to average SSSD user/admin, my feelings are irrelevant here.
Its the how users from the domain are presented in the system. I.e. user@domain or DOMAIN\user, etc. It is expected to be known by admins.
Do you need any other help with the provider? I think the mof file does not need any further review.
Jan
Thank you for the review. I'll start working on the implementation. And send patches for review when ready.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 04/25/2014 08:31 AM, Pavel Březina wrote:
On 04/25/2014 12:21 PM, Jan Safranek wrote:
On 04/24/2014 02:39 PM, Pavel Březina wrote:
Hi, latest version can be found at: http://bit.ly/1iQkNjE
It completely separates domains and processes. Domains and subdomains are both of class LMI_SSSDDomain. They are distinguished only by flag and topology given by LMI_SSSDDomainSubdomain association.
The design looks just fine. Few minor nits:
[Description("Enable this component. SSSD has to be restarted in order " "this change to take any effect.")] uint32 Enable();
If a method returns uint32, it should describe what the integer means, like:
[Description("Permanently change debug level of this component."), ValueMap { "0", "1", "2" }, Values { "Success", "Failed", "Invalid arguments" }] uint32 SetDebugLevelPermanently([In] uint16 debug_level);
Fixed.
Define error codes as you find appropriate, the above is just suggestion.
[Description("The output format this domain uses.")] string OutputFormat;
I have no idea what 'output of a domain' could be, it sounds really strange to me. Anyway, I just hope that the name and its description makes some sense to average SSSD user/admin, my feelings are irrelevant here.
Its the how users from the domain are presented in the system. I.e. user@domain or DOMAIN\user, etc. It is expected to be known by admins.
I'd prefer FullyQualifiedNameFormat rather than OutputFormat. It wasn't clear to me either.
Do you need any other help with the provider? I think the mof file does not need any further review.
Jan
Thank you for the review. I'll start working on the implementation. And send patches for review when ready.
Great work!
On 04/25/2014 03:39 PM, Stephen Gallagher wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 04/25/2014 08:31 AM, Pavel Březina wrote:
On 04/25/2014 12:21 PM, Jan Safranek wrote:
On 04/24/2014 02:39 PM, Pavel Březina wrote:
Hi, latest version can be found at: http://bit.ly/1iQkNjE
It completely separates domains and processes. Domains and subdomains are both of class LMI_SSSDDomain. They are distinguished only by flag and topology given by LMI_SSSDDomainSubdomain association.
The design looks just fine. Few minor nits:
[Description("Enable this component. SSSD has to be restarted in order " "this change to take any effect.")] uint32 Enable();
If a method returns uint32, it should describe what the integer means, like:
[Description("Permanently change debug level of this component."), ValueMap { "0", "1", "2" }, Values { "Success", "Failed", "Invalid arguments" }] uint32 SetDebugLevelPermanently([In] uint16 debug_level);
Fixed.
Define error codes as you find appropriate, the above is just suggestion.
[Description("The output format this domain uses.")] string OutputFormat;
I have no idea what 'output of a domain' could be, it sounds really strange to me. Anyway, I just hope that the name and its description makes some sense to average SSSD user/admin, my feelings are irrelevant here.
Its the how users from the domain are presented in the system. I.e. user@domain or DOMAIN\user, etc. It is expected to be known by admins.
I'd prefer FullyQualifiedNameFormat rather than OutputFormat. It wasn't clear to me either.
OK. I took the name from the original design of D-Bus responder. I agree with you, I had to check to what option it is related myself but didn't want to change it. Ccing Jakub to get his opinion.
Do you need any other help with the provider? I think the mof file does not need any further review.
Jan
Thank you for the review. I'll start working on the implementation. And send patches for review when ready.
Great work!
On Fri, Apr 25, 2014 at 05:09:06PM +0200, Pavel Březina wrote:
On 04/25/2014 03:39 PM, Stephen Gallagher wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 04/25/2014 08:31 AM, Pavel Březina wrote:
On 04/25/2014 12:21 PM, Jan Safranek wrote:
On 04/24/2014 02:39 PM, Pavel Březina wrote:
Hi, latest version can be found at: http://bit.ly/1iQkNjE
It completely separates domains and processes. Domains and subdomains are both of class LMI_SSSDDomain. They are distinguished only by flag and topology given by LMI_SSSDDomainSubdomain association.
The design looks just fine. Few minor nits:
[Description("Enable this component. SSSD has to be restarted in order " "this change to take any effect.")] uint32 Enable();
If a method returns uint32, it should describe what the integer means, like:
[Description("Permanently change debug level of this component."), ValueMap { "0", "1", "2" }, Values { "Success", "Failed", "Invalid arguments" }] uint32 SetDebugLevelPermanently([In] uint16 debug_level);
Fixed.
Define error codes as you find appropriate, the above is just suggestion.
[Description("The output format this domain uses.")] string OutputFormat;
I have no idea what 'output of a domain' could be, it sounds really strange to me. Anyway, I just hope that the name and its description makes some sense to average SSSD user/admin, my feelings are irrelevant here.
Its the how users from the domain are presented in the system. I.e. user@domain or DOMAIN\user, etc. It is expected to be known by admins.
I'd prefer FullyQualifiedNameFormat rather than OutputFormat. It wasn't clear to me either.
OK. I took the name from the original design of D-Bus responder. I agree with you, I had to check to what option it is related myself but didn't want to change it. Ccing Jakub to get his opinion.
Sounds good to me, can you change the design page as well?
On 04/28/2014 10:03 AM, Jakub Hrozek wrote:
On Fri, Apr 25, 2014 at 05:09:06PM +0200, Pavel Březina wrote:
On 04/25/2014 03:39 PM, Stephen Gallagher wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 04/25/2014 08:31 AM, Pavel Březina wrote:
On 04/25/2014 12:21 PM, Jan Safranek wrote:
On 04/24/2014 02:39 PM, Pavel Březina wrote:
Hi, latest version can be found at: http://bit.ly/1iQkNjE
It completely separates domains and processes. Domains and subdomains are both of class LMI_SSSDDomain. They are distinguished only by flag and topology given by LMI_SSSDDomainSubdomain association.
The design looks just fine. Few minor nits:
[Description("Enable this component. SSSD has to be restarted in order " "this change to take any effect.")] uint32 Enable();
If a method returns uint32, it should describe what the integer means, like:
[Description("Permanently change debug level of this component."), ValueMap { "0", "1", "2" }, Values { "Success", "Failed", "Invalid arguments" }] uint32 SetDebugLevelPermanently([In] uint16 debug_level);
Fixed.
Define error codes as you find appropriate, the above is just suggestion.
[Description("The output format this domain uses.")] string OutputFormat;
I have no idea what 'output of a domain' could be, it sounds really strange to me. Anyway, I just hope that the name and its description makes some sense to average SSSD user/admin, my feelings are irrelevant here.
Its the how users from the domain are presented in the system. I.e. user@domain or DOMAIN\user, etc. It is expected to be known by admins.
I'd prefer FullyQualifiedNameFormat rather than OutputFormat. It wasn't clear to me either.
OK. I took the name from the original design of D-Bus responder. I agree with you, I had to check to what option it is related myself but didn't want to change it. Ccing Jakub to get his opinion.
Sounds good to me, can you change the design page as well?
OK. Renamed.
- [Description("The output format this domain uses.")] - string OutputFormat; + [Description("Format of fully qualified name this domain uses.")] + string FullyQualifiedNameFormat;
openlmi-devel@lists.fedorahosted.org
-
Jakub Hrozek -
Jan Safranek -
Pavel Březina -
Russell Doty -
Stephen Gallagher