1:11 p.m.
I've been looking at the Konkret doc and the various OpenLMI providers
and there seems to be an an inherent assumption that enumerateInstances
will be called exactly once. There are no checks to see if an instance
already exists during the enumeration. I went to the CMPI spec for a
clarification, except it had nothing to say about this (at least as far
I could find).
My naive assumption for a function with the verb Enumerate in it's name
followed by the noun Instance says you're suppose to return a list of
existing Instances, not create them. Also you might be asked to
enumerate those same Instances more than once (i.e. give me a list of
what you've got).
But it seems like the actual semantics are "create your initial set of
default instances and tell me what they are" Hence it has more to do
with creation than enumeration. Is this correct or do I have a
misunderstanding? Is this actually spelled out someplace? If so can you
point me at that doc?
Thanks,
John
--
John Dennis <jdennis(a)redhat.com>
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/
1:09 a.m.
* John Dennis <jdennis(a)redhat.com> [Feb 21. 2013 20:12]:
I've been looking at the Konkret doc and the various OpenLMI
providers and there seems to be an an inherent assumption that
enumerateInstances will be called exactly once.
Huh ?
There are no checks
to see if an instance already exists during the enumeration. I went
to the CMPI spec for a clarification, except it had nothing to say
about this (at least as far I could find).
Well, CMPI only describes the API between the CIMOM and the provider.
The CIM and WBEM standards from dmtf.org should be consulted here.
My naive assumption for a function with the verb Enumerate in it's
name followed by the noun Instance says you're suppose to return a
list of existing Instances, not create them.
Yes, in principle.
Sometimes its practicable to actually create instances in order to get
their properties and names right. [1]
Also you might be asked
to enumerate those same Instances more than once (i.e. give me a
list of what you've got).
Absolutely. EnumerateInstances should be idempotent.
But it seems like the actual semantics are "create your initial set
of default instances and tell me what they are" Hence it has more to
do with creation than enumeration. Is this correct or do I have a
misunderstanding? Is this actually spelled out someplace? If so can
you point me at that doc?
This is a misunderstanding. However some providers will actually
create instances on the initial call to enumerateInstances for
practical purposes as outlined above.
Hth,
Klaus
[1] http://martinfowler.com/bliki/TwoHardThings.html
--
SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG
Nürnberg)
Maxfeldstraße 5, 90409 Nürnberg, Germany
11:57 a.m.
On 02/22/2013 02:09 AM, Klaus Kaempf wrote:
* John Dennis <jdennis(a)redhat.com> [Feb 21. 2013 20:12]:
> I've been looking at the Konkret doc and the various OpenLMI
> providers and there seems to be an an inherent assumption that
> enumerateInstances will be called exactly once.
Huh ?
> There are no checks
> to see if an instance already exists during the enumeration. I went
> to the CMPI spec for a clarification, except it had nothing to say
> about this (at least as far I could find).
Well, CMPI only describes the API between the CIMOM and the provider.
The CIM and WBEM standards from dmtf.org should be consulted here.
>
> My naive assumption for a function with the verb Enumerate in it's
> name followed by the noun Instance says you're suppose to return a
> list of existing Instances, not create them.
Yes, in principle.
Sometimes its practicable to actually create instances in order to get
their properties and names right. [1]
> Also you might be asked
> to enumerate those same Instances more than once (i.e. give me a
> list of what you've got).
Absolutely. EnumerateInstances should be idempotent.
Thank you, that confirms what I had believed to be true.
>
> But it seems like the actual semantics are "create your initial set
> of default instances and tell me what they are" Hence it has more to
> do with creation than enumeration. Is this correct or do I have a
> misunderstanding? Is this actually spelled out someplace? If so can
> you point me at that doc?
This is a misunderstanding. However some providers will actually
create instances on the initial call to enumerateInstances for
practical purposes as outlined above.
Well, there in was part of my confusion because the examples I looked at
made no distinction as to whether this was an initial call to
enumerateInstances or not, they just blindly created class instances.
Part of my question is also directed toward "What is the life cycle of
these instances and who owns the instance? Is it the provider or does
the broker copy the returned instance? Jan Safranek in his reply
addresses some of these concerns so I will follow up in a bit more
detail in his reply.
Once again thank you.
--
John Dennis <jdennis(a)redhat.com>
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/
12:07 p.m.
* John Dennis <jdennis(a)redhat.com> [Feb 22. 2013 18:57]:
Well, there in was part of my confusion because the examples I
looked at made no distinction as to whether this was an initial call
to enumerateInstances or not, they just blindly created class
instances.
Well, the enumerateInstances function must create CMPIInstances and
set their properties in order to populate the CMPIEnumeration.
But these are just in-memory representations of whatever the provider
is supposed to model.
Klaus
--
SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG
Nürnberg)
Maxfeldstraße 5, 90409 Nürnberg, Germany
4:07 a.m.
On 02/21/2013 08:11 PM, John Dennis wrote:
I've been looking at the Konkret doc and the various OpenLMI
providers
and there seems to be an an inherent assumption that enumerateInstances
will be called exactly once. There are no checks to see if an instance
already exists during the enumeration. I went to the CMPI spec for a
clarification, except it had nothing to say about this (at least as far
I could find).
enumerateInstances will be called for every
EnumerateInstances/EnumerateInstanceNames request that CIMOM receives
from an remote application.
I think that the providers do not run in multiple threads, so there is
only one enumerateInstances() at a time, but I haven't checked that.
My naive assumption for a function with the verb Enumerate in
it's name
followed by the noun Instance says you're suppose to return a list of
existing Instances, not create them. Also you might be asked to
enumerate those same Instances more than once (i.e. give me a list of
what you've got).
Yes, exactly.
But it seems like the actual semantics are "create your initial
set of
default instances and tell me what they are" Hence it has more to do
with creation than enumeration. Is this correct or do I have a
misunderstanding? Is this actually spelled out someplace? If so can you
point me at that doc?
No, the point of CIM and CIMOM is that the instances live only in
providers. CIMOM asks you to enumerate them or get concrete instance,
but it does not keep any state, it just forwards requests from remote
applications to your provider and back.
Even in your provider the instances do not need to be 'alive'. When your
enumerateInstances() is called it's up to you where you get list of
instances from. For example, SBLIM has a provider to show list of
processes and it just executes 'ps -a', parses it and returns the
requested information to CIMOM. It does not keep any state, it parses
'ps -a' again in next enumerateInstances(). Of course, for hard-to-get
information, some caching in your provider is recommended - for storage,
we keep list of block devices and their properties in the provider to
speed things up.
Jan
4088
days inactive
4089
days old
openlmi-devel@lists.fedorahosted.org
4 comments
3 participants
participants (3)
-
Jan Safranek -
John Dennis -
Klaus Kaempf