Lifecycle and ManagementContext

Under-the-covers, at heart of the brooklyn management plane is the ManagementContext. This is started automatically when launching an application using the brooklyn CLI. For programmatic use, see BrooklynLauncher.newLauncher().launch().

A Brooklyn deployment consists of many entities in a hierarchical tree, with the privileged application entity at the top level.

An application entity (Application class) is responsible for starting the deployment of all its child entities (i.e. the entire entity tree under its ownership).

An Application's start() method begins provisioning the child entities of the application (and their entities, recursively).

Provisioning of entities typically happens in parallel automatically, although this can be customized. This is implemented as tasks which are tracked by the management plane and is accessible in the web-based management console and REST API.

Customized provisioning can be useful where two starting entities depend on each other. For example, it is often necessary to delay start of one entity until another entity reaches a certain state, and to supply run-time information about the latter to the former.

When new entities are created, the entity is wired up to an application by giving it a parent. The entity is then explicitly "managed", which allows other entities to discover it.

Typically a Brooklyn deployment has a single management context which records:

• all entities under management that are reachable by the application(s) via the parent-child relationships,
• the state associated with each entity,
• subscribers (listeners) to sensor events arising from the entities,
• active tasks (jobs) associated with the entity,
• which Brooklyn management node is mastering (managing) each entity.

In a multi-location deployment, management operates in all regions, with brooklyn entity instances being mastered in the relevant region.