This is an automated email from the ASF dual-hosted git repository.
heneveld pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/brooklyn-docs.git
The following commit(s) were added to refs/heads/master by this push:
new faf1ac9 Incorporate some feedback from Aled Sage
new 0ee14a0 This closes #291
faf1ac9 is described below
commit faf1ac9be629caae6aa1fe98c64059c12f8cf32e
Author: Denis Ovsienko <[email protected]>
AuthorDate: Fri Aug 16 17:26:14 2019 +0100
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
---
guide/concepts/application-parent-membership.md | 17 +++++++++++++----
guide/concepts/configuration-sensor-effectors.md | 5 +++--
guide/concepts/dependent-configuration.md | 3 +++
guide/concepts/execution.md | 1 -
guide/concepts/lifecycle-managementcontext.md | 2 --
5 files changed, 19 insertions(+), 9 deletions(-)
diff --git a/guide/concepts/application-parent-membership.md
b/guide/concepts/application-parent-membership.md
index bedd71e..52874f4 100644
--- a/guide/concepts/application-parent-membership.md
+++ b/guide/concepts/application-parent-membership.md
@@ -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.
diff --git a/guide/concepts/configuration-sensor-effectors.md
b/guide/concepts/configuration-sensor-effectors.md
index b0d9f9d..2c28bdb 100644
--- a/guide/concepts/configuration-sensor-effectors.md
+++ b/guide/concepts/configuration-sensor-effectors.md
@@ -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
diff --git a/guide/concepts/dependent-configuration.md
b/guide/concepts/dependent-configuration.md
index 21b5e95..bb25948 100644
--- a/guide/concepts/dependent-configuration.md
+++ b/guide/concepts/dependent-configuration.md
@@ -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.
diff --git a/guide/concepts/execution.md b/guide/concepts/execution.md
index 9fd0038..d4e9ebe 100644
--- a/guide/concepts/execution.md
+++ b/guide/concepts/execution.md
@@ -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.
diff --git a/guide/concepts/lifecycle-managementcontext.md
b/guide/concepts/lifecycle-managementcontext.md
index 68babb3..44e4471 100644
--- a/guide/concepts/lifecycle-managementcontext.md
+++ b/guide/concepts/lifecycle-managementcontext.md
@@ -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,
