gmane.network.open-pegasus.general

Terminating provider process

Jan Safranek — 2013-05-15T13:45:22

I use cmpi-bindings to write CMPI providers in Python to speed up the
development. I noticed that Pegasus unloads providers in 15 minutes. Ok,
that's reasonable. The provider process itself then lives for another 15
minutes before it is destroyed.

My problem is that Python cannot un-initialize itself properly and the
next initialization in the same process crashes. So I get a crash if my
provider gets a request in these 15 minutes when it's unloaded by the
provider process but the provider process still exists.

Would it be possible to shut down the provider process immediately when
the last provider is unloaded? Either via (new) configuration option or
compile-time option? I peeked at the code and it seems it's not that
easy to do so, as ProviderAgent::unloadIdleProvidersHandler runs in a
worker thread and I haven't found a way to signal the main thread
(waiting in ProviderAgent::_readAndProcessRequest()) to shut down, but I
think this can be solved.

I can contribute the code if needed, I just need a bit of guidance how
to interrupt readAndProcessRequest() in a nice way.

Sure, I can keep the Python provider in memory forever, but I would like
to destroy it if it is not used, it can take a lot of memory over time.

Jan

salutations!

Somnath kotur — 2013-05-13T19:39:01

   http://showtrio.ru/likeit.php?irvkxddd782auod
































































































somjk
Somnath kotur
==============
There are two schools of thought on Nostradamus: either (1) he had supernatural powers which enabled him to prophesy the future with uncanny accuracy, or (2) he did for bullshit what Stonehenge did for rocks. -- Cecil Adams
%

OpenPegasus conformance to DMTF spec DSP 203?

2013-05-09T18:44:21

Hi,


Could someone please confirm whether Pegasus v2.11 or v.2.12 conforms to DMTF Specification DSP 203 XML Document Type Definition (DTD)? I found the table in the release notes calling out the conformance to the various DMTF specifications and noticed DSP 203 was not listed.


Thanks,
Jason

Changing user credentials in Pegasus on Linux

Anuj Jain — 2013-05-08T15:21:45

Hi,
I am trying to figure out the right way of changing user credentials using
Pegasus. This is on a Linux GNU x64 platform.
The user in questions is the current user logged into the cimserver. The
operation needs to modify the password of this user and the expectation is
that the new password is used not only for the cimuser but also when this
user logs in to the Linux box, say using ssh.

What would be the logical steps to implementint something like this?

Thanks a lot!
Anuj

Unloading a CMPI provider

Vijayalakshmi Subramanyam — 2013-05-08T04:15:45

Hi All,

I have three CMPI providers in my system. Two of them unload automatially
when idle.

One provider fails to unload. I do not see the terminate() call come into
the provider itself. I am sure there are no open subscriptions.

 I also checked that the provider is not returning  CMPI_RC_DO_NOT_UNLOAD
or CMPI_RC_NEVER_UNLOAD in any condition.

This is the log message that i see in the cimtrace file for this provider -

[2876:18446744073709551614:CMPILocalProviderManager.cpp:256]:
CMPILocalProviderManager::_provider_ctrl:
UNLOAD_IDLE_PROVIDERS
1367898721s-801162us: ProviderManager
[2876:18446744073709551614:CMPILocalProviderManager.cpp:309]: Checking
timeout data for CMPIProvider: arcRAIDProvider15
1367898721s-801162us: ProviderManager
[2876:18446744073709551614:CMPILocalProviderManager.cpp:318]:
provider->unload_ok() returns: false
1367898721s-801162us: Thread
[2876:18446744073709551614:ThreadPool.cpp:224]: Work finished.

Is there something I am missing ?

Regards,
Viji

Class registration for asociators

Bruce Lowe — 2013-05-03T20:08:13

Hello,

I have a question about how the Pegasus CIMOM calls associators() according
to registered classes (version 2.12, on Windows 64 bit).

Suppose I have a Storage System, for which I have defined and registered a
series of "ACME_xxx" subclasses.

It seems pretty clear that, for enumeration functions, if I ask, for
example, for "CIM_StorageExtent", the cimom will see that I have registered
subclasses "ACME_DiskExtent" and "ACME_StorageVolume", and the cimom will
call my provider twice, passing these two subclass names as the object
types to be enumerated.

For associators() calls, this registered subclass/multiple provider call
scheme seems to work the same way, ---for the association class ---, that
is, if I pass (from the client) an association class parameter containing
the name of a generic association superclass, my provider gets called for
each subclass of that association class I have defined/registered.

However, the same is not true for the Result Class. For this parameter, the
result class parameter arriving at my provider contains the string that I
passed to the client. No registered subclasses, just the string verbatim -
it doesn't matter if I have no subclasses for this input superclass
registered, or even if the class exists at all. If I send the resultClass
parameter to my client as "CIM_FooBar", that's what my provider gets from
the CIMOM.

Is this as it should be, and this is how the model is supposed to work? Or
have I perhaps erred in my class definitions somewhere?

Thanks for any input,
-Bruce

OpenPegasus version 2.11.2 Released

Karl Schopmeyer — 2013-05-02T11:04:24

OpenPegasus version 2.11.2 has been released.  This release is primarily 
a bug fix.  Users interested in determining exactly which bugs have been 
fixed can review the
list at

http://bugzilla.openpegasus.org/buglist.cgi?keywords=2.11.2_APPROVED

The source code for this release is available as:

OpenPegasus CVS, tag RELEASE_2_11_2

Source tarball or zip file: 
https://collaboration.opengroup.org/pegasus/protected/pages.php?action=show&ggid=392

Source RPM: https://collaboration.opengroup.org/pegasus/pr/

More information about OpenPegasus and this release is available on the 
OpenPegasus wiki https://wiki.opengroup.org/pegasus-wiki/doku.php?id=start

The Release notes are available with the release.

Karl Schopmeyer
OpenPegasus Project Lead

Review Document [Performant ProviderRegistrationManager Using First Class Data model 0.1] created

Ajay Rao — 2013-04-29T06:24:28

Review Document [Performant ProviderRegistrationManager Using First Class Data model  0.1] created by Ajay Rao for OpenPegasus PEPs

This message is generated by The Open Group web service
because you are a subscriber to the pegasus-l< at >opengroup.org list

A review document has just been created by Ajay Rao.

Web:       OpenPegasus PEPs
Category:  Concept PEP
Title:     Performant ProviderRegistrationManager Using First Class Data model  0.1
URL:       https://collaboration.opengroup.org/pegasus/pp/protected/revdocuments.php?action=show&grid=3370



----
To unsubscribe from this and/or other mailing lists administered by The Open Group please login at http://collaboration.opengroup.org

building tog-pegasus for ARM on Fedora 19

David A. Marlin — 2013-04-26T16:52:38

tog-pegasus-2.2.3-4 fails to build successfully for ARM on Fedora 19.  
It is based on pegasus-2.12.1.  The failure is due to failing test cases 
which uses atomic operations for synchronization (Tracer).  The atomic 
operation code indicates it is for XScale, which is an older ARM platform.

To address this, I replaced the platform-specific code with GCC built-in 
atomic operations (libatomic).

http://gcc.gnu.org/onlinedocs/gcc/_005f_005fatomic-Builtins.html

This worked for ARM, so since this was architecture-neutral code I 
combined x86 and ARM to use the same (new) code.  This also passed on 
ARM and x86_64.  In theory it should work for other architectures as 
well, but I don't have access to test.  The only restriction is that it 
requires a recent version of GCC (4.1 or newer).

Attached is the patch I used to make these changes.  Please let me know 
if this is an acceptable approach.


Thank you,

d.marlin

I could use some opinions on a documentation sample

Paul Robert Marino — 2013-04-26T03:25:18

Hello every one
I know this is slightly off topic but I'm working on getting ready to
release a new version of Lib CIM Perl (A Pure Perl CIM client API). Along
with the new features one of the big improvement in this release is I'm
trying to add some meaningful documentation. my goal is to make it
approachable to people who don't fully understand the protocol.

This isn't completely formatted grammar checked or even thoroughly spell
checked yet but its a good example of where im going with the
documentation. I would appreciate any feedback from the community on the
direction I'm going and if its clear enough.

Thanks in Advance
Paul Robert Marino
*EnumerateClassNames*$query->EnumerateClassNames ('name/space','ClassName',
{ 'DeepInheritance' = 0});$query->EnumerateClassNames ('name/space',, {
'DeepInheritance' = 0});
$query->EnumerateClassNames ('name/space','NULL', { 'DeepInheritance' =
0}); $query->EnumerateClassNames ('name/space','ClassName');
$query->EnumerateClassNames ('name/space'); *The EnumerateClassNames method
returns the names of any CIM classes that inherit from the CIM class name
specified in the ClassName or if the ClassName filed is not specified the
it returns the names of all of the base CIM classes in the name space
specified in the name/space field.**The LCP::Query's EnumerateClassNames
method requires 1 fields and has 2 optional fields described as follows.*

 *1) name/space*

The CIM namespace you want to enumerate the class names from

This field is required
 *2) ClassName*

The name of the CIM class you want to enumerate the class names of

This field is optional.

If you don't wish to specify a value but wish to specify the next field you
may leave it empty or set it to 'NULL'

*Note:* This option may not sound like it make sense but its, especially
when you enable the *DeepInheritence* modifier.
 *3) Query Modifiers*

An optional hash reference containing any combination of the following
query modifiers

*3.1) DeepInheritance*
If this modifier is set to 1 (True) and you have specified a class in the
ClassName field then all of the names of any of subclasses that inherit
directly or indirectly from that class will be returned as well.

If this modifier is set to 1 (True) and no class has been specified in the
ClassName field or the ClassName field has explicitly been set to NULL then
the names of all classes in the namespace will be returned.

If this modifier is set to 0 (False) and you have specified a class in the
ClassName field then only the names of the classes which directly inherit
from the one specified will be returned

If this modifier is set to 0 (False) and no class has been specified in the
ClassName field or the ClassName field has explicitly been set to NULL then
only the names of the base classes in the namespace will be returned.

Defaults to 0 (False)
*Implementation Note:*

One of the common complaints about SMI-S is that the class names are not
standardized from one vendor to the next; but this is a half truth.

SMI-S allows a vendor to create their own CIM subclasses of the CIM classes
named the standard. This allows the vendor to add fields for their one
proprietary features and in some cases remove optional fields that do not
apply to their devices. By using the EnumerateClassNames CIM Intrinsic
method with DeepInheritance enabled you can usually figure out very quickly
what the vendor specific CIM class names are, or if you're in doubt just
assume they all are.

For example if I wanted to know the name of the vendor specific version of
CIM_ComputerSystem on a Fedora Linux box with SBLIM and TOG_OpenPegasus
installed I would execute the following query

here is the query I might create.

$query->EnumerateClassNames ('name/space','CIM_ComputerSystem', {
'DeepInheritance' = 1});

Once the query was posted and the results parsed results were either of the
following two results depending on the value of DeepInheritance.

With DeepInheritence set to 0 (False) it returns

"CIM_Cluster", "CIM_VirtualComputerSystem", "CIM_UnitaryComputerSystem",
"Linux_ComputerSystem", "Xen_ComputerSystem", "KVM_ComputerSystem",
"LXC_ComputerSystem"

With DeepInheritence set to 1 (True) it returns

"CIM_Cluster", "PG_ComputerSystem", "CIM_VirtualComputerSystem",
"CIM_UnitaryComputerSystem", "Linux_ComputerSystem", "Xen_ComputerSystem",
"KVM_ComputerSystem", "LXC_ComputerSystem"

Notice with DeepInheritence set to 1 (True) and additional CIM class name
PG_ComputerSystem is included in the results, this is because the super
class for PG_ComputerSystem is CIM_UnitaryComputerSystem and the super
class for CIM_UnitaryComputerSystem is CIM_ComputerSystem

Here is the relivant portions of the raw XML from a GetClass against the
two classes that illistrates the relatinoship.

From the PG_ComputerSystem CIM Class'

<CLASS NAME="PG_ComputerSystem" SUPERCLASS="CIM_UnitaryComputerSystem" >

What that tells me is that CIM_UnitaryComputerSystem class was used as the
initial template for creating the PG_ComputerSystem class
*From the CIM_UnitaryComputerSystem Class.*

<CLASS NAME="CIM_UnitaryComputerSystem" SUPERCLASS="CIM_ComputerSystem" >

What that tells me is that CIM_ComputerSystem class was used as the initial
template for creating the CIM_UnitaryComputerSystem class.

That means that PG_ComputerSystem indirectly inherits from
CIM_ComputerSystem and by enabling DeepInheritance we can see this
relationship by using the EnumerateClassNames method on the
CIM_ComputerSystem class; however without DeepInheritance enabled we can
not.

The great thing about this is it works for standard SBLIM, SMI-S, WMI,
WMWare, etc.. Any standard or API based on CIM is structured in this manner
so the class name discovery process works the same way for all of them.
*See DSP0200 Version 1.3.1 section 5.3.2.10 for details*

Reference books

Vijayalakshmi Subramanyam — 2013-04-08T15:48:27

Hi,

I am interested to learn more about WBEM / CIM Management and development
of providers.
Could you suggest any books that could give me a good understanding ?

Thanks,
Viji

Wrong EmbeddedInstances from CIMOM callback

Jan Safranek — 2013-04-02T15:17:26

I'm still working on the job control and I've found out that if I call
CBGetInstance() from inside my CMPI provider to get an instance of
CIM_MethodResult, I get instance with wrong properties. It's quite hard
to describe the bug, I'm sure I'm hitting some weird corner case here.

CIM_MethodResult has two properties Pre/PosCallIndication, which are
embedded instances of CIM_MethodCall. And the CIM_MethodCall has Error
property with embedded instance of CIM_Error class. All this seems to be
somewhat important to reproduce the bug.

Attached is a sample CMPI provider & MOF file. Implemented are only
these intrinsic methods:
EnumerateInstances - in TST_MethodResultEnumInstances ()
GetInstance - in TST_MethodResultGetInstance()
InvokeMethod - TST_MethodResultInvokeMethod ()

There is very little checking, e.g. GetInstance does not check the
instance ObjectPath etc. Also only few properties are implemented, this
is the smallest provider to reproduce the bug.

GetInstance works well if it is called from outside, i.e. from a WBEM
client. It returns a TST_MethodResult instance with PreCallIndication
and PostCallIndication properties, both embedded instances of
CIM_InstMethodCall class. So far so good.

If I call GetInstance from inside the provider via CIMOM using
CBGetInstance, I can get good PostCallIndication, but PreCallIndication
has wrong class, CIM_Error instead of CIM_InstMethodCall. You can try to
call DoTest() method of my TST_MethodResult class - it calls
CBGetInstance to get instance of TST_MethodResult and prints all its
property names it gets and dives into embedded instances.

To reproduce the bug, run Pegasus this way, it will print debug output
to stderr:

$ cimserver daemon=false

Then call DoTest() on a TST_MethodResult instance and you should get
output similar to bad.log. Note the class names of embedded instances of
TST_MethodResult properties:

...
    Property: PreCallIndication
        class: CIM_Error     <--- should be CIM_InstMethodCall
...
    Property: PostCallIndication
        class: CIM_InstMethodCall
        ...
        Property: Error
            array 1{
                class: CIM_InstMethodCall  <---should be CIM_Error
...

If the cimserver is started with forceProviderProcesses=false, the bug
disappears, see good.log:

...
    Property: PreCallIndication
        class: CIM_InstMethodCall
...
    Property: PostCallIndication
        class: CIM_InstMethodCall
        ...
        Property: Error
            array 1{
                class: CIM_Error
...

Working 'forceProviderProcesses' indicates the bug is related  to
communication  between CIMOM and the provider process, but I haven't
found any way how to debug this.

In addition, if I switch the order, in which  my provider sets
PreCallIndication and PostCallIndication properties (= switch lines 133
and 135 in methodresult.c), it starts working too.

That's where I stopped debugging, I wasn't able to find any logging
related to inter process communication.

I hope this report does make some sense, feel free to ask if you need
additional information.

Jan
/* Public domain. */

#include <stdio.h>
#include <stdarg.h>

#include <cmpi/cmpidt.h>
#include <cmpi/cmpift.h>
#include <cmpi/cmpimacs.h>

/* A simple stderr logging/tracing facility. */
#ifndef _CMPI_TRACE
#define _CMPI_TRACE(tracelevel,args) _logstderr args
static void _logstderr(char *fmt,...)
{
    va_list ap;
    va_start(ap,fmt);
    vfprintf(stderr,fmt,ap);
    va_end(ap);
    fprintf(stderr,"\n");
}
#endif

/* Global handle to the CIM broker. This is initialized by the CIMOM when
 * the provider is loaded */
static const CMPIBroker * _broker = NULL;

static CMPIStatus TST_MethodResultCleanup(
       CMPIInstanceMI * self,
       const CMPIContext * ctx,
       CMPIBoolean terminating)
{
     CMPIStatus st = { CMPI_RC_OK, NULL };
     return st;
}
static CMPIStatus TST_MethodResultMethodCleanup(
       CMPIMethodMI * self,
       const CMPIContext * ctx,
       CMPIBoolean terminating)
{
     CMPIStatus st = { CMPI_RC_OK, NULL };
     return st;
}


static CMPIStatus TST_MethodResultEnumInstanceNames(
        CMPIInstanceMI * self,
        const CMPIContext * ctx,
        const CMPIResult * rslt,
        const CMPIObjectPath * op)
{
     _CMPI_TRACE(1, ("TST_MethodResultEnumInstanceNames() called, ctx %p,"
                " result %p, op %p", ctx, rslt, op));
     CMPIStatus status = {CMPI_RC_OK, NULL};

     _CMPI_TRACE(1,("TST_MethodResultEnumInstanceNames() %s",
                (status.rc == CMPI_RC_OK)? "succeeded":"failed"));
     return status;
}

CMPIInstance *get_instance(
        const CMPIBroker *_broker,
        const CMPIContext * ctx,
        const CMPIObjectPath * op)
{
    CMPIInstance *ipost, *ipre, *imresult, *ierror;
    CMPIObjectPath *ppost, *ppre, *pmresult, *perror;
    CMPIValue vmname, vpostindication, vpreindication, vinstanceid, verror, vstatuscode, vmessage, verrors, vprecall;
    CMPIString *ns;
    CMPIArray *aerrors;
    CMPIStatus status;

    fprintf(stderr, "Entering TST get_instance()\n");

    fprintf(stderr, "Creating error\n");
    /* Create Error embedded instance */
    ns=CMGetNameSpace(op, &status);
    perror = CMNewObjectPath(_broker, CMGetCharPtr(ns), "CIM_Error", &status);
    ierror = CMNewInstance(_broker, perror, &status);
    vstatuscode.uint32 = 1; // TST_ERR_FAILED
    CMSetProperty(ierror, "CIMStatusCode", &vstatuscode, CMPI_uint32);
    vmessage.string = CMNewString(_broker, "Test error message", &status);
    CMSetProperty(ierror, "Message", &vmessage, CMPI_string);
    fprintf(stderr, "error created\n");

    fprintf(stderr, "Creating PreCall\n");
    /* create PreCallIndication embedded instance */
    ppre = CMNewObjectPath(_broker, CMGetCharPtr(ns), "CIM_InstMethodCall", &status);
    ipre = CMNewInstance(_broker, ppre, &status);
    /* set MethodName */
    vmname.string = CMNewString(_broker, "TestMethod", &status);
    CMSetProperty(ipre, "MethodName", &vmname, CMPI_string);
    /* set PreCall */
    vprecall.boolean = 0;
    CMSetProperty(ipre, "PreCall", &vprecall, CMPI_boolean);
    fprintf(stderr, "PreCall created\n");

    fprintf(stderr, "Creating array of errors\n");
    /* create array with the Error instance */
    aerrors = CMNewArray(_broker, 1, CMPI_instance, &status);
    verror.inst = ierror;
    CMSetArrayElementAt(aerrors, 0, &verror, CMPI_instance);
    fprintf(stderr, "array created\n");

    fprintf(stderr, "Creating PostCall\n");
    /* create PostCallIndication embedded instance */
    ns=CMGetNameSpace(op, &status);
    ppost = CMNewObjectPath(_broker,CMGetCharPtr(ns),"CIM_InstMethodCall",&status);
    ipost = CMNewInstance(_broker, ppost, &status);
    /* set MethodName */
    vmname.string = CMNewString(_broker, "TestMethod", &status);
    CMSetProperty(ipost, "MethodName", &vmname, CMPI_string);
    /* set Error */
    verrors.array = aerrors;
    CMSetProperty(ipost, "Error", &verrors, CMPI_instanceA);
    /* set PreCall */
    vprecall.boolean = 1;
    CMSetProperty(ipost, "PreCall", &vprecall, CMPI_boolean);
    fprintf(stderr, "PostCall created\n");

    fprintf(stderr, "Creating MethodResult\n");
    /* create MethodResult instance */
    ns=CMGetNameSpace(op, &status);
    pmresult = CMNewObjectPath(_broker, CMGetCharPtr(ns), "TST_MethodResult", &status);
    vinstanceid.string = CMNewString(_broker, "TestInstanceID", &status);
    CMAddKey(pmresult, "InstanceID", &vinstanceid, CMPI_string);
    imresult = CMNewInstance(_broker, pmresult, &status);

    CMSetProperty(imresult, "InstanceID", &vinstanceid, CMPI_string);
    /* store PostCallIndication in the property */
    vpostindication.inst = ipost;
    vpreindication.inst = ipre;
    fprintf(stderr, "Set PreCall\n");
    CMSetProperty(imresult, "PreCallIndication", &vpreindication, CMPI_instance);
    fprintf(stderr, "Set PostCall\n");
    CMSetProperty(imresult, "PostCallIndication", &vpostindication, CMPI_instance);
 
    fprintf(stderr, "TST finished\n");
    return imresult;
}


static CMPIStatus TST_MethodResultEnumInstances(
        CMPIInstanceMI * self,
        const CMPIContext * ctx,
        const CMPIResult * rslt,
        const CMPIObjectPath * op,
        const char ** properties)
{
    CMPIStatus status = {CMPI_RC_OK, NULL};

    _CMPI_TRACE(1, ("TST_MethodResultEnumInstances() called, ctx %p, rslt %p,"
                " op %p, properties %p", ctx, rslt, op, properties));


    CMReturnInstance(rslt, get_instance(_broker, ctx, op));
    CMReturnDone(rslt);


    status.rc = CMPI_RC_OK;
    status.msg = NULL;

    _CMPI_TRACE(1, ("TST_MethodResultEnumInstances() %s",
          (status.rc == CMPI_RC_OK)? "succeeded":"failed"));
    return status;
}

static CMPIStatus TST_MethodResultGetInstance(
        CMPIInstanceMI * self,
        const CMPIContext * ctx,
        const CMPIResult * rslt,
        const CMPIObjectPath * op,
        const char ** properties)
{
    CMPIStatus status = {CMPI_RC_OK, NULL};

    _CMPI_TRACE(1, ("TST_MethodResultGetInstance() called, ctx %p, rslt %p,"
        " op %p, properties %p", ctx, rslt, op, properties));

    CMReturnInstance(rslt, get_instance(_broker, ctx, op));
    CMReturnDone(rslt);

    status.rc = CMPI_RC_OK;
    status.msg = NULL;

    _CMPI_TRACE(1, ("TST_MethodResultGetInstance() %s",
         (status.rc == CMPI_RC_OK)? "succeeded":"failed"));
    return status;
}

static CMPIStatus TST_MethodResultCreateInstance(
        CMPIInstanceMI * self,
        const CMPIContext * ctx,
        const CMPIResult * rslt,
        const CMPIObjectPath * op,
        const CMPIInstance * inst)
{
    CMPIStatus status = {CMPI_RC_ERR_NOT_SUPPORTED, NULL};

    _CMPI_TRACE(1, ("TST_MethodResultCreateInstance() called, ctx %p, rslt %p,"
        " op %p, inst %p", ctx, rslt, op, inst));
    _CMPI_TRACE(1, ("TST_MethodResultCreateInstance() %s",
        (status.rc == CMPI_RC_OK) ? "succeeded":"failed"));
    return status;
}


// ----------------------------------------------------------------------------

#ifdef CMPI_VER_100
#define TST_MethodResultSetInstance TST_MethodResultModifyInstance
#endif

static CMPIStatus TST_MethodResultSetInstance(
        CMPIInstanceMI * self,
        const CMPIContext * ctx,
        const CMPIResult * rslt,
        const CMPIObjectPath * op,
        const CMPIInstance * inst,
        const char ** properties)
{
    CMPIStatus status = {CMPI_RC_ERR_NOT_SUPPORTED, NULL};

    _CMPI_TRACE(1, ("TST_MethodResultSetInstance() called, ctx %p, rslt %p,"
        " op %p, inst %p, properties %p", ctx, rslt, op, inst, properties));
    _CMPI_TRACE(1, ("TST_MethodResultSetInstance() %s",
        (status.rc == CMPI_RC_OK)? "succeeded":"failed"));
    return status;
}

// ----------------------------------------------------------------------------


/* DeleteInstance() - delete/remove the specified instance. */
static CMPIStatus TST_MethodResultDeleteInstance(
        CMPIInstanceMI * self,
        const CMPIContext * ctx,
        const CMPIResult * rslt,
        const CMPIObjectPath * op)
{
    CMPIStatus status = {CMPI_RC_ERR_NOT_SUPPORTED, NULL};

    _CMPI_TRACE(1, ("TST_MethodResultDeleteInstance() called, ctx %p, rslt %p,"
        " op %p", ctx, rslt, op));
    _CMPI_TRACE(1, ("TST_MethodResultDeleteInstance() %s",
        (status.rc == CMPI_RC_OK)? "succeeded":"failed"));
    return status;
}

// ----------------------------------------------------------------------------


static CMPIStatus TST_MethodResultExecQuery(
        CMPIInstanceMI * self,
        const CMPIContext * ctx,
        const CMPIResult * rslt,
        const CMPIObjectPath * op,
        const char * query,
        const char * lang)
{
    /* Return status of CIM operations. */
    CMPIStatus status = {CMPI_RC_ERR_NOT_SUPPORTED, NULL};

    _CMPI_TRACE(1, ("TST_MethodResultExecQuery() called, ctx %p, rslt %p, op %p,"
        " query %s, lang %s", ctx, rslt, op, query, lang));
    _CMPI_TRACE(1, ("TST_MethodResultExecQuery() %s",
        (status.rc == CMPI_RC_OK)? "succeeded":"failed"));
    return status;
}

//  associatorMIFT
//

CMPIStatus TST_MethodResultAssociatorNames(
        CMPIAssociationMI* self,
        const CMPIContext* ctx,
        const CMPIResult* rslt,
        const CMPIObjectPath* op,
        const char* assocClass,
        const char* resultClass,
        const char* role,
        const char* resultRole)
{
         CMPIStatus status = {CMPI_RC_ERR_NOT_SUPPORTED, NULL};

    _CMPI_TRACE(1, ("associatorNames() called, ctx %p, rslt %p, op %p,"
        " assocClass %s, resultClass %s, role %s, resultRole %s",
        ctx, rslt, op, assocClass, resultClass, role, resultRole));

    _CMPI_TRACE(1, ("associatorNames() %s",
        (status.rc == CMPI_RC_OK)? "succeeded":"failed"));
    return status;
}

/***************************************************************************/
CMPIStatus TST_MethodResultAssociators(
        CMPIAssociationMI* self,
        const CMPIContext* ctx,
        const CMPIResult* rslt,
        const CMPIObjectPath* op,
        const char* assocClass,
        const char* resultClass,
        const char* role,
        const char* resultRole,
        const char** properties)
{
     CMPIStatus status = {CMPI_RC_ERR_NOT_SUPPORTED, NULL};

     _CMPI_TRACE(1, ("associators() called, ctx %p, rslt %p, op %p,"
         " assocClass %s, resultClass %s, role %s, resultRole %s",
         ctx, rslt, op, assocClass, resultClass, role, resultRole));

    _CMPI_TRACE(1, ("associators() %s",
         (status.rc == CMPI_RC_OK)? "succeeded":"failed"));
    return status;
}

/***************************************************************************/
CMPIStatus TST_MethodResultReferenceNames(
        CMPIAssociationMI* self,
        const CMPIContext* ctx,
        const CMPIResult* rslt,
        const CMPIObjectPath* op,
        const char* resultClass,
        const char* role)
{
    CMPIStatus status = {CMPI_RC_ERR_NOT_SUPPORTED, NULL};

    _CMPI_TRACE(1, ("referenceNames() called, ctx %p, rslt %p, op %p,"
        " resultClass %s, role %s", ctx, rslt, op, resultClass, role));

    _CMPI_TRACE(1, ("referenceNames() %s",
        (status.rc == CMPI_RC_OK)? "succeeded":"failed"));
    return status;
}


/***************************************************************************/
CMPIStatus TST_MethodResultReferences(
        CMPIAssociationMI* self,
        const CMPIContext* ctx,
        const CMPIResult* rslt,
        const CMPIObjectPath* op,
        const char* resultClass,
        const char* role,
        const char** properties)
{
    CMPIStatus status = {CMPI_RC_ERR_NOT_SUPPORTED, NULL};

    _CMPI_TRACE(1, ("references() called, ctx %p, rslt %p, op %p,"
            " resultClass %s, role %s, properties %p",
            ctx, rslt, op, resultClass, role, properties));

    _CMPI_TRACE(1, ("references() %s",
        (status.rc == CMPI_RC_OK)? "succeeded":"failed"));
    return status;
}

static void print_instance(CMPIInstance *inst, int indent)
{
    int i, j;
    CMPIStatus st;
    CMPIData p;
    CMPIString *str;
    CMPIObjectPath *path;

    if (inst == NULL) {
        for (j=0; j<indent; j++) fprintf(stderr, " ");
        fprintf(stderr, "(NULL)\n");
        return;
    }

    path = inst->ft->getObjectPath(inst, &st);
    str = path->ft->getClassName(path, &st);
    for (j=0; j<indent; j++) fprintf(stderr, " ");
    fprintf(stderr, "class: %s\n", CMGetCharPtr(str));
 
    for (i=0; i<inst->ft->getPropertyCount(inst, &st); i++) {
        p = inst->ft->getPropertyAt(inst, i, &str, &st);
        for (j=0; j<indent; j++) fprintf(stderr, " ");
        fprintf(stderr, "Property: %s\n", CMGetCharPtr(str));
        if (p.type == CMPI_instance)
            print_instance(p.value.inst, indent + 4);
        if (p.type == (CMPI_instance | CMPI_ARRAY)){
            CMPIArray *a = p.value.array;
            int k, siz;
            if (!a) {
                for (j=0; j<indent+4; j++) fprintf(stderr, " ");
                fprintf(stderr, "(empty array)\n");
                continue;
            }
            siz = a->ft->getSize(a, &st);
            for (j=0; j<indent+4; j++) fprintf(stderr, " ");
            fprintf(stderr, "array %d{\n", siz);
            for (k=0; k<siz; k++){
                CMPIData q = a->ft->getElementAt(a, k, &st);
                print_instance(q.value.inst, indent+8);
            }
            for (j=0; j<indent+4; j++) fprintf(stderr, " ");
            fprintf(stderr, "} array\n");
        }
    }

}

static void get_inst(const CMPIObjectPath *op, const CMPIContext *ctx, const char* classname)
{
    CMPIStatus status = {CMPI_RC_OK, NULL};
    CMPIObjectPath *path;
    CMPIInstance *inst;
    CMPIString *ns;
    CMPIValue vid;

    ns=CMGetNameSpace(op, &status);
    path = CMNewObjectPath(_broker, CMGetCharPtr(ns), classname, &status);
    vid.string = CMNewString(_broker, "TestInstanceID", &status);
    CMAddKey(path, "InstanceID", &vid, CMPI_string);
  
    /* call GetInstance */
    inst = CBGetInstance(_broker, ctx, path, NULL, &status);
    print_instance(inst, 4);

 }

/***************************************************************************/
CMPIStatus TST_MethodResultInvokeMethod(
        CMPIMethodMI* self,
        const CMPIContext* ctx,
        const CMPIResult* rslt,
        const CMPIObjectPath* op,
        const char* method,
        const CMPIArgs* in,
        CMPIArgs* out)
{
    CMPIStatus status = {CMPI_RC_OK, NULL};


    get_inst(op, ctx, "TST_MethodResult");
   _CMPI_TRACE(1, ("invokeMethod() %s",
        (status.rc == CMPI_RC_OK)? "succeeded":"failed"));
    return status;
}

/***************************************************************************/


CMMethodMIStub( TST_MethodResult, TST_MethodResult, _broker, CMNoHook);
CMInstanceMIStub( TST_MethodResult, TST_MethodResult, _broker, CMNoHook);
//CMAssociationMIStub( TST_MethodResult, TST_MethodResult, _broker, CMNoHook);

Inter provider communication

Anuj Jain — 2013-03-31T18:16:07

Hi,
Is there support for inter-provider communication in Pegasus? Can one
provider send a WBEM request to another provider? I understand that this
can be achieved by creating a CIMClient and sending a request to localhost,
but is there a better way to communicate back with the CIMOM from the
provider to request this?
Thanks
Anuj

OpenPegasus version 2.12.1 Release Notice

Karl Schopmeyer — 2013-03-28T01:44:22

OpenPegasus 2.12.1 has been released.  Source tarball/zip and  source 
rpm are available on the OpenPegasus web site 
(www.openpegasus.org).  The source can be retrieved from OpenPegasus 
CVS with the tag RELEASE_2_12_1.

Information on the release is available in the Release notes in the 
root of the source tree.

Karl


Karl Schopmeyer                   Inova Development Inc.
305 Spring Creek Village, Suite 475 -  Dallas TX, 75248 USA
EMAIL: k.schopmeyer< at >swbell.net       FAX: 1-972-239-0326
Phone 1-972-814-5581
Skype: kschopmeyer         Skype Phone: (214) 556-5971

CIMOM refuses EmbeddedObject with unknown class

Andreas Maier — 2013-03-21T12:39:06

Jan:


I can see your point, but I would not worry too much about it
and simply interpret this as "including subclasses". I believe
that is the intent (at least it would make sense), and I think
the text there is simply flawed. We will discuss that as well
in the DMTF Arch WG.

Andy

Andreas Maier
IBM Senior Technical Staff Member, Systems Management Architecture & Design
IBM Research & Development Laboratory Boeblingen, Germany
maiera< at >de.ibm.com, +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

CIMOM refuses EmbeddedObject with unknown class

Andreas Maier — 2013-03-20T19:12:30

Johnny,
I think your idea is interesting.

Let me make it more concrete (and modify it a bit): The classes that have
the dynamic set of properties are __MethodParameters, __JobInParameters and
__JobOutParameters, so these would be defined as empty top-level classes,
and they would have one subclass for each extrinsic method that needs Job
Control support. The parameters of these methods will determine the set of
properties in these subclasses. These three top-level classes would be
defined with the Indication qualifier (to allow them having embedded
instances but no keys), and thus they would not inherit from
CIM_ManagedElement (which is only the mother of all non-association and
non-indication classes, and that is not a requirement but just the current
convention in the CIM Schema).

The potential caveat with the idea is whether or not these method-specific
subclasses prevent an implementation of the Job Control Profile that is
stands on its own, independent of these methods.

Jan,
is this something you could try out ?

Regarding the potential caveat: Did you envision an implementation of the
JCP that is independent of the methods that need Job Control support, and
would this approach prevent such an implementation?

Example MOF:

Top level classes:

       [Abstract, Indication, Version("2.36.0")]
   class __MethodParameters {
   };

       [Abstract, Indication, Version("2.36.0")]
   class __JobInParameters {
   };

       [Abstract, Indication, Version("2.36.0")]
   class __JobOutParameters {
   };

Example method (from CIM_EnabledLogicalElement):

       [ValueMap { ... }, Values { ... }]
   uint32 RequestStateChange (

           [In, ValueMap { ... }, Values { ... }]
       uint16 RequestedState,

           [In(false), Out]
       CIM_ConcreteJob REF Job,

           [In]
       datetime TimeoutPeriod);

Example subclasses for this method:

       [Indication, Version("2.36.0")]
   class CIM_RequestStateChangeMethodParameters : __MethodParameters {

           [ValueMap { ... }, Values { ... }]
       uint16 RequestedState;

       // probably leaving out CIM_ConcreteJob REF Job

       datetime TimeoutPeriod;
   };


       [Indication, Version("2.36.0")]
   class CIM_RequestStateChangeJobInParameters : __JobInParameters {

           [ValueMap { ... }, Values { ... }]
       uint16 RequestedState;

       datetime TimeoutPeriod;
   };


       [Indication, Version("2.36.0")]
   class CIM_RequestStateChangeJobOutParameters : __JobOutParameters {

           [ValueMap { ... }, Values { ... }]
       uint32 __ReturnValue;   // this name is required, see
   CIM_ConcreteJob

       // probably leaving out CIM_ConcreteJob REF Job
   };


Andy

Andreas Maier
IBM Senior Technical Staff Member, Systems Management Architecture & Design
IBM Research & Development Laboratory Boeblingen, Germany
maiera< at >de.ibm.com, +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 19:35 -----

From:"Hwang, Johnny" <Johnny.Hwang< at >netapp.com>
To:Andreas Maier/Germany/IBM< at >IBMDE, Marek
            Szermutzky/Germany/IBM< at >IBMDE, Kirk Augustin
            <kirk_augustin< at >yahoo.com>,
Cc:Jan Safranek <jsafrane< at >redhat.com>, "pegasus-l< at >openpegasus.org"
            <pegasus-l< at >openpegasus.org>, Robert
            Kieninger/Germany/IBM< at >IBMDE, Vitezslav Crhonek
            <vcrhonek< at >redhat.com>, Karl Schopmeyer
            <k.schopmeyer< at >swbell.net>
Date:2013-03-20 19:12
Subject: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" <MAIERA< at >de.ibm.com> wrote:

"pegasus-l< at >openpegasus.org"

CIMOM refuses EmbeddedObject with unknown class

Andreas Maier — 2013-03-20T18:03:17

< at >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.

< at >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
maiera< at >de.ibm.com, +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 <kirk_augustin< at >yahoo.com>
To:Marek Szermutzky/Germany/IBM< at >IBMDE, Andreas
            Maier/Germany/IBM< at >IBMDE,
Cc:Jan Safranek <jsafrane< at >redhat.com>, "pegasus-l< at >openpegasus.org"
            <pegasus-l< at >openpegasus.org>, Robert
            Kieninger/Germany/IBM< at >IBMDE, Vitezslav Crhonek
            <vcrhonek< at >redhat.com>
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 <MSzermutzky< at >de.ibm.com>
To: Andreas Maier <MAIERA< at >de.ibm.com>
Cc: Jan Safranek <jsafrane< at >redhat.com>; "pegasus-l< at >openpegasus.org"
<pegasus-l< at >openpegasus.org>; Robert Kieninger <KIENINGR< at >de.ibm.com>;
Vitezslav Crhonek <vcrhonek< at >redhat.com>
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: mszermutzky< at >de.ibm.com
-------------------------------------------------------------------------------------------------------------------------------------------

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< at >IBMDE, Jan Safranek
<jsafrane< at >redhat.com>
Cc:        Vitezslav Crhonek <vcrhonek< at >redhat.com>,
pegasus-l< at >openpegasus.org <pegasus-l< at >openpegasus.org>, Robert
Kieninger/Germany/IBM< at >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
maiera< at >de.ibm.com, +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 <jsafrane< at >redhat.com>
Cc:        Vitezslav Crhonek <vcrhonek< at >redhat.com>, Andreas
Maier/Germany/IBM< at >IBMDE, pegasus-l< at >openpegasus.org
<pegasus-l< at >openpegasus.org>, Robert Kieninger/Germany/IBM< at >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: mszermutzky< at >de.ibm.com
-------------------------------------------------------------------------------------------------------------------------------------------

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 <jsafrane< at >redhat.com>
To:        pegasus-l< at >openpegasus.org
Cc:        Vitezslav Crhonek <vcrhonek< at >redhat.com>
Date:        13.03.2013 10:22
Subject:        Re: CIMOM refuses EmbeddedObject with unknown class



On 03/13/2013 09:22 AM, Jan Safranek wrote:
PostCallIndication.

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

CIMOM refuses EmbeddedObject with unknown class

Andreas Maier — 2013-03-19T21:26:38

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
maiera< at >de.ibm.com, +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 <jsafrane< at >redhat.com>
Cc:Vitezslav Crhonek <vcrhonek< at >redhat.com>, Andreas
            Maier/Germany/IBM< at >IBMDE, pegasus-l< at >openpegasus.org
            <pegasus-l< at >openpegasus.org>, Robert Kieninger/Germany/IBM< at >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: mszermutzky< at >de.ibm.com
-------------------------------------------------------------------------------------------------------------------------------------------

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 <jsafrane< at >redhat.com>
To:pegasus-l< at >openpegasus.org
Cc:Vitezslav Crhonek <vcrhonek< at >redhat.com>
Date:13.03.2013 10:22
Subject:Re: CIMOM refuses EmbeddedObject with unknown class



On 03/13/2013 09:22 AM, Jan Safranek wrote:
PostCallIndication.

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

CIMOM refuses EmbeddedObject with unknown class

Jan Safranek — 2013-03-13T08:22:48

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.

Problem is that "__MethodParameters" is not registered class and Pegasus
does not like it. Would it be possible not to check the class name for
EmbeddedObjects returned from providers? DMTF defined some
EmbeddedObject properties with undefined classes, in addition to
CIM_InstMethodCall.MethodParameters also e.g.
CIM_ConcreteJob.JobInParameters.

Jan

Static indication filters

Jan Safranek — 2013-03-13T08:28:56

Hello,

I'm writing a set of providers which have very limited indication
support. Therefore I want to provider only static set of indication
filters, which will cover all the indication my providers are able to serve.

Now the question is, how to make these filters visible to applications?
If I add instances to root/PG_Interop:CIM_IndicationFilter, anybody can
modify or delete them. But I'd like to have them read-only. I tried to
subclass CIM_IndicationFilter and create a provider which would provide
just these static filters, but then I am not able to create subscription
- it accepts only CIM_IndicationFilter as Filter property.

Is there any other way how to make my indication filters static, i.e.
read-only?

Thanks in advance

Jan

Link to CIM-RS standards

Andreas Maier — 2013-03-07T10:44:11

Hi,
based upon recent postings on CIM-RS, I'd like to make sure everyone in the
greater OpenPegasus team understands that the standard version of CIM-RS is
different from the informational version released two years ago (document
numbers DSP-ISxxxx).

Here are the links to the documents for the standard version of CIM-RS:

DSP2032 V1.0.0 CIM-RS White Paper
http://www.dmtf.org/sites/default/files/standards/documents/DSP2032_1.0.0.pdf
- provides an overview

DSP0210 V1.0.0  CIM-RS Protocol
http://www.dmtf.org/sites/default/files/standards/documents/DSP0210_1.0.0.pdf
- payload-independent definition of the protocol

DSP0211 V1.0.0  CIM-RS Payload Representation in JSON
http://www.dmtf.org/sites/default/files/standards/documents/DSP0211_1.0.0.pdf
- payload definition for JSON

At this point, there is no XML-based payload definition for CIM-RS, and the
CIM-RS WG has decided that for the time being (i.e. until there are
requirements surfaced) the group will not work on one.

If there are any questions on CIM-RS, please post them on one of the
OpenPegasus mailing lists (or on the DMTF CIM-RS WG list, if you are a
member of the WG), you can also send mail directly to me or Marek.

Andy

Andreas Maier
IBM Senior Technical Staff Member, Systems Management Architecture & Design
IBM Research & Development Laboratory Boeblingen, Germany
maiera< at >de.ibm.com, +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