6:39 a.m.
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...