Re: CIMOM refuses EmbeddedObject with unknown class

Hello Andreas,

There should be a workaround where even though the spec expects a
weakly-typed EmbeddedObject, the said weakly-typed EmbeddedObject output
should be able to tolerate a strongly-typed Instance, so you can just
create a custom JobControl class that inherits from CIM_ManagedElement,
the mother of all classes, such that the custom class includes all the
fields that you will ever send out to your heart's content, and call that
a day.

Hope this helps =],
Johnny

On 3/20/13 11:03 AM, "Andreas Maier" <[email protected]> wrote:

>
>@Kirk:
>   The special thing with this class __MethodParameters is that it is
>   required to be supported for an implementation of the DMTF Job Control
>   Profile, and that its properties by definition are dynamic. I am not
>   asking for any kind of general support for "virtual" or "dynamic"
>   classes, I am just interested to solve the problem for the Job Control
>   Profile, and hence, for this one class. In the way this class is used
>in
>   the model of the Job Control Profile, it is the provider that
>determines
>   which properties the embedded instances have, and not the client. So I
>   don't think we are opening any doors to external (client-based)
>   manipulation in any way.
>
>   While the provider will control the set of properties in the embedded
>   instance of class __MethodParameters, CIMOMs like OpenPegasus that
>   perform checking of instances against loaded classes, will have to add
>   some support to tolerate that. Currently, OpenPegasus does not tolerate
>   that.
>
>   Other CIMOMs that do not have such checking, do tolerate that already
>   today (there is a number of them). So the strong checking model
>   OpenPegasus employs is not the only valid way to build CIMOMs. I'm not
>   suggesting to give up on the checking, don't get me wrong. In fact, I
>   think that is one of the great sides of OpenPegasus. But if that
>   prevents us from implementing a standard DMTF profile, we need to fix
>   something.
>
>   Actually, I scanned the CIM Schema and I found three classes that have
>   this special behavior of a dynamic set of properties:
>      __MethodParameters - mentioned in CIM_InstMethodCall
>      __JobInParameters and __JobOutParameters, mentioned in
>      CIM_ConcreteJob
>   All three cases are related to the Job Control Profile, and in all
>three
>   cases, the set of properties will be set by the provider, not by the
>   client.
>
>@Marek:
>   I would definitely argue against an automatic approach where any
>unknown
>   class can be used in an embedded instance, or any class can have
>dynamic
>   properties. That completely defeats the purpose of today's checking.
>
>   A registration based approach (as I imagine it) would allow upon
>   registration of a class to state that the class has a dynamic set of
>   properties, and OP would determine the set of classes that are to be
>   treated specially based on the registration information instead of
>   having the set of special class names hard coded. That would probably
>be
>   an improvement over hard coding the class names, but given that today
>we
>   have only three well known class names, I suggest we start small by
>hard
>   coding the class names. If vendor extension schemas need additional
>such
>   classes, or if the CIM schema adds more such classes, we can still add
>   support for registration to OP at a later point in time.
>
>   Not sure what a configuration based approach would be. Did you envision
>   a control switch that enables and disables the special behavior for the
>   hard coded set of class names ? Or to specify the set of class names
>   with dynamic properties in configuration information ? I would not be
>   too thrilled about the latter, and it is not clear to me that we need
>   such a control switch either.
>
>   I'd like to put a fourth approach on the table: Given that the CIM
>   Schema every now and then seems to have a need for classes with dynamic
>   set of properties, and the current text-based way of describing this is
>   not machine readable, we could make it machine readable by adding a
>   class qualifier (in DSP0004) that expresses that the class has a
>dynamic
>   set of properties. The CIMOM would then have a normal class definition
>   loaded, and would inspect the qualifier value and enable the dynamic
>   behavior based upon that. The nice thing would be that the CIMOM does
>   not need to invent new controls in the provider registration or
>   configuration, that it would be prepared for any new such classes in
>the
>   future, and that it would be very explicit and controlled.
>
>Andy
>
>Andreas Maier
>IBM Senior Technical Staff Member, Systems Management Architecture &
>Design
>IBM Research & Development Laboratory Boeblingen, Germany
>[email protected], +49-7031-16-3654
>________________________________________________________________________
>IBM Deutschland Research & Development GmbH
>Vorsitzende des Aufsichtsrats: Martina Koederitz
>Geschaeftsfuehrung: Dirk Wittkopp
>Sitz der Gesellschaft: Boeblingen
>Registergericht: Amtsgericht Stuttgart, HRB 243294
>
>----- Forwarded by Andreas Maier/Germany/IBM on 2013-03-20 18:26 -----
>
>From:	Kirk Augustin <[email protected]>
>To:	Marek Szermutzky/Germany/IBM@IBMDE, Andreas
>            Maier/Germany/IBM@IBMDE,
>Cc:	Jan Safranek <[email protected]>, "[email protected]"
>            <[email protected]>, Robert
>            Kieninger/Germany/IBM@IBMDE, Vitezslav Crhonek
>            <[email protected]>
>Date:	2013-03-20 16:32
>Subject:	CIMOM refuses EmbeddedObject with unknown class
>
>
>
>An embedded object must have an existing instance provider registered for
>that class, or else it can not be supported.
>If you try to create a virtual or dynamic class, you will allow an
>anything
>goes environment where sites can be externally manipulated in undesirable
>ways.
>The original definition was to simply map calls to providers.
>If one wants to virtualize what goes on between client and provider, that
>should be up to the provider author, not the CIMOM, in my opinion.
>
>
>Kirk  Augustin
>11821 NW McNamee Rd
>Portland, OR 97231
>
>
>HM: 503-289-4356
>From: Marek Szermutzky <[email protected]>
>To: Andreas Maier <[email protected]>
>Cc: Jan Safranek <[email protected]>; "[email protected]"
><[email protected]>; Robert Kieninger <[email protected]>;
>Vitezslav Crhonek <[email protected]>
>Sent: Wednesday, March 20, 2013 2:49 AM
>Subject: Re: CIMOM refuses EmbeddedObject with unknown class
>
>Thank you Andy for your perspective on this topic, greatly appreciated by
>me.
>
>
>On the EmbeddedObject qualifier there is no "class checking" for existence
>of the class when registering MOF today.
>In CMPI we have no mechanism to create an "EmbeddedObject", we only can
>create Instances (no class support).
>
>Well ... DSP0201 writes on the topic EmbeddedObject: "The value must be a
>valid INSTANCE element, defining a single CIM instance of a CIM class or a
>valid CLASS element."
>Which effectively means there always should be at least a class name, even
>if the class is not registered/defined in CIM Server.
>
>As I tried to describe in my last comment, we can build special support
>for
>"dynamic" / "virtual" classes in OpenPegasus where instances would allow
>user-defined keys and properties (minimum requirement: a valid class
>name).
>Another step to take could be to assume unknown classes automatically as
>being a "dynamic/virtual" class, effectively using an empty representation
>class and going from there.
>
>Not sure if it is preferable to have this as an automatism or require
>special registration or configuration.
>
>I will gladly listen to what the users/exploiters want: automatic,
>configured or by registration ?
>So, please speak up! ;)
>
>
>
>Kind regards,
>Marek Szermutzky
>
>Software Engineer / OpenPegasus Maintainer (PMC)
>IBM Systems &Technology Group, Systems Software Development / z/OS
>Capacity
>Management and Support
>--------------------------------------------------------------------------
>-----------------------------------------------------------------
>
>IBM Deutschland
>Schoenaicher Str. 220
>71032 Boeblingen
>Phone: +49-7031-16-5182
>E-Mail: [email protected]
>--------------------------------------------------------------------------
>-----------------------------------------------------------------
>
>IBM Deutschland Research & Development GmbH / Vorsitzende des
>Aufsichtsrats: Martina Koederitz
>Geschäftsführung: Dirk Wittkopp
>Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht Stuttgart,
>HRB 243294
>
>
>
>From:        Andreas Maier/Germany/IBM
>To:        Marek Szermutzky/Germany/IBM@IBMDE, Jan Safranek
><[email protected]>
>Cc:        Vitezslav Crhonek <[email protected]>,
>[email protected] <[email protected]>, Robert
>Kieninger/Germany/IBM@IBMDE
>Date:        19.03.2013 22:26
>Subject:        CIMOM refuses EmbeddedObject with unknown class
>
>
>Marek, Jan,
>At this point (with Jim Davis' response to my other mail still
>outstanding), my guess is that OpenPegasus will need to special-case class
>__MethodParameters. One reason is that its properties are likely to
>correspond to the method that was invoked. Which means its declaration
>changes every time, but it keeps the same class name. It is therefore not
>possible to come up with a statically declared class for that.
>
>One idea is that OpenPegasus would disable its class checking for
>EmbeddedObject qualified elements that contain an embedded instance of
>that
>special class.
>
>If that is not possible because OpenPegasus internally depends on class
>declarations, then one other idea is that OpenPegasus dynamically creates
>an internal representation of the class declaration based on the
>properties
>it finds in the embedded instance of that special class (because that is
>supposedly how it works with this class).
>
>I believe there is already a small handful of such cases in the CIM
>schema,
>and tomorrow some vendor could come up with a new one.  Note that the
>reason the EmbeddedObject qualifier is used and not EmbeddedInstance, is
>that that allows not having to declare the class name in the qualifier.
>Ignoring the fact that EmbeddedObject is simply the older one of the two,
>one could also argue that the whole intention of the EmbeddedObject
>qualifier is that the class is not necessarily declared. If it was
>declared
>one could have used EmbeddedInstance and specify it (arguably that would
>not work for polymorphic use of associations because they do not have a
>single root class, or esoteric cases of mixes of ordinary classes,
>indications and associations).
>
>Bottom line, I think we need to have a discussion as to whether class
>checking is a good idea for embedded instances in EmbeddedObject qualified
>elements. Is that somehow doable in OpenPegasus ?
>
>Andy
>
>Andreas Maier
>IBM Senior Technical Staff Member, Systems Management Architecture &
>Design
>IBM Research & Development Laboratory Boeblingen, Germany
>[email protected], +49-7031-16-3654
>________________________________________________________________________
>IBM Deutschland Research & Development GmbH
>Vorsitzende des Aufsichtsrats: Martina Koederitz
>Geschaeftsfuehrung: Dirk Wittkopp
>Sitz der Gesellschaft: Boeblingen
>Registergericht: Amtsgericht Stuttgart, HRB 243294
>
>----- Forwarded by Andreas Maier/Germany/IBM on 2013-03-19 22:12 -----
>
>From:        Marek Szermutzky/Germany/IBM
>To:        Jan Safranek <[email protected]>
>Cc:        Vitezslav Crhonek <[email protected]>, Andreas
>Maier/Germany/IBM@IBMDE, [email protected]
><[email protected]>, Robert Kieninger/Germany/IBM@IBMDE
>Date:        13.03.2013 13:31
>Subject:        Re: CIMOM refuses EmbeddedObject with unknown class
>
>
>Hi !
>
>Good to have you on the mailing list and thank you for reporting this
>problem. It looks like you are the first one trying to implement Job
>control, not too surprising though since the profile only was published in
>May 2012. EmbeddedInstance/EmbeddedObject support works well perfectly
>fine
>in OpenPegasus as long as instances are based on a registered class (known
>and full defined class).
>
>To be honest ... this arbitrarily generated class "__MethodParameters" was
>a big surprise to me. My first reaction was to call it a "dirty trick" and
>asking for who introduced that concept of a "virtual" class in the DMTF
>CIM
>Schema definition. ;)
>But I understand your situation and that this nothing you chose to do.
>
>Let me try to give you a short description on the background and the
>reason
>this doesn't work right now.
>The design approach in OpenPegasus for CMPI is to have instances always be
>based on a defined class like programming languages do. There you cannot
>create an instance of a class without having the class defined. This has
>several advantages, obvious things like type-safety and stability but also
>in the area of footprint and performance. What I am trying to say is that
>with OpenPegasus 2.12.0 I see no easy circumvention which would allow to
>implement the indication that uses "__MethodParameters" (that indication
>is
>an optional feature in Job Control Profile).
>
>I discussed this with one of my fellows (Robert Kieninger), we invented
>the
>SCMO model in OpenPegasus together (we made that "instance based on class
>only" design decision). We came to the conclusion that supporting this
>"__MethodParameters" needs some code changes and a feature addition to the
>Single Chunk Memory Object Model.
>We basically would add a flag to our internal representation of classes
>which says: "virtual". On these "virtual" classes we would allow
>"user-defined properties" to be added, just as "user-defined key
>properties". Assuming "__MethodParameters" would be registered with the
>CIM
>Server as an empty class and flagged as "virtual", you now could create
>CMPI instances from that class and freely add whatever properties
>required.
>The advantage of such an approach is that we do not lose the performance
>advantage existing providers, as well as the type-safety for provider
>creating instances for defined classes.
>
>I have not done a full analysis on the necessary code changes (effort?) to
>implement support for such "virtual" classes, but I believe this would be
>the right solution to the Job Control Profile issue. I do not know the
>time
>frame in which you would need this fixed, but assuming OpenPegasus 2.13
>with Release Date of 15 July 2013 is sufficient, can you imagine working
>your code and test cases in a way that you would register a class
>"__MethodParameters" in OpenPegasus which holds the parameters for all
>methods used in your testing (that's the quick hack around the problem I
>see) ?
>
>But maybe someone else has a proposal for a quicker solution or
>circumvention ?
>
>
>Putting Andreas Maier (Andy) on CC.
>Andy ? Do you think we can find someone in IBM to pick up the work
>necessary to implement this "virtual" classes concept in SCMO and CMPI ?
>
>
>Kind regards,
>Marek Szermutzky
>
>Software Engineer / OpenPegasus Maintainer (PMC)
>IBM Systems &Technology Group, Systems Software Development / z/OS
>Capacity
>Management and Support
>--------------------------------------------------------------------------
>-----------------------------------------------------------------
>
>IBM Deutschland
>Schoenaicher Str. 220
>71032 Boeblingen
>Phone: +49-7031-16-5182
>E-Mail: [email protected]
>--------------------------------------------------------------------------
>-----------------------------------------------------------------
>
>IBM Deutschland Research & Development GmbH / Vorsitzende des
>Aufsichtsrats: Martina Koederitz
>Geschäftsführung: Dirk Wittkopp
>Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht Stuttgart,
>HRB 243294
>
>
>
>
>From:        Jan Safranek <[email protected]>
>To:        [email protected]
>Cc:        Vitezslav Crhonek <[email protected]>
>Date:        13.03.2013 10:22
>Subject:        Re: CIMOM refuses EmbeddedObject with unknown class
>
>
>
>On 03/13/2013 09:22 AM, Jan Safranek wrote:
>> I have a CMPI provider for CIM_MethodResult class under Pegasus 2.12.0.
>> It has EmbeddedInstance('CIM_InstMethodCall') property
>PostCallIndication.
>>
>> This CIM_InstMethodCall class has EmbeddedObject property
>> MethodParameters and description of the property says:
>>
>>    The parameters of the method, formatted as an EmbeddedObject (with a
>>    predefined class name of "__MethodParameters".
>>
>> Now if I set the MethodParameters property with CIM instance of
>> not-existing "__MethodParameters" class in my provider, Pegasus returns
>> CMPI_RC_ERR_NOT_FOUND from
>> src/Pegasus/ProviderManager2/CMPI/CMPI_BrokerEnc.cpp:mbEncNewInstance()
>>
>> If I try to use "CIM_ManagedElement" as classname of the embedded object
>> just for testing, Pegasus shows correct property, i.e. these
>> EmbeddedInstances and EmbeddedObjects work well for registered classes.
>
>Well, it does not work so well... I can add only properties specified
>for CIM_ManagedElement, I cannot add parameters of the method as
>properties - the parameter names (=name of __MethodParameters
>properties) are different for each method which starts a job.
>
>Am I the first one, who tries to implement job control? How can I return
>an output parameter from a method, which created a job, without using
>embedded instance? Whole CIM is full of these methods... Do I miss
>something?
>
>Jan
>
>
>
>
>