|
|
|
|
|
|
|
|
|
|
xen-cim
Re: [Xen-cim] Re: Various implementation questions
Right now the provider-register script
doesnt support specifying multiple namespaces, though it may well be possible
to add a second line for each relevant class with a different namespace.
I haven't ever tried this myself yet, but I dont think there is anything
in the script to prevent it, since it processes each line independently.
>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 :-(.
Yup. That's some of the messy details
that need to be worked out. eg if you try to register an association
provider in, say, the SMASH namespace, then in addition to the assoc class,
you also have to make sure that both the association endpoint classes are
also registered to that class (even though you may never start an association
traversal from one of the endpoints). Otherwise the CIMOM repository class
registration will most likely fail when it does its class checks. And I
dont expect this (conservative) check is something that can be turned off...
- Gareth
Dr. Gareth S. Bestor
IBM Linux Technology Center
M/S DES2-01
15300 SW Koll Parkway, Beaverton, OR 97006
503-578-3186, T/L 775-3186, Fax 503-578-3186
Jim Fehlig <jfehlig@xxxxxxxxxx>
Sent by: xen-cim-bounces@xxxxxxxxxxxxxxxxxxx
07/14/2006 11:19 AM
|
To
| Gareth S Bestor/Poughkeepsie/IBM@IBMUS
|
cc
| xen-cim@xxxxxxxxxxxxxxxxxxx
|
Subject
| 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
_______________________________________________
Xen-cim mailing list
Xen-cim@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-cim
|
|
|
|
|