6. Overlay

The Troy Overlay...

class troy.overlay.PilotDescription(descr={})

Bases: troy.utils.properties.Properties

The PilotDescription class is a simple container for properties which describe a Pilot, i.e. a overlay element. PilotDescription`s are submitted to :class:`OverlayManager instances on add_pilot, and are internally used to create Pilot instances.

FIXME: description of supported properties goes here

class troy.overlay.Pilot(param, _overlay=None, _instance_type=None)

Bases: troy.utils.properties.Properties

cancel()

cancel the pilot

class troy.overlay.Overlay(descr={})

Bases: troy.utils.properties.Properties

The Overlay class represents a resource overlay which is managed by Troy, i.e. in application and user space. It contains a set of Pilots, which represent the resource capabilities of the overlay.

Overlay instances are owned by the OverlayManager class – only that class should change its composition and state (but Overlay may get created by the troy.Planner).

An overlay undergoes a series of transformations before being able to run workloads. Those transformations are orchestrated by the overlay manager. To support that orchestration, an overlay will be lockable, and it will have a state attribute. The valid states are listed below.

Internally, a overlay is represented by a set of troy.Pilot instances. As the overlay undergoes transformations, it is enriched by additional information, although those are kept solely within the Pilot instances – see there for more details.

The overlay transformations are:

• Scheduling: A overlay is mapped onto resourced.
• Dispatching: A scheduled overlay is provisioned to the respective resources.

An overlay can be in different states, depending on the transformations performed on it. Specifically, it can be in DESCRIBED, TRANSLATED, SCHEDULED, PROVISIONED, COMPLETED or FAILED.

A overlay enters the overlay manager in DESCRIBED state, and all follow-up state transitions are kept within the overlay manager.

Those states are ill defined in case of partial transformations – if, for example, a scheduling step may only schedule some of the pilots, but not others. As a general rule, a overlay will remain in a state until the transformation has been performed on all applicable overlay components (pilots).

Even on fully transformed overlay, the actual overlay state may not be trivial to determine – for example, a specific pilot may have failed, and my turn out to be impossible to re-run on its target resource, so it needs to be rescheduled to a different resource. Those feedback loops are considered out-of-scope for Troy at this point, so that state transitions are considered irreversible.

cancel()

cancel all pilots

lock()

locked()

unlock(*args)