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...
>
>
>
> _______________________________________________
> openlmi-devel mailing list
> openlmi-devel(a)lists.fedorahosted.org
>
https://lists.fedorahosted.org/mailman/listinfo/openlmi-devel
_______________________________________________
openlmi-devel mailing list
openlmi-devel(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/openlmi-devel