You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@brooklyn.apache.org by dr...@apache.org on 2017/09/16 08:16:10 UTC
[2/3] brooklyn-docs git commit: Address review comments
Address review comments
Project: http://git-wip-us.apache.org/repos/asf/brooklyn-docs/repo
Commit: http://git-wip-us.apache.org/repos/asf/brooklyn-docs/commit/b0d14344
Tree: http://git-wip-us.apache.org/repos/asf/brooklyn-docs/tree/b0d14344
Diff: http://git-wip-us.apache.org/repos/asf/brooklyn-docs/diff/b0d14344
Branch: refs/heads/master
Commit: b0d143442d522c33d383fc1588a6cabfbd0be9a8
Parents: 91484a6
Author: Duncan Godwin <du...@cloudsoftcorp.com>
Authored: Fri Sep 15 09:47:52 2017 +0100
Committer: Duncan Godwin <du...@cloudsoftcorp.com>
Committed: Fri Sep 15 09:47:52 2017 +0100
----------------------------------------------------------------------
guide/blueprints/policies.md | 17 +++++++++++++----
1 file changed, 13 insertions(+), 4 deletions(-)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/b0d14344/guide/blueprints/policies.md
----------------------------------------------------------------------
diff --git a/guide/blueprints/policies.md b/guide/blueprints/policies.md
index f305770..ff8d1f1 100644
--- a/guide/blueprints/policies.md
+++ b/guide/blueprints/policies.md
@@ -17,7 +17,7 @@ Common uses of a policy include the following:
* invoke effectors (management policies) or,
* cause the entity associated with the policy to emit sensor values (enricher policies).
-Entities can have zero or more ``Policy`` instances attached to them.
+Entities can have zero or more `Policy` instances attached to them.
Off-the-Shelf Policies
@@ -104,8 +104,10 @@ The ConnectionFailureDetector is an HA policy for monitoring an http connection,
- org.apache.brooklyn.policy.action.PeriodicEffectorPolicy
-The `PeriodicEffectorPolicy` calls an effector with a set of arguments at a specified time and date. The following example
-calls a `resize` effector to resize a cluster up to 10 members at 8am and then down to 1 member at 6pm.
+The `PeriodicEffectorPolicy` calls an effector with a set of arguments at a specified time and date. The policy monitors the
+sensor configured by `start.sensor` and will only start when this is set to `true`. The default sensor checked is `service.isUp`,
+so that the policy will not execute the effector until the entity is started. The following example calls a `resize` effector
+to resize a cluster up to 10 members at 8am and then down to 1 member at 6pm.
- type: org.apache.brooklyn.policy.action.PeriodicEffectorPolicy
brooklyn.config:
@@ -126,7 +128,14 @@ calls a `resize` effector to resize a cluster up to 10 members at 8am and then d
- org.apache.brooklyn.policy.action.ScheduledEffectorPolicy
-The `ScheduledEffectorPolicy` calls an effector after a specified interval has expired. The interval can be triggered from a sensor, `SERVICE_UP` by default.
+The `ScheduledEffectorPolicy` calls an effector at a specific time. The policy monitors the sensor configured by `start.sensor`
+and will only execute the effector at the specified time if this is set to `true`.
+
+There are two modes of operation, one based solely on policy configuration where the effector will execute at the time set
+using the `time` key or after the duration set using the `wait` key, or by monitoring sensors. The policy monitors the
+`scheduler.invoke.now` sensor and will execute the effector immediately when its value changes to `true`.
+When the `scheduler.invoke.at` sensor changes, it will set a time in the future when the effector should be executed.
+
The following example calls a `backup` effector every night at midnight.
- type: org.apache.brooklyn.policy.action.ScheduledEffectorPolicy