Skip to content
Permalink
Browse files
Incorporate some feedback from Aled Sage
* configuration-sensor-effectors.md: reword for clarity
* lifecycle-managementcontext.md: Brooklyn does not support that feature
* execution.md: idem
* dependent-configuration.md: acknowledge the potential for deadlocks
* application-parent-membership.md: expand the example
  • Loading branch information
infrastation committed Sep 2, 2019
1 parent 11112d3 commit faf1ac9be629caae6aa1fe98c64059c12f8cf32e
Show file tree
Hide file tree
Showing 5 changed files with 19 additions and 9 deletions.
@@ -15,8 +15,17 @@ For example, an application may be the parent of a web cluster; that cluster in
In the management console, this is represented hierarchically in a tree view.

A parallel concept is that of ***membership***: in addition to one fixed parent,
and entity may be a ***member*** of any number of special entities called ***groups***.
an entity may be a ***member*** of zero or more ***groups*** (a "group" is a special kind of entity).
Membership of a group can be used for whatever purpose is required;
for example, it can be used to manage a collection of entities together for one purpose
(e.g. wide-area load-balancing between locations) even though they may have been
created by different parents (e.g. a multi-tier stack within a location).
it is commonly used to manage a collection of entities together for one purpose.

For example, a group could be used to indicate the targets for a load balancer, getting
the address of each. These targets do not need to have the same parent (e.g. the members
may have been deployed in different locations, where the 'parent' hierarchy mirrors the
different locations).

Another example would be deployment of a set of VMs where there is a "sidecar" logging
process on each VM. The parent hierarchy could be a top-level cluster with a child entity
per VM. Under each of these VM entities there could be two child entities for the two
processes. There could then be a "group" entity whose members were all the sidecar
logger entities.
@@ -27,9 +27,10 @@ in the entity's interface is the recommended mechanism for exposing configuratio

***Sensors*** (activity information and notifications) and ***effectors*** (operations that can be invoked on the entity) are defined by entities as static fields on the `Entity` subclass.

Sensors can be updated by the entity or associated tasks, and sensors from an entity can be subscribed to by its parent or other entities to track changes in an entity's activity.
Sensors can be updated by the entity or associated tasks – each update generates an event. An entity can subscribe to sensor events from itself or other entities.
A common pattern is for an entity to subscribe to its children (or for a group to subscribe to its members), to aggregate the sensor data and to respond to those events.

Effectors can be invoked by an entity's parent remotely, and the invoker is able to track the execution of that effector. Effectors can be invoked by other entities, but use this functionality with care to prevent too many managers!
Effectors can be invoked by an entity's parent, and the invoker is able to track the execution of that effector. Effectors can also be invoked by other entities, but use this functionality with care to prevent too many managers!

An entity consists of a Java interface (used when interacting with the entity) and a Java class. For resilience, it is recommended to store
the entity's state in attributes (see `getAttribute(AttributeKey)`). If internal fields are used then the data will be lost on brooklyn
@@ -28,4 +28,7 @@ Typically this does the right thing, blocking when necessary to generate the rig
without the developer having to think through the order, but it can take some getting used to.
Be careful not to request config information until really necessary (or to use non-blocking "raw" mechanisms),
and in complicated situations be ready to attend to circular dependencies.
Trying to resolve a circular dependency leads to a deadlock in those activities. The presence of such deadlocks can
be seen by viewing the web-console's 'activities' tab of the (hung) entities – it will show what the executing
activities are waiting for. Automated detection/alerting of deadlocks is currently not supported in Brooklyn.
The management console gives useful information for understanding what is happening and resolving the cycle.
@@ -7,7 +7,6 @@ All processing, whether an effector invocation or a policy cycle, are tracked as
* active and historic processing can be observed by operators
* the invocation context is available in the thread, to check entitlement (permissions) and maintain a
hierarchical causal chain even when operations are run in parallel
* processing can be managed across multiple management nodes

Some executions create new entities, which can then have tasks associated with them, and the system will record, for example, that a start effector on the new entity is a task associated with that entity, with that task
created by a task associated with a different entity.
@@ -32,8 +32,6 @@ Typically a Brooklyn deployment has a single management context which records:

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

When management is distributed a Brooklyn deployment may consist of multiple Brooklyn management nodes each with a ``ManagementContext`` instance.

<!-- TODO - Clarify the following statements.
The management context entity forms part of the management plane.
The management plane is responsible for the distribution of the ``Entity`` instances across multiple machines and multiple locations,

0 comments on commit faf1ac9

Please sign in to comment.