RFC: Profile Registration in OpenLMI - generically

Jan Safranek jsafrane at redhat.com
Tue Jul 16 13:38:11 UTC 2013


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



More information about the openlmi-devel mailing list