Re: CIMOM refuses EmbeddedObject with unknown class

Jan Safranek <[email protected]> Thu, 14 Mar 2013 09:46:24 +0100
Newsgroups gmane.network.open-pegasus.general
Message-ID <[email protected]>
Hello,

thanks for the explanation and design background. I do not like
'__MethodParmeters' either, it does not fit CIM well...

> 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

This looks fine for me.

> 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) ?

If there patch/code is ready earlier and I can test my code with it to
be sure that OpenPegasus 2.13 works well, even mid of July is fine. Of
course, earlier is better :).

The job profile allows that any modified/created element is associated
with the finished job using CIM_AffectedJobElement association, so I can
use it as the 'output' parameter on application side for now.

We at Red Hat started new open source project to add several providers
we think that are missing, see openlmi.org. I'm writing the storage
part, inspired by SMI-S, and it's full of asynchronous jobs - typically,
filesystem creation can take quite lot of time. The storage provider is
in Python, its job implementation can be reused, so far it is tailored
to our needs (patches are welcome!) We might do also plain C
implementation of the jobs when we see it's necessary.


Jan