RFC: Profile Registration in OpenLMI - generically

Chris Buccella buccella at linux.vnet.ibm.com
Wed Jul 10 15:56:29 UTC 2013


Hi MIchal,

 > use a CIM_RegisteredProfile directly - no subclass with versioning 
info we need

You can create the subclass just above it, like this:

   class LMI_RegisteredProfile : CIM_RegisteredProfile
    {
     /* whatever */
    };

   instance of LMI_RegisteredProfile
    {
     InstanceID = "CIM:RH_Fan";
     RegisteredOrganization = 2;
     RegisteredName = "Fan";
     RegisteredVersion = "1.0.0";
     AdvertiseTypes = 3;
    };


 > Please correct me, if I'm wrong. I've only tried to create class 
LMI_RegisteredProfile without any provider under
 > Pegasus. And then tried to create static instances, which failed with 
CIM_ERR_NOT_SUPPORTED.

I'm not very knowledgeable about Pegasus, but this seems strange. If the 
mof compiler allowed you to compile the static instance, it should be in 
the repository, and I would expect that you could retrieve it with an 
EnumerateInstances call for CIM_RegisteredProfile. If it did not 
successfully compile, I would expect the error to be CIM_ERR_NOT_FOUND.


-Chris
SBLIM Team

On 07/10/2013 01:34 AM, Michal Minář wrote:
> Thank you Chris for the tip.
>
> But if I'm not mistaken, this would force us to either:
>
>   * use a CIM_RegisteredProfile directly - no subclass with versioning
>     info we need
>   * make a LMI_RegisteredProfile with corresponding provider, with
>     some persistent storage for storing installed static instances
>       o which could again be a json file, but this time it would be
>         more complicated (provider would have to know, how to write
>         these files)
>
> Please correct me, if I'm wrong. I've only tried to create class 
> LMI_RegisteredProfile without any provider under Pegasus. And then 
> tried to create static instances, which
> failed with CIM_ERR_NOT_SUPPORTED. That's why we need to have a 
> provider to instrument it. Static instances would be very nice though.
>
> Michal
>
> On 9.7.2013 20:04, Chris Buccella wrote:
>> You might also consider using static instances for 
>> RegisteredProfiles. This means that the instance is defined in MOF, 
>> then compiled directly into the repository.
>>
>> For example, you could have the following in a MOF file:
>>
>> instance of CIM_RegisteredProfile
>> {
>>   InstanceID = "CIM:RH_Fan";
>>   RegisteredOrganization = 2;
>>   RegisteredName = "Fan";
>>   RegisteredVersion = "1.0.0";
>>   AdvertiseTypes = 3;
>> };
>>
>> This is then compiled similar to how classes are compiled into the 
>> repository. The default provider serves the request for 
>> RegisteredProfile by pulling the instance out of the repository.
>>
>> SFCB's instances of RegiteredProfile work this way.  See 
>> 20_indication.mof for details.
>>
>> Using static instances would save you needing the json file and extra 
>> provider to parse it. I'm unsure if Pegasus also honors the instance 
>> keyword when compiling MOFs, but it is worth a look.
>>
>>
>> -Chris
>> SBLIM Team
>>
>>
>>
>> On 07/05/2013 07:39 AM, Michal Minář wrote:
>>> Hi,
>>>
>>> according to Profile Registration Profile [1], there are two ways of 
>>> registered profile advertisement:
>>>
>>>  1. Central Class Profile Implementation Advertisement
>>>  2. Scoping Class Profile Implementation Advertisement
>>>
>>> Both are mutually exclusive (can not be used together for the same 
>>> profile). From what I've read they have following features:
>>>
>>>  1. Central Class
>>>       * associates instances of Central Class to instance of
>>>         RegisteredProfile
>>>           o every profile has usually different Central Class
>>>       * pros:
>>>           o simple clients
>>>               + both generic (operating on CIM_RegisteredProfile)
>>>                 and LMI specific clients could use the same
>>>                 algorithm to find out, which profiles and versions
>>>                 are installed
>>>               + just one call to Associators from particular
>>>                 instance of Central Class
>>>           o compatible with other providers (from other vendors)
>>>             implementing the same profile
>>>               + both can run under the same broker
>>>       * cons:
>>>           o difficult implementation
>>>               + each of our profile would need to implement its own
>>>                 implementation of ElementConformsToProfile
>>>                 association class
>>>               + can not be done generically
>>>  2. Scoping Class
>>>       * associates instance of Scoping Class to instance of
>>>         RegisteredProfile
>>>           o Scoping Class is practically always CIM_ComputerSystem
>>>               + there is just one instance of ScopingClass on
>>>                 particular CIMOM
>>>       * pros:
>>>           o simple implementation
>>>               + we can make the registration generic - see below
>>>       * cons:
>>>           o difficulties for generic clients in finding out, which
>>>             profile and version is available
>>>               + see section 9.4 in [1]
>>>               + this does no apply to OpenLMI specific clients,
>>>                 which could enumerate/query just
>>>                 LMI_RegisteredProfile instances
>>>           o OpenLMI providers would not be compatible with those
>>>             provided by other vendors implementing the same profile
>>>
>>> Me and Jan think that the Scoping Class approach is the right way. 
>>> Here is a proposal for profile registration based on this approach:
>>>
>>>  1. let's create a file
>>>       * /usr/share/openlmi-{providers,network,storage}/LMI_{Software,Network,Storage,...}RegisteredProfiles.json
>>>  2. with contents (in json) below
>>>      *
>>>
>>>         [ { "RegisteredName" : "Software Inventory"
>>>           , "Description" : "OpenLMI implementation of Software
>>>         Inventory DMTF profile"
>>>           ,"RegisteredVersion" : "1.0.1"
>>>           , "RegisteredOrganization" : 2
>>>           , "RegisteredOrganizationName" : "DMTF"
>>>           , "ScopingClass" : "CIM_System"
>>>           , "ImplementedFeatures" : null
>>>           , "MajorVersion" : 0
>>>           , "MinorVersion" : 9
>>>           , "RevisionNumber" : 1
>>>           , "ReferencedProfiles" : [
>>>               { "ClassName" : "CIM_RegisteredProfile"
>>>               , "InstanceID": "DMTF+Profile Registration+1.0.0"
>>>         }
>>>         ]
>>>           }
>>>         ]
>>>
>>>       * where
>>>           o RegisteredName, RegisteredOrganizationName,
>>>             RegisteredVersion, Description, MajorVersion,
>>>             MinorVersion and RevisionNumber are mandatory
>>>           o ScopingClass (string) defaults to Linux_ComputerSystem
>>>               + will be associated with instances of
>>>                 LMI_ElementConformsToProfile with this very instance
>>>                 of LMI_RegisteredProfile
>>>           o ImplementedFeatures (array of strings) defaults to null
>>>           o RegisteredOrganization (uint16) defaults to 2 (DMTF)
>>>           o RegisteredOrganizationName (string) will be used to fill
>>>             LMI_RegisteredProfile::OtherRegisteredOrganizationproperty
>>>             if RegisteredOrganization == 1
>>>           o ReferencedProfiles defaults to:
>>>               + [{ "ClassName" : "CIM_RegisteredProfile",
>>>                 "InstanceID": "DMTF+Profile Registration+1.0.0"}]
>>>               + may contain arbitrary number of objects
>>>       * top-level node is an array - so one file can define more
>>>         profile instances
>>>           o for LMI_SoftwareProfile.conf it would be:
>>>               + Software Inventory
>>>               + Software Update
>>>       * we could use yajl library in c implementation for parsing
>>>         (available in RHEL)
>>>  3. upon rpm installation, this would get registered by symlinking
>>>     this file into directory
>>>       * /usr/lib/openlmi/registered_profiles/
>>>  4. our c provider for LMI_RegisteredProfile would read all files in
>>>     this directory and generate instances such as this (in pseudo code):
>>>       * instance of LMI_RegisteredProfile {
>>>           InstanceID = "LMI:" + RegisteredOrganizationName + "+" +
>>>         RegisteredName + "+" + RegisteredVersion;
>>>           AdvertisedTypes = [2];
>>>           Caption = "OpenLMI " + RegisteredName + " profile
>>>         implementation";
>>>           Description = Description;
>>>           RegisteredName = RegisteredName;
>>>           RegisteredOrganization = RegisteredOrganization;
>>>           RegisteredVersion = "1.0.0";
>>>           MajorVersion = MajorVersion;
>>>           MinorVersion = MinorVersion;
>>>           RevisionNumber = RevisionNumber;
>>>           SpecificationType = 2;
>>>         };
>>>       * together with associations of ScopingClass instances to this
>>>         registered profile instance
>>>
>>> Does it make sense? Any other ideas?
>>>
>>> Michal
>>>
>>> [1] 
>>> http://www.dmtf.org/sites/default/files/standards/documents/DSP1033_1.0.0.pdf
>>>
>>>
>>>
>>> _______________________________________________
>>> openlmi-devel mailing list
>>> openlmi-devel at lists.fedorahosted.org
>>> https://lists.fedorahosted.org/mailman/listinfo/openlmi-devel
>>
>>
>>
>> _______________________________________________
>> openlmi-devel mailing list
>> openlmi-devel at lists.fedorahosted.org
>> https://lists.fedorahosted.org/mailman/listinfo/openlmi-devel
>
>
>
> _______________________________________________
> openlmi-devel mailing list
> openlmi-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/openlmi-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fedorahosted.org/pipermail/openlmi-devel/attachments/20130710/18887626/attachment.html>


More information about the openlmi-devel mailing list