<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">Hi MIchal, <br>
      <br>
      &gt; use a CIM_RegisteredProfile directly - no subclass with
      versioning info we need<br>
      <br>
      You can create the subclass just above it, like this: <br>
      <br>
        class LMI_RegisteredProfile : CIM_RegisteredProfile<br>
         {<br>
          /* whatever */<br>
         };<br>
      <br>
        instance of LMI_RegisteredProfile<br>
         {<br>
          InstanceID = "CIM:RH_Fan";<br>
          RegisteredOrganization = 2;<br>
          RegisteredName = "Fan";<br>
          RegisteredVersion = "1.0.0";<br>
          AdvertiseTypes = 3;<br>
         };<br>
      <br>
      <br>
      &gt; Please correct me, if I'm wrong. I've only tried to create
      class LMI_RegisteredProfile without any provider under <br>
      &gt; Pegasus. And then tried to create static instances, which
      failed with CIM_ERR_NOT_SUPPORTED.<br>
      <br>
      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.<br>
      <br>
      <br>
      -Chris<br>
      SBLIM Team<br>
      <br>
      On 07/10/2013 01:34 AM, Michal Minář wrote:<br>
    </div>
    <blockquote cite="mid:51DCF283.2060306@redhat.com" type="cite">
      <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
      <div class="moz-cite-prefix">Thank you Chris for the tip.<br>
        <br>
        But if I'm not mistaken, this would force us to either:<br>
        <ul>
          <li>use a CIM_RegisteredProfile directly - no subclass with
            versioning info we need</li>
          <li>make a LMI_RegisteredProfile with corresponding provider,
            with some persistent storage for storing installed static
            instances</li>
          <ul>
            <li>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)</li>
          </ul>
        </ul>
        <p>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<br>
          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.<br>
        </p>
        <p>Michal<br>
        </p>
        On 9.7.2013 20:04, Chris Buccella wrote:<br>
      </div>
      <blockquote cite="mid:51DC50BB.3030403@linux.vnet.ibm.com"
        type="cite">
        <meta content="text/html; charset=UTF-8"
          http-equiv="Content-Type">
        <div class="moz-cite-prefix">You might also consider using
          static instances for RegisteredProfiles. This means that the
          instance is defined in MOF, then compiled directly into the
          repository. <br>
          <br>
          For example, you could have the following in a MOF file:<br>
          <br>
          instance of CIM_RegisteredProfile<br>
          {<br>
            InstanceID = "CIM:RH_Fan";<br>
            RegisteredOrganization = 2;<br>
            RegisteredName = "Fan";<br>
            RegisteredVersion = "1.0.0";<br>
            AdvertiseTypes = 3;<br>
          };<br>
          <br>
          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.<br>
          <br>
          SFCB's instances of RegiteredProfile work this way.  See
          20_indication.mof for details. <br>
          <br>
          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.<br>
          <br>
          <br>
          -Chris<br>
          SBLIM Team<br>
          <br>
          <br>
          <br>
          On 07/05/2013 07:39 AM, Michal Minář wrote:<br>
        </div>
        <blockquote cite="mid:51D6B066.4000806@redhat.com" type="cite">
          <meta http-equiv="content-type" content="text/html;
            charset=UTF-8">
          Hi,<br>
          <br>
          according to Profile Registration Profile [1], there are two
          ways of registered profile advertisement:<br>
          <ol>
            <li>Central Class Profile Implementation Advertisement<br>
            </li>
            <li>Scoping Class Profile Implementation Advertisement<br>
            </li>
          </ol>
          <p>Both are mutually exclusive (can not be used together for
            the same profile). From what I've read they have following
            features:<br>
          </p>
          <ol>
            <li>Central Class</li>
            <ul>
              <li>associates instances of Central Class to instance of
                RegisteredProfile</li>
              <ul>
                <li>every profile has usually different Central Class<br>
                </li>
              </ul>
              <li>pros:</li>
              <ul>
                <li>simple clients</li>
                <ul>
                  <li>both generic (operating on CIM_RegisteredProfile)
                    and LMI specific clients could use the same
                    algorithm to find out, which profiles and versions
                    are installed</li>
                  <li>just one call to Associators from particular
                    instance of Central Class</li>
                </ul>
                <li>compatible with other providers (from other vendors)
                  implementing the same profile</li>
                <ul>
                  <li>both can run under the same broker</li>
                </ul>
              </ul>
              <li>cons:</li>
              <ul>
                <li>difficult implementation</li>
                <ul>
                  <li>each of our profile would need to implement its
                    own implementation of ElementConformsToProfile
                    association class</li>
                  <li>can not be done generically<br>
                  </li>
                </ul>
              </ul>
            </ul>
            <li>Scoping Class</li>
            <ul>
              <li>associates instance of Scoping Class to instance of
                RegisteredProfile</li>
              <ul>
                <li>Scoping Class is practically always
                  CIM_ComputerSystem</li>
                <ul>
                  <li>there is just one instance of ScopingClass on
                    particular CIMOM</li>
                </ul>
              </ul>
              <li>pros:</li>
              <ul>
                <li>simple implementation</li>
                <ul>
                  <li>we can make the registration generic - see below<br>
                  </li>
                </ul>
              </ul>
              <li>cons:</li>
              <ul>
                <li>difficulties for generic clients in finding out,
                  which profile and version is available</li>
                <ul>
                  <li>see section 9.4 in [1]</li>
                  <li>this does no apply to OpenLMI specific clients,
                    which could enumerate/query just
                    LMI_RegisteredProfile instances<br>
                  </li>
                </ul>
                <li>OpenLMI providers would not be compatible with those
                  provided by other vendors implementing the same
                  profile</li>
              </ul>
            </ul>
          </ol>
          <p>Me and Jan think that the Scoping Class approach is the
            right way. Here is a proposal for profile registration based
            on this approach:<br>
          </p>
          <ol>
            <li>let's create a file</li>
            <ul>
              <li><tt>/usr/share/openlmi-{providers,network,storage}/LMI_{Software,Network,Storage,...}RegisteredProfiles.json</tt></li>
            </ul>
            <li>with contents (in json) below<br>
            </li>
            <ul>
              <li>
                <p><tt>[ { "RegisteredName" : "Software Inventory"</tt><tt><br>
                  </tt><tt>  , "Description" : "OpenLMI implementation
                    of Software Inventory DMTF profile"</tt><tt><br>
                  </tt><tt>  ,</tt><tt> "RegisteredVersion" </tt><tt>:
                    "1.0.1"</tt><tt><br>
                  </tt><tt>  , "RegisteredOrganization" : 2</tt><tt><br>
                  </tt><tt>  , "RegisteredOrganizationName" : "DMTF"</tt><tt><br>
                  </tt><tt>  , "ScopingClass" : "CIM_System"</tt><tt><br>
                  </tt><tt>  , "ImplementedFeatures" : null<br>
                      , "MajorVersion" : 0</tt><tt><br>
                  </tt><tt>  , "MinorVersion" : 9</tt><tt><br>
                  </tt><tt>  , "RevisionNumber" : 1</tt><tt><br>
                  </tt><tt>  , "ReferencedProfiles" : [</tt><tt><br>
                  </tt><tt>      { "ClassName" : "CIM_RegisteredProfile"</tt><tt><br>
                  </tt><tt>      , "InstanceID": "</tt><tt>DMTF+Profile
                    Registration+1.0.0"</tt><tt><br>
                  </tt><tt>      </tt><tt>}</tt><tt><br>
                  </tt><tt>    </tt><tt>]</tt><tt><br>
                  </tt><tt>  }</tt><tt><br>
                  </tt><tt>]</tt></p>
              </li>
              <li>where</li>
              <ul>
                <li>RegisteredName, RegisteredOrganizationName,
                  RegisteredVersion, Description, MajorVersion,
                  MinorVersion and RevisionNumber are mandatory</li>
                <li>ScopingClass (string) defaults to
                  Linux_ComputerSystem</li>
                <ul>
                  <li>will be associated with instances of
                    LMI_ElementConformsToProfile with this very instance
                    of LMI_RegisteredProfile</li>
                </ul>
                <li>ImplementedFeatures (array of strings) defaults to
                  null<br>
                </li>
                <li>RegisteredOrganization (uint16) defaults to 2 (DMTF)</li>
                <li>RegisteredOrganizationName (string) will be used to
                  fill <tt>LMI_Registe</tt><tt>redP</tt><tt>rofile::</tt><tt>OtherRegistered</tt><tt>Organization</tt><tt>
                  </tt>property if <tt>RegisteredOrganization == 1</tt><br>
                </li>
                <li>ReferencedProfiles defaults to:</li>
                <ul>
                  <li><tt>[{ "ClassName" : "CIM_RegisteredProfile",
                      "InstanceID": "</tt><tt><span style="color: rgb(0,
                        0, 0); font-family: 'Times New Roman';
                        font-size: medium; font-style: normal;
                        font-variant: normal; font-weight: normal;
                        letter-spacing: normal; line-height: normal;
                        orphans: auto; text-align: start; text-indent:
                        0px; text-transform: none; white-space: normal;
                        widows: auto; word-spacing: 0px;
                        -webkit-text-stroke-width: 0px; display: inline
                        !important; float: none;">DMTF+Profile
                        Registration+1.0.0"<tt> </tt></span>}]</tt></li>
                  <li>may contain arbitrary number of objects</li>
                </ul>
              </ul>
              <li>top-level node is an array - so one file can define
                more profile instances</li>
              <ul>
                <li>for LMI_SoftwareProfile.conf it would be:</li>
                <ul>
                  <li>Software Inventory</li>
                  <li>Software Update</li>
                </ul>
              </ul>
              <li>we could use yajl library in c implementation for
                parsing (available in RHEL)</li>
            </ul>
            <li>upon rpm installation, this would get registered by
              symlinking this file into directory</li>
            <ul>
              <li><tt>/usr/lib/openlmi/registered_profiles/</tt></li>
            </ul>
            <li>our c provider for LMI_RegisteredProfile would read all
              files in this directory and generate instances such as
              this (in pseudo code):</li>
            <ul>
              <li><tt>instance of LMI_RegisteredProfile {</tt><tt><br>
                </tt><tt>  InstanceID = "LMI:" +
                  RegisteredOrganizationName + "+" + RegisteredName +
                  "+" + RegisteredVersion;</tt><tt><br>
                </tt><tt>  AdvertisedTypes = [2];</tt><tt><br>
                </tt><tt>  Caption = "OpenLMI " + RegisteredName + "
                  profile implementation";</tt><tt><br>
                </tt><tt>  Description = Description;</tt><tt><br>
                </tt><tt>  RegisteredName = RegisteredName;</tt><tt><br>
                </tt><tt>  RegisteredOrganization =
                  RegisteredOrganization;</tt><tt><br>
                </tt><tt>  RegisteredVersion = "1.0.0";</tt><tt><br>
                </tt><tt>  MajorVersion = MajorVersion;</tt><tt><br>
                </tt><tt>  MinorVersion = MinorVersion;</tt><tt><br>
                </tt><tt>  RevisionNumber = RevisionNumber;</tt><tt><br>
                </tt><tt>  SpecificationType = 2;</tt><tt><br>
                </tt><tt>};</tt></li>
              <li>together with associations of ScopingClass instances
                to this registered profile instance</li>
            </ul>
          </ol>
          <p>Does it make sense? Any other ideas?<br>
          </p>
          <p>Michal<br>
          </p>
          <p>[1] <a moz-do-not-send="true"
              class="moz-txt-link-freetext"
href="http://www.dmtf.org/sites/default/files/standards/documents/DSP1033_1.0.0.pdf">http://www.dmtf.org/sites/default/files/standards/documents/DSP1033_1.0.0.pdf</a><br>
          </p>
          <br>
          <fieldset class="mimeAttachmentHeader"></fieldset>
          <br>
          <pre wrap="">_______________________________________________
openlmi-devel mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:openlmi-devel@lists.fedorahosted.org">openlmi-devel@lists.fedorahosted.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://lists.fedorahosted.org/mailman/listinfo/openlmi-devel">https://lists.fedorahosted.org/mailman/listinfo/openlmi-devel</a>
</pre>
        </blockquote>
        <br>
        <br>
        <fieldset class="mimeAttachmentHeader"></fieldset>
        <br>
        <pre wrap="">_______________________________________________
openlmi-devel mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:openlmi-devel@lists.fedorahosted.org">openlmi-devel@lists.fedorahosted.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://lists.fedorahosted.org/mailman/listinfo/openlmi-devel">https://lists.fedorahosted.org/mailman/listinfo/openlmi-devel</a>
</pre>
      </blockquote>
      <br>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
openlmi-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:openlmi-devel@lists.fedorahosted.org">openlmi-devel@lists.fedorahosted.org</a>
<a class="moz-txt-link-freetext" href="https://lists.fedorahosted.org/mailman/listinfo/openlmi-devel">https://lists.fedorahosted.org/mailman/listinfo/openlmi-devel</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>