Resource and Control Model

The goal of cobald is to simplify the provisioning of opportunistic resources. This is achieved with a composable model to define, aggregate, generalise and control resources. The cobald.interfaces codify this into a handful of primitive building blocks.

Pool and Control Model

The cobald model for controlling resources is built on four simple types of primitives. Two fundamental primitives represent the actual resources and the provisioning strategy:

  • The adapter handling concrete resources is a Pool. Each Pool merely communicates the total volume of resources and their overall fitness.

  • The decision to add or remove resources is made by a Controller. Each Controller only inspects the fitness of its Pools and adjusts their desired volume.

These two primitives are sufficient for direct control of simple resources. It is often feasible to control several pools of resources separately.

digraph graphname {
    graph [rankdir=LR, splines=lines, bgcolor="transparent"]
    labelloc = "b"
    controla, controlb [label=Controller]
    poola, poolb [label=Pool]
    subgraph cluster_0 {
        controla -> poola
        pencolor=transparent
        label = "Resource 1"
    }
    subgraph cluster_1 {
        controlb -> poolb
        pencolor=transparent
        label = "Resource 2"
    }
    poola -> controlb [style=invis]
}

Composition and Decoration

For complex tasks it may be necessary to combine resources or change their interaction and appearance.

  • The details of managing resources are encoded by Decorators. Each Decorator translates between the specific Pools and the generic Controllers.

  • The combination of several resources is made by CompositePools. Each CompositePool handles several Pools, but gives the outward appearance of a single Pool.

All four primitives can be combined to express even complex resource and control scenarios. However, there is always a Controller on one end and a Pool on the other. Since individual primitives can be combined and reused, new use cases require only a minimum of new implementations.

digraph graphname {
    graph [rankdir=LR, splines=lines, bgcolor="transparent"]
    labelloc = "b"
    controller [label=Controller]
    decoa, decob, decoc [label=Decorator]
    composite [label=Composite]
    poola, poolb [label=Pool]
    controller -> decoa -> composite
    composite -> decob -> poola
    composite -> decoc -> poolb
    pencolor=transparent
    label = "Resource 1 and 2"
}

Detail Descriptions