[Libvirt-cim] [PATCH 2 of 2] Adoption of changes in RegisteredProfile to association ElementConformsToProfile; ECTP uses upcalls to retrieve ManagedElements and minor bug fixes

[Jay Gagnon]

Heidi Eckhart wrote:
> Jay Gagnon wrote:
>> I'm good with most of this, although a little confused about one
>> thing. I've had the wrong idea about how ECTP was supposed to work in
>> the past,
>> so I wouldn't be surprised if I'm just confused again, but I'm afraid I
>> don't understand why you changed the prof_to_elem behavior.  I had it so
>> that we would return an essentially empty instance of the provider that
>> matched that profile, as I thought the idea was that the client would
>> check the CreationClassName and know that this provider implements the
>> profile they wanted.  You appear to be finding the appropriate provider
>> and invoking its EnumInstances method.  I'm not sure why.  Also, won't
>> this present a problem for profiles that don't have EnumInstances?
>>   
> The DMTF specification defines the following behavior for ECTP, if
> traversed from an instance of RegisteredProfile to the instance(s) of
> the profile's scoping class. The result of this request is the list of
> all instances of the scoping class - which means an EnumInstances on
> the scoping class. So using an upcall to the EnumInstances function of
> the scoping class enables a generic implementation of the ECTP
> provider. What you have been talking about is client logic - but its
> definitely not the clients responsibility to select the appropriate
> instances of the profile's scoping class. This knowledge is anchored
> in the ECTP association.
> A scoping class always needs to implemented the EnumInstances
> function. And if there should once be the case that this did not
> happen then this is either a bug in the specification or in the code ;).
>
Understood.  That's fine.  My tendency to think like a client seems to
have bitten me again.  :)

-- 

-Jay