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

use a CIM_RegisteredProfile directly - no subclass with versioning

Please correct me, if I'm wrong. I've only tried to create class

Pegasus. And then tried to create static instances, which failed with

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

On 07/10/2013 05:56 PM, Chris Buccella wrote: > Hi MIchal, > >> use a CIM_RegisteredProfile directly - no subclass with versioning > info we need > > You can create the subclass just above it, like this: > > class LMI_RegisteredProfile : CIM_RegisteredProfile > { > /* whatever */ > }; > > instance of LMI_RegisteredProfile > { > InstanceID = "CIM:RH_Fan"; > RegisteredOrganization = 2; > RegisteredName = "Fan"; > RegisteredVersion = "1.0.0"; > AdvertiseTypes = 3; > }; > > >> 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. > > I'm not very knowledgeable about Pegasus, but this seems strange. If the > mof compiler allowed you to compile the static instance, it should be in > the repository, and I would expect that you could retrieve it with an > EnumerateInstances call for CIM_RegisteredProfile. If it did not > successfully compile, I would expect the error to be CIM_ERR_NOT_FOUND. Pegasus has configuration option for this, see repositoryIsDefaultInstanceProvider at http://cvs.opengroup.org/cgi-bin/viewcvs.cgi/*checkout*/pegasus/doc/Build... Maybe we should enable it by default in Fedora.

Jan _______________________________________________ openlmi-devel mailing list openlmi-devel(a)lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/openlmi-devel

On 07/05/2013 01:39 PM, Michal Minář wrote: > # 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; > }; I'm looking at Pegasus way of registering profiles. To register new profile, one must create instance of PG_ProviderProfileCapabilities (either via MOF or via CreateInstance WBEM call). It then automatically creates instances of: PG_RegisteredProfile PG_SoftwareIdentity (PG_RegisteredSubProfile) + all associations between them. The PG_SoftwareIdentity instance then contains VersionString property, which is taken from provider's PG_ProviderModule (=we can influence it). Optionally, array of class names in ConformingElements property can be specified and Pegasus then automatically creates PG_ElementConformsToProfile association between PG_RegisteredProfile and all instances of these classes.

I would rather strive for more portable solution. This is imho too much Pegasus-oriented.

What I'm missing here is the storage for API version of our providers. Either we'd have to encode it into some String variable like InstanceID, ElementName or Caption or use a RegisteredVersion property, which should contain DMTF version of implemented profile - another deviation from standard.

Otherwise I like its simplicity. Michal On 15.7.2013 10:56, 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 > > 2. extend openlmi-mof-register: > 2.1 to accept version on command line and pass it to > openlmi-register-pegasus > 2.2 to create instances of PG_ProviderProfileCapabilities, e.g. by > using: > $ openlmi-mof-register register-profile myprofile.mof > > Question is, if the profile registration should be directly Pegasus mof > file or some other file and openlmi-mof-register would create a Pegasus > mof file from it. > > 3. update our rpm packages to register/deregister profiles > > > Jan > _______________________________________________ > 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

On 07/15/2013 11:24 AM, Michal Minář wrote: > I would rather strive for more portable solution. This is imho too much > Pegasus-oriented. Yes, it is, I think that's the easiest way to get SLP working. It's possible to implements and inject similar classes to SFCB in the same way, it just requires larger MOF files with profile registrations, as SFCB does not support much classes in root/interop. > What I'm missing here is the storage for API version of our providers. > Either we'd > have to encode it into some String variable like InstanceID, ElementName > or Caption or use a RegisteredVersion property, which should contain > DMTF version of implemented > profile - another deviation from standard. The version of API is not in CIM_RegisteredProfile subclass, but in PG_ElementSoftwareIdentity, which describes *implementation* of the profile and is associated to CIM_RegisteredProfile. And it is free form string.

ElementSoftwareIdentity has properties like MajorVersion, MinorVersion and RevisionNumber, but from some reason they are not filled. Maybe it's a bug in Pegasus, which could be fixed. > Otherwise I like its simplicity. > > Michal > > On 15.7.2013 10:56, 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 >> >> 2. extend openlmi-mof-register: >> 2.1 to accept version on command line and pass it to >> openlmi-register-pegasus >> 2.2 to create instances of PG_ProviderProfileCapabilities, e.g. by >> using: >> $ openlmi-mof-register register-profile myprofile.mof >> >> Question is, if the profile registration should be directly Pegasus mof >> file or some other file and openlmi-mof-register would create a Pegasus >> mof file from it. >> >> 3. update our rpm packages to register/deregister profiles >> >> >> Jan >> _______________________________________________ >> 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 _______________________________________________ openlmi-devel mailing list openlmi-devel(a)lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/openlmi-devel

On Mon, 2013-07-15 at 11:24 +0200, Michal Minář wrote: > I would rather strive for more portable solution. This is imho too much > Pegasus-oriented. Pegasus is the CIMOM we are using for OpenLMI. SFCB is used for testing to provide additional coverage. I wouldn't worry too much about Pegasus specific work where we are making a deliberate decision to use Pegasus features. While we should take sfcb into consideration, sfcb support is not a hard requirement.

> What I'm missing here is the storage for API version of our providers. > Either we'd > have to encode it into some String variable like InstanceID, ElementName > or Caption or use a RegisteredVersion property, which should contain > DMTF version of implemented > profile - another deviation from standard. > > Otherwise I like its simplicity. > > Michal > > On 15.7.2013 10:56, 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 >> >> 2. extend openlmi-mof-register: >> 2.1 to accept version on command line and pass it to >> openlmi-register-pegasus >> 2.2 to create instances of PG_ProviderProfileCapabilities, e.g. by using: >> $ openlmi-mof-register register-profile myprofile.mof >> >> Question is, if the profile registration should be directly Pegasus mof >> file or some other file and openlmi-mof-register would create a Pegasus >> mof file from it. >> >> 3. update our rpm packages to register/deregister profiles >> >> >> Jan >> _______________________________________________ >> 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 _______________________________________________ openlmi-devel mailing list openlmi-devel(a)lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/openlmi-devel

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

I got no other response, so let's call this proposal as agreed. I documented it on our wiki: https://fedorahosted.org/openlmi/wiki/ProfileRegistration Jan