RFC: Profile Registration in OpenLMI - generically

Roman Rakus rrakus at redhat.com
Wed Jul 17 12:41:57 UTC 2013


Looks good and can be done automatically.

RR
On 07/16/13 15:38, Jan Safranek wrote:
> On 07/15/2013 10:56 AM, Jan Safranek wrote:
>> Hi,
>>
>> I have alternative proposal how to do profile registration using Pegasus
>> native classes.
>>
>> Advantages:
>> - no new provider needed
>> - automatic SLP
>>
>> Disadvantages:
>> - Pegasus only
>>
>> As I reported in another email in this thread, it's enough to:
>>
>> 1. extend our openlmi-register-pegasus to add version into
>> PG_ProviderModule instances. E.g.:
>>
>> $ openlmi-register-pegasus -v 0.5.2 < *.mof
> Patch sent for review.
> https://reviewboard-openlmi.rhcloud.com/r/559/
>
>> 2. extend openlmi-mof-register:
>>    2.1 to accept version on command line and pass it to
>> openlmi-register-pegasus
> Patch sent for review.
> https://reviewboard-openlmi.rhcloud.com/r/560/
>
>>    2.2 to create instances of PG_ProviderProfileCapabilities, e.g. by using:
>>    $ openlmi-mof-register register-profile myprofile.mof
> It seems no special 'register-profile' parameter is needed, profile
> registration is just a mof file and can be registered using 'register'
> parameter.
>
> *** How to register a profile ***
>
> Profile registration = instance of PG_ProviderProfileCapabilities. See
> Pegasus mof file (or Yawn) for details about the class properties.
>
> We should register all DMTF profiles we implement + I propose for each
> provider also to register one OpenLMI-<providername> profile, which will
> announce API version of the provider.
>
> Example for OpenLMI Storage, which does *not* implement any SNIA profile
> (it's only inspired by SMI-S), but implements some SNIA subprofiles:
>
> instance of PG_ProviderProfileCapabilities
> {
>      // just unique ID
>      CapabilityID = "LMI_Storage";
>
>      // 'group:' in .reg file
>      ProviderModuleName = "pycmpiLMI_Storage";
>
>      // 'provider:' in .reg file
>      ProviderName =
> "/usr/lib/python2.7/site-packages/lmi/storage/cimom_entry.py";
>
>      // 0 = Other, look at the huge ValueMap if your profile is there
>      RegisteredProfile = 0;
>
>      // Name of the profile
>      OtherRegisteredProfile = "OpenLMI-Storage";
>      // Organization issuing the profile
>      OtherProfileOrganization = "OpenLMI";
>
>      // Version of the profile (if it's DMTF or SNIA)
>      // Version of the API (if it's OpenLMI profile)
>      ProfileVersion = "0.5.2";
>
>      // list of subprofiles
>      RegisteredSubProfiles = {
>          0,   // 0 = Other, see OtherRegisteredSubProfiles
>          0,   // Look at the ValueMap if your profile is there
>          0,
>          0,
>          0
>      };
>
>      // Name of the subprofiles in SMI-S
>      OtherRegisteredSubProfiles = {
>          "Block Services",
>          "Extent Composition",
>          "File Storage",
>          "Job Control",
>          "Block Server Performance"
>      };
>
>      // Version of the subprofiles in SMI-S
>      SubprofileVersions = {
>          "1.5",
>          "1.5",
>          "1.4",
>          "1.5",
>          "1.5"
>      };
>
>      // Organization issuing the subprofiles
>      OtherSubProfileOrganizations = {
>          "SNIA",
>          "SNIA",
>          "SNIA",
>          "SNIA",
>          "SNIA"
>      };
>
>      // (Huge?) list of all classes which conform to the profile
>      ConformingElements = {
>          "LMI_StorageExtent",
>          "LMI_MDRAIDStorageExtent",
>          // ...
>       };
> };
>
>> 3. update our rpm packages to register/deregister profiles
> Patch sent for review.
> https://reviewboard-openlmi.rhcloud.com/r/563
>
> Pegasus will automatically generate instances of PG_RegisteredProfile,
> PG_RegisteredSubProfile, associate them (PG_SubProfileRequiresProfile)
> and advertise these profiles using SLP. It will also generate (huge!)
> PG_ElementConformsToProfile association between all instances of
> ConformingElements classes and the profile.
>
> Scripts should then check CIM_RegisteredProfile.RegisteredVersion of a
> OpenLMI profile (CIM_RegisteredProfile.RegisteredName). If we want to
> support SFCB later, we can just add CIM_RegisteredProfile instances with
> appropriate properties.
>
> what do you think?
>
> Jan
>
> _______________________________________________
> openlmi-devel mailing list
> openlmi-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/openlmi-devel



More information about the openlmi-devel mailing list