[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.