Re: [Xen-cim] Allocation Capabilities big picture

[Gareth S Bestor <bestor@xxxxxxxxxx>]

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

"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

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