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