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] Allocation Capabilities big picture

To: "Szymanski, Lukasz K" <Lukasz.Szymanski@xxxxxxxxxx>
Subject: Re: [Xen-cim] Allocation Capabilities big picture
From: Gareth S Bestor <bestor@xxxxxxxxxx>
Date: Wed, 1 Nov 2006 20:31:53 -0800
Cc: xen-cim@xxxxxxxxxxxxxxxxxxx, xen-cim-bounces@xxxxxxxxxxxxxxxxxxx
Delivery-date: Thu, 02 Nov 2006 13:45:45 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <94C8C9E8B25F564F95185BDA64AB05F6045A6F38@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
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

Making a Xen-specific subclass for every DMTF SV association for every resource type is always an option; you are basically trading off having a large number of simpler assoc providers that expose just one particular 'flavor' of association, against a smaller number of more complex assoc providers that expose associations for a number of different resources. In some cases I did the former in the original IBM providers - eg each ElementSettingData from a particular resource type to its RASD was done in a different provider - and in some cases I used a single provider for multiple somewhat different associations - eg the different flavors of min/max/inc/default RASDs per ResourcePool are all exposed via the same assoc provider.

Its basically a judgement call at the end of the day. Typically, my rule of thumb is that if its not that much more effort to extend an (assoc) provider to expose multiple flavors of an assoc then I do it. But in other cases if trying to do so means you end up having pretty much duplicate but distinct per-flavor code sections in all the provider methods, then it makes sense just to use distinct providers and different subclasses.

Remember, you do not *have to* have resource type specific association providers, or instance providers for that matter, so long as you have a provider that exposes associations of the correct subclass as dictated by the DMTF Profile. eg you could conceivably have one instance provider that exposed *all* resource pools, however you'd probably end up having huge very resource-specific code sections doing so.

Another 'feature' of resource specific providers is that you have the potential to optimize a CIM client by tailoring it to call your specific provider subclasses; eg Xen_CSProcessor vs Xen_SystemDevice. Of course, the more you optimize a client to implementation specific classes, rather than using the DMTF prescribed superclass, the less useful your client is for managing other implementations of the profile... (aka there's no such thing as free beer :-)

- 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

Inactive hide details for "Szymanski, Lukasz K" <Lukasz.Szymanski@xxxxxxxxxx>"Szymanski, Lukasz K" <Lukasz.Szymanski@xxxxxxxxxx>


          "Szymanski, Lukasz K" <Lukasz.Szymanski@xxxxxxxxxx>
          Sent by: xen-cim-bounces@xxxxxxxxxxxxxxxxxxx

          11/01/06 02:07 PM


To

<xen-cim@xxxxxxxxxxxxxxxxxxx>

cc


Subject

[Xen-cim] Allocation Capabilities big picture

I am trying to think of the big picture wrt AllocationCapabilities. Looking at the Profile doc I see that there are 4 associations that connect AllocationCapabilites to other classes, those being: ComputerSystem, ResourcePool, CurrentRASD, RecordedRASD. Is there a need, therefore, for 4 associations (e.g. ComputerSystemToProcessorElementCapabilites, ResourcePoolToProcessorElementCapabilites, etc) ? Is there a better way of doing this?

BTW, this would hold true for each type of resource (proc, memory, network, disk). That's 4x4 new associations. That seems like a lot, but I am not sure how else to approach it.

I am thinking that in ProcessorAllocationCapabilites you would go through discovering the Allocation Capability with some case statement like this:

Case (From ResourcePool)
...
Case (From ComputerSystem)

Finally we need to associate the ProcessorAllocationCapability with ProcessorCapabiltiesSettingData (which is already done). The association would be called something like ProcessorSettingsDefineCapabilites.

I have some bits of this coded, but don't want to submit anything until I have a suitable chunk ready to go.

Suggestions? Comments?

Thanks,
Luke
_______________________________________________
Xen-cim mailing list
Xen-cim@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-cim

GIF image

_______________________________________________
Xen-cim mailing list
Xen-cim@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-cim
<Prev in Thread] Current Thread [Next in Thread>