Add docs for Scheduled and PeriodicEffectorPolicy #213
Conversation
guide/blueprints/policies.md
Outdated
|
|
||
| - org.apache.brooklyn.policy.action.ScheduledEffectorPolicy | ||
|
|
||
| The ScheduledEffectorPolicy calls an effector with a set of arguments at a specified time and date. The following example |
There was a problem hiding this comment.
Would wrap ScheduledEffectorPolicy in ``
guide/blueprints/policies.md
Outdated
|
|
||
| - org.apache.brooklyn.policy.action.PeriodicEffectorPolicy | ||
|
|
||
| The PeriodicEffectorPolicy calls an effector after a specified interval has expired. The interval can be triggered from a sensor, `SERVICE_UP` by default. |
There was a problem hiding this comment.
Same as above but for PeriodicEffectorPolicy
guide/blueprints/policies.md
Outdated
| - org.apache.brooklyn.policy.action.PeriodicEffectorPolicy | ||
|
|
||
| The PeriodicEffectorPolicy calls an effector after a specified interval has expired. The interval can be triggered from a sensor, `SERVICE_UP` by default. | ||
| The following example calls a backup effector every day. |
There was a problem hiding this comment.
Same as above but for backup (effector)
guide/blueprints/policies.md
Outdated
| - org.apache.brooklyn.policy.action.ScheduledEffectorPolicy | ||
|
|
||
| The ScheduledEffectorPolicy 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. |
There was a problem hiding this comment.
Same as above but for resize (effector)
guide/blueprints/policies.md
Outdated
| - type: org.apache.brooklyn.policy.action.PeriodicEffectorPolicy | ||
| brooklyn.config: | ||
| effector: backup | ||
| period: 1d |
There was a problem hiding this comment.
Is it on purpose that the period value is different than the example above?
There was a problem hiding this comment.
both are valid I think, I'll make them the same though
drigodwin
force-pushed
the
add-periodic-policy-docs
branch
from
2398ab3
to
91484a6
Compare
guide/blueprints/policies.md
Outdated
| - 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. |
There was a problem hiding this comment.
add this text:
The policy monitors the sensor configured as
start.sensorand will only start when this is set totrue. The default sensor checked isservice.isUp, so that the policy will not execute the effector until the entity is started.
guide/blueprints/policies.md
Outdated
|
|
||
| - 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. |
There was a problem hiding this comment.
change to:
The
ScheduledEffectorPolicycalls an effector at a specific time, waiting until the entity is ready using the same mechanism as thePeriodicEffectorPolicy. There are two modes of operation, one based solely on policy configuration where the effector will execute at the time set using thetimekey or after the duration set using thewaitkey, or by monitoring sensors. The policy monitors thescheduler.invoke.nowsensor and will execute the effector immediately when its value changes totrue. When thescheduler.invoke.atsensor changes, it will set a time in the future when the effector should be executed.
|
LGTM @drigodwin |
|
Merging as brooklyn-server#822 is merged |
Docs for brooklyn-server#822