Dan Smith wrote:
KR> Just a nit-picky thing here... why not call the AllocCapabilities KR> function that setups the instance? I think using the same KR> InstanceID for the AllocCapa as the pool might not always return KR> the correct instance because AllocCapa uses <pool type>/0 as the KR> InstanceID. But something like the NetworkingPool returns KR> "NetworkPool/xenbr0". So you'll be creating an instance with KR> "NetworkPool/xenbr0" as the InstanceID, which would conflict with KR> what EnumInstances from AllocCapa would return.
I think AllocationCapabilities needs to change here. It think using the InstanceID from the pool makes the most sense. I'm not sure what the existing AllocationCapabilities stuff intended, but I'm assuming it will need to change to match this new stuff. Perhaps it was a hold-over from the days of one-pool-per-resource-type?
Good catch, by the way :)
Just to be clear, copying InstanceID from the instance of ResourcePool to the instance of AllocationCapabilities is okay, but I need to change the AllocationCapabilities provider? That doesn't much surprise me; the AllocationCapabilities provider itself only exists so I could register it as a class; I'm honestly not even sure what it's supposed to do on its own . Reading through the entire Allocation Capabilities Profile (DSP1043) provides no insight into what get/enumerateInstance(s) would do. Reasonable detail is given about how it should be connected to things via associations, but there isn't much concept of a standalone instance. -- -Jay