WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-cim

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

To: Jim Fehlig <jfehlig@xxxxxxxxxx>
Subject: Re: [Xen-cim] Re: Various implementation questions
From: Gareth S Bestor <bestor@xxxxxxxxxx>
Date: Fri, 14 Jul 2006 11:52:02 -0700
Cc: xen-cim@xxxxxxxxxxxxxxxxxxx
Delivery-date: Fri, 14 Jul 2006 11:52:22 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <44B7E023.7000104@xxxxxxxxxx>
List-help: <mailto:xen-cim-request@lists.xensource.com?subject=help>
List-id: xen-cim mailing list <xen-cim.lists.xensource.com>
List-post: <mailto:xen-cim@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-cim>, <mailto:xen-cim-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-cim>, <mailto:xen-cim-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-cim-bounces@xxxxxxxxxxxxxxxxxxx

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