|  |  | 
  
    |  |  | 
 
  |   |  | 
  
    |  |  | 
  
    |  |  | 
  
    |   xen-cim
Re: [Xen-cim] Re: Various implementation questions 
| 
Gareth S Bestor wrote:
 
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
 
Cool.  Appears this issue has quite a few issues :-).
 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, ...)
 
As far as registering providers go, there is nothing to do for 
openwbem.  The .registration files (not used by openwbem) contain 
namespace info.  Can multiple be specified? 
Classes must be registered, i.e. our pertinent schema imported into 
smash namespace.  I have done this with Xen_HostedComputerSystem but 
found that I also need to put Xen_ComputerSystem in smash as well since 
it is the type of the Dependent property :-(.  And then 
Xen_ComputerSystems exit is smash so association provider still has to 
filter :-(. 
Cross-namespace certainly needs some work at DMTF level.
Jim
_______________________________________________
Xen-cim mailing list
Xen-cim@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-cim
 | 
 |  | 
  
    |  |  |