clean up policy descriptions

Project: http://git-wip-us.apache.org/repos/asf/brooklyn-docs/repo
Commit: http://git-wip-us.apache.org/repos/asf/brooklyn-docs/commit/ae513834
Tree: http://git-wip-us.apache.org/repos/asf/brooklyn-docs/tree/ae513834
Diff: http://git-wip-us.apache.org/repos/asf/brooklyn-docs/diff/ae513834

Branch: refs/heads/master
Commit: ae51383477061fcf5bdc3007639eaa495342ac4a
Parents: 046bc13
Author: Alex Heneveld <[email protected]>
Authored: Fri Sep 1 14:13:41 2017 +0100
Committer: Alex Heneveld <[email protected]>
Committed: Fri Sep 1 14:16:53 2017 +0100

----------------------------------------------------------------------
 guide/blueprints/policies.md | 23 ++++++++++++++++-------
 1 file changed, 16 insertions(+), 7 deletions(-)
----------------------------------------------------------------------


http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/ae513834/guide/blueprints/policies.md
----------------------------------------------------------------------
diff --git a/guide/blueprints/policies.md b/guide/blueprints/policies.md
index e5f7dde..7b90b58 100644
--- a/guide/blueprints/policies.md
+++ b/guide/blueprints/policies.md
@@ -7,11 +7,8 @@ Policies perform the active management enabled by Brooklyn.
 They can subscribe to entity sensors and be triggered by them (or they can run 
periodically,
 or be triggered by external systems).
 
-<!---
-TODO, clarify below, members of what?
--->
-Policies can add subscriptions to sensors on any entity. Normally a policy 
will subscribe to its
-associated entity, to the child entities, and/or to the members of a "group" 
entity.
+Policies can add subscriptions to sensors on any entity. Normally a policy 
will subscribe to sensors on
+either its associated entity, that entity's children and/or to the members of 
a "group" entity.
 
 Common uses of a policy include the following:
 
@@ -57,7 +54,10 @@ brooklyn.policies:
 
 - org.apache.brooklyn.policy.ha.ServiceRestarter
 
-Attaches to a SoftwareProcess (or anything Startable, emitting ENTITY_FAILED 
or other configurable sensor), and invokes restart on failure; if there is a 
subsequent failure within a configurable time interval, or if the restart 
fails, this gives up and emits {@link #ENTITY_RESTART_FAILED}
+Attaches to a SoftwareProcess or to anything Startable which emits 
`ha.entityFailed` on failure
+(or other configurable sensor), and invokes `restart` on that failure. 
+If there is a subsequent failure within a configurable time interval or if the 
restart fails, 
+this gives up and emits `ha.entityFailed.restart` for other policies to act 
upon or for manual intervention.
 
 {% highlight yaml %}
 brooklyn.policies:
@@ -66,6 +66,11 @@ brooklyn.policies:
     failOnRecurringFailuresInThisDuration: 5m
 {% endhighlight %}
 
+Typically this is used in conjunction with the FailureDetector enricher to 
emit the trigger sensor.
+The [introduction to policies](../start/policies.html) shows a worked 
+example of these working together.
+
+
 #### StopAfterDuration Policy
 
 - org.apache.brooklyn.policy.action.StopAfterDurationPolicy
@@ -100,7 +105,11 @@ The ConnectionFailureDetector is an HA policy for 
monitoring an http connection,
 
 - org.apache.brooklyn.policy.ha.ServiceReplacer
 
-The ServiceReplacer attaches to a DynamicCluster and replaces a failed member 
in response to HASensors.ENTITY_FAILED or other sensor.  The [introduction to 
policies](../) shows a worked example of the ServiceReplacer policy in user.
+The ServiceReplacer attaches to a DynamicCluster and replaces a failed member 
in response to 
+`ha.entityFailed` (or other configurable sensor).  
+The [introduction to policies](../start/policies.html) shows a worked 
+example of this policy in use.
+
 
 #### FollowTheSun Policy
 

Reply via email to