Custom Pool Semantics

Adding new types of resources requires writing a new cobald.interfaces.Pool implementation. While adherence to the interface ensures compatibility, a custom Pool must also conform to some constraints for consistency.

Behaviour of Pool Implementations

The conventions on Pools are minimal, but their prevalence makes following them critical. Basically, the conventions are implied by the semantics of a Pool’s properties.

Responsiveness of Properties

The properties supply, demand, allocation, and utilisation should respond similar to regular attributes. Getting and setting properties should return quickly - avoid lengthy computations, queries and interactions with external processes. Never use locking for arbitrary times.

If you wish to represent external or complex state, buffer values and react to them or update them at regular intervals.

Ordering of Utilisation and Allocation

The model of allocation and utilisation assumes that only allocated resources can be utilised. As such, allocation should generally be greater than utilisation. Note that this is a loose assumption that is not enforced. Deviations due to precision or timing should not have a significant impact.

If you have use-cases where this assumption is not applicable, such as overbooking, you may want to write your own cobald.interfaces.Controller.

Common Utilisation and Allocation scenarios

Depending on the actual resources to manage, it might not be possible to accurately track allocation or utilisation. Furthermore, at times it is not desirable to use meaningless accuracy. This is why allocation and utilisation are purposely unrestrictive. The following illustrates several scenarios how to define the two consistently.

Multi-Dimensional Allocations

../../_images/pool_allocation_cpu_ram.png

Allocation of CPU and RAM