RFC: Profile Registration in OpenLMI - generically

Michal Minář miminar at redhat.com
Fri Jul 5 11:39:18 UTC 2013


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fedorahosted.org/pipermail/openlmi-devel/attachments/20130705/4b244db8/attachment-0001.html>


More information about the openlmi-devel mailing list