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

[Jim Fehlig <jfehlig@xxxxxxxxxx>]

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