Re: [Xen-cim] Re: Various implementation questions

[Gareth S Bestor <bestorga@xxxxxxxxxx>]

BTW - I found this good background info
about the cross-namespace issue. Worth reading.

        http://www.openpegasus.org/pp/uploads/40/4853/DMTF-Cross-Namespace-Associations.pdf

As we talked about on the call this
morning, I think I'd suggest we proceed with registering the necessary
association providers (and classes?) in *both* namespaces. Realistically,
what namespace we - ie Xen CIM - lives in is largely dictated by the DMTF
System Virt Profile, since this is the 'bible' that the CIM client will
follow/live by. And for now that's root/cimv2. So I think we need to plan
on having to deal with CIM objects coming from two namespaces, and try
to do so as best we can till this cross-namespace problem is more formally
solved at the CIM Schema/DMTF level (ie the messy details that can result
from having the assoc provider live in two places, exposing a namespace
back to a CIM client that might not have even been aware such a namespace
existed, ...)

FYI - from the latest DMTF Profile Reg
Profile (06/07/2006):

7.3 Cross Namespace Associations

Associations that cross namespaces
shall be instantiated in both namespaces. The rationale for this is to

support association traversal from
either namespace back to the other. In order to be able to traverse an

association that spans 2 namespaces
from either namespace, an instance of the association must be 
instantiated in both namespaces.

I'll followup with Andy Maier to see
what the latest is here.

- Gareth

Jim Fehlig <jfehlig@xxxxxxxxxx>
Sent by: xen-cim-bounces@xxxxxxxxxxxxxxxxxxx

07/13/2006 02:21 PM

To	Gareth S Bestor/Beaverton/IBM@IBMUS
cc	xen-cim@xxxxxxxxxxxxxxxxxxx
Subject	Re: [Xen-cim] Re: Various implementation questions

Gareth S Bestor wrote:
>
> We want to try to avoid any dependencies on specific non-System 
> Virtualization classnames, eg classes for host instrumentation, and
> instead rely on the more general CIM_* classnames/profiles. 
> Fortunately, since all the OMC SMASH providers will be located under
> the root/smash namespace, it should be a problem simply referring
to, 
> say,  root/smash/CIM_ComputerSystem, which should pull up any
> OMC_ComputerSystem subclass.

While playing with the implementation, found that going from smash 
namespace to root/cimv2 (our current namespace) was not possible.  cimom
does not know about our schema in smash namespace.  So for example
asking for objects associated with CIM_CS in smash namespace via 
association Xen_HostedComputerSystem is invalid since no such 
association exists in smash namespace.  One possible solution of course
is to put our schema in smash namespace.  One of the smash developers
has some ideas, but won't have time to talk with him before our morning
call.

Related, in what namespace do we want to live?  I assume any, i.e.
work 
wherever an admin might place our schema.

> As an initial pass, where all the relevant host resources are 
> automatically considered part of the respective resource pool, there
> wont be any need to persist anything, since the associations can be
> (re)generated on the fly. Once we more fully support pool management
> adding/removing host resources then yes, we'll have to persist which
> resource are and are not currently in the various pools somewhere.
I 
> suppose persiting the association object itself in the CIMOM 
> repository wold do the trick, but for some reason this makes me 
> uneasy... I'd need to think thru the implications and consequences
> more :-)

Right.  The notion of a primordial pool containing all of the host
resources for a given resource type.

>  
> >BTW, there is a lot off association traversal in resource pool
> >implementations.
>
> Depends. If the pool provider takes the 'easy' approach and exploits
> traversing the CIM associations itself (ie making the associatio 
> provider do the hard work) and sum everything up, then yes, there
> could be a lot of association upcalls to handle. But depending on
how 
> pool membership is persisted, theres nothing to prevent a smarter
pool 
> resource provider extracting the necessary raw data more efficiently.
> Really depends on how pool membership is persisted at the back end.

Yep.  And given a first implementation that uses primordial pools,
the 
'easy' approach will be used here as well :-).  Will have to revisit
when supporting fancier pool management.

Jim


_______________________________________________
Xen-cim mailing list
Xen-cim@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-cim

_______________________________________________
Xen-cim mailing list
Xen-cim@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-cim