Merge lp:~jimbaker/pyjuju/new-hook-semantics-5-docs into lp:pyjuju
- new-hook-semantics-5-docs
- Merge into trunk
Status: | Merged |
---|---|
Approved by: | Gustavo Niemeyer |
Approved revision: | 203 |
Merged at revision: | 200 |
Proposed branch: | lp:~jimbaker/pyjuju/new-hook-semantics-5-docs |
Merge into: | lp:pyjuju |
Diff against target: |
353 lines (+166/-113) 1 file modified
docs/source/formula.rst (+166/-113) |
To merge this branch: | bzr merge lp:~jimbaker/pyjuju/new-hook-semantics-5-docs |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Gustavo Niemeyer | Approve | ||
Review via email: mp+57536@code.launchpad.net |
Commit message
Description of the change
This branch updates the description of the hooks so as to update them with respect to the new hook semantic changes. It also copy edits this formula section as a whole. In particular, the copy editing focus was on clarifying how hooks actually execute, and under what conditions. This is to avoid the confusion that prompted the new-hook-semantics- branches in the first place.
Ahmed Kamal (kim0) wrote : | # |
Gustavo Niemeyer (niemeyer) wrote : | # |
Very good changes overall, thanks Jim.
We'll need another round:
[1]
17 +A formula is deployed as a service, potentially multiple times. Each
This is very open and perhaps even misleading. Please take this specific
sentence off. The rest of the paragraph should give better background.
[2]
+The `metadata.yaml` file, at the root of the formula definition,
s/definition/
[3]
- and `peers` relations (note: that's not yet supported).
(...)
- that the relation is required (note: that's not yet supported).
Please add back both unsupported notes. All documentation which is not
under drafts should reflect what is implemented and may be trusted upon,
or declare explicitly what is not yet in place.
130 + At this time, Ensemble does not enforce the `limit` and
131 + `optional` constraints, but Ensemble will do so in the future.
The note really has to be closer to the explanation. Someone reading about
the field to tweak a formula will not read the whole text to see what is
supported or not.
[4]
188 +changes on its underlying machine, and change its own relation
189 +settings. Changes to relation settings then trigger further events
190 +that hooks can respond to. The following section on hook tools
s/its own relation settings/the relation settings/ (the subject of the
sentence is "the hook").
Also, please drop the sentence starting at "Changes to relation". You're
describing what happens from the perspective of an individual unit. For
an individual unit, changing relation settings will not trigger its own
hooks to execute again.
[5]
194 +the desired hook name under the ``hooks/`` directory of the formula
195 +bundle or directory
s/bundle or directory/
Conceptually, we use the bundle term to reference to a file, so it can't
have directories.
[6]
195 +bundle or directory. Ensemble then executes the hook without command
196 +line arguments when the corresponding event occurs.
Please use this in place of the latter sentence:
Ensemble will execute the hook based on its file name when the corresponding
event occurs.
Note that in general we don't have to document the lack of something. If it's
not documented to exist, it's fine to not exist.
[7]
198 +Each hook is optional. Not including a corresponding executable in the
s/Each hook is/All hooks are/
[8]
213 + * **stop** - Runs when the service unit is stopped. This hook will run
214 + after any established relations are broken.
Let's take the chance to fix the pre-existing ambiguity in the latter sentence:
If relations exist, they will be broken and the respective hooks called before
this hook is called.
[9]
+ 1. A remote service unit joins the relation.
Let's complement:
1. A remote service unit joins the relation, right after the
[10]
229 + This hook is the most common hook for a formula to implement. It
230 + enables service units to handshake and otherwise negotiate their
231 + interaction, especially with respect to scaling up and down
232 + service deployments.
This doesn't feel very helpful. It's taking assumptions about how the user
sh...
Jim Baker (jimbaker) wrote : | # |
Thanks, I forgot to run my double-word-typo script that I have just for this
case! (Need to integrate that into my push process or maybe the emacs fly
mode support.)
On Thu, Apr 14, 2011 at 8:06 AM, Ahmed Kamal <email address hidden>wrote:
> Typo line-259 says "with with respect"
> --
>
> https:/
> You are the owner of lp:~jimbaker/ensemble/new-hook-semantics-5-docs.
>
Jim Baker (jimbaker) wrote : | # |
On Thu, Apr 14, 2011 at 8:59 AM, Gustavo Niemeyer <email address hidden>wrote:
> Review: Needs Fixing
> Very good changes overall, thanks Jim.
>
> We'll need another round:
>
> [1]
>
> 17 +A formula is deployed as a service, potentially multiple times.
> Each
>
> This is very open and perhaps even misleading. Please take this specific
> sentence off. The rest of the paragraph should give better background.
>
>
Reworked intro
>
> [2]
>
> +The `metadata.yaml` file, at the root of the formula definition,
>
> s/definition/
>
Changed
>
>
> [3]
>
> - and `peers` relations (note: that's not yet supported).
> (...)
> - that the relation is required (note: that's not yet supported).
>
> Please add back both unsupported notes. All documentation which is not
> under drafts should reflect what is implemented and may be trusted upon,
> or declare explicitly what is not yet in place.
>
> 130 + At this time, Ensemble does not enforce the `limit` and
> 131 + `optional` constraints, but Ensemble will do so in the
> future.
>
> The note really has to be closer to the explanation. Someone reading about
> the field to tweak a formula will not read the whole text to see what is
> supported or not.
>
Moved description to being closer as suggested
>
>
> [4]
>
> 188 +changes on its underlying machine, and change its own relation
> 189 +settings. Changes to relation settings then trigger further events
> 190 +that hooks can respond to. The following section on hook tools
>
> s/its own relation settings/the relation settings/ (the subject of the
> sentence is "the hook").
>
> Also, please drop the sentence starting at "Changes to relation". You're
> describing what happens from the perspective of an individual unit. For
> an individual unit, changing relation settings will not trigger its own
> hooks to execute again.
>
Fixed
>
>
> [5]
>
> 194 +the desired hook name under the ``hooks/`` directory of the
> formula
> 195 +bundle or directory
>
> s/bundle or directory/
>
> Conceptually, we use the bundle term to reference to a file, so it can't
> have directories.
>
This was from the old text in trunk, so thanks for spotting this so it
doesn't get perpetuated
>
>
> [6]
>
> 195 +bundle or directory. Ensemble then executes the hook without
> command
> 196 +line arguments when the corresponding event occurs.
>
> Please use this in place of the latter sentence:
>
> Ensemble will execute the hook based on its file name when the
> corresponding
> event occurs.
>
Much better
>
> Note that in general we don't have to document the lack of something. If
> it's
> not documented to exist, it's fine to not exist.
>
Ack
>
>
> [7]
>
> 198 +Each hook is optional. Not including a corresponding executable in
> the
>
> s/Each hook is/All hooks are/
>
Changed
>
>
> [8]
>
>
> 213 + * **stop** - Runs when the service unit is stopped. This hook
> will run
> 214 + after any established relations are broken.
>
> Let's take the chance to fix the pre-existing ambiguity in the latter
> sentence:
>
> If relations exist, they will be broken and the respective hooks ca...
Gustavo Niemeyer (niemeyer) wrote : | # |
Thanks, +1 with a small fix for that:
[15]
Its purpose is to allow the formula to
255 + clean up established state
256 +
257 + The service unit can then clean up any established state.
Preview Diff
1 | === modified file 'docs/source/formula.rst' |
2 | --- docs/source/formula.rst 2011-04-08 17:37:35 +0000 |
3 | +++ docs/source/formula.rst 2011-04-19 15:20:54 +0000 |
4 | @@ -1,80 +1,86 @@ |
5 | - |
6 | Formulas |
7 | ======== |
8 | |
9 | Introduction |
10 | ------------ |
11 | |
12 | -In Ensemble, formulas are the description of how services should |
13 | -behave when deployed and run. A single service definition may be run |
14 | -multiple times with the same formula and configuration, so we call a |
15 | -deployed and running service as a service unit. Each of those units |
16 | -will have an independent copy of the same formula guiding its behavior. |
17 | +Formulas define how services integrate and how their service units |
18 | +react to events in the distributed environment, as orchestrated by |
19 | +Ensemble. |
20 | |
21 | -This specification describes how formulas are built and how they |
22 | -react once integrated in an Ensemble environment. |
23 | +This specification describes how formulas are defined, including their |
24 | +metadata and hooks. It also describes the resources available to hooks |
25 | +in working with the Ensemble environment. |
26 | |
27 | |
28 | The metadata file |
29 | ----------------- |
30 | |
31 | -The file named `metadata.yaml`, at the root of the formula, contains |
32 | -details about the formula. |
33 | - |
34 | -The following fields are supported: |
35 | +The `metadata.yaml` file, at the root of the formula directory, |
36 | +describes the formula. The following fields are supported: |
37 | |
38 | * **name:** - The formula name itself. |
39 | |
40 | - * **revision:** - A monothonically increasing integer which defines the |
41 | - formula version. |
42 | - |
43 | - * **summary:** - A one line description of the formula |
44 | - |
45 | - * **description:** - Long explanation about the formula features |
46 | - |
47 | - * **provides:** - The deployed service unit must have the given relations |
48 | - established with another service unit whose formula requires them for |
49 | - the service to work properly. See below for how to define a relation. |
50 | - |
51 | - * **requires:** - The deployed service unit must have the given relations |
52 | - established with another service unit whose formula provides them for |
53 | - the service to work properly. See below for how to define a relation. |
54 | - |
55 | - * **peers:** - Relations which are established not in a provides/requires |
56 | - (or client/server) style, but with P2P semantics. When the formula |
57 | - is deployed as a service unit, all the units from the given service |
58 | - will automatically be made part of the relation. See below for how to |
59 | - define a relation. |
60 | + * **revision:** - A monotonically increasing integer which defines |
61 | + the formula version. This number is used to determine if the |
62 | + formula needs to be updated in the Ensemble environment. It is |
63 | + also displayed as output for the ``ensemble status`` command, so |
64 | + you can ensure you have the right formula deployed. |
65 | + |
66 | + * **summary:** - A one-line description of the formula. |
67 | + |
68 | + * **description:** - Long explanation of the formula and its |
69 | + features. |
70 | + |
71 | + * **provides:** - The deployed service unit must have the given |
72 | + relations established with another service unit whose formula |
73 | + requires them for the service to work properly. See below for how |
74 | + to define a relation. |
75 | + |
76 | + * **requires:** - The deployed service unit must have the given |
77 | + relations established with another service unit whose formula |
78 | + provides them for the service to work properly. See below for how |
79 | + to define a relation. |
80 | + |
81 | + * **peers:** - Relations that are established with P2P semantics |
82 | + instead of a provides/requires (or client/server) style. When the |
83 | + formula is deployed as a service unit, all the units from the |
84 | + given service will automatically be made part of the relation. |
85 | + See below for how to define a relation. |
86 | |
87 | |
88 | Relations available in `provides`, `requires`, and `peers` are defined |
89 | -the following way: |
90 | +as follows: |
91 | |
92 | * **provides|requires|peers:** |
93 | |
94 | - * **<relation name>:** - This is a user-provided value which identifies |
95 | - this relation uniquely within the given formula. Examples might be |
96 | - "database", or "cache", or "proxy", or "appserver". |
97 | + * **<relation name>:** - This name is a user-provided value which |
98 | + identifies the relation uniquely within the given formula. |
99 | + Examples include "database", "cache", "proxy", and "appserver". |
100 | |
101 | Each relation may have the following fields defined: |
102 | |
103 | - * **interface:** - This defines the type of this relation. This |
104 | - relation will only be established with service units which |
105 | - define a compatible relation with the same interface. Examples |
106 | - here might be "http", or "mysql", or "backup-schedule". |
107 | + * **interface:** - This field defines the type of the |
108 | + relation. The relation will only be established with service |
109 | + units that define a compatible relation with the same |
110 | + interface. Examples include "http", "mysql", and |
111 | + "backup-schedule". |
112 | |
113 | - * **limit:** - The maximum number of relations of this kind which |
114 | - may be established to other service units. Defaults to 1 for |
115 | - `requires` relations, and to "none" (no limit) for `provides` |
116 | - and `peers` relations (note: that's not yet supported). |
117 | + * **limit:** - The maximum number of relations of this kind |
118 | + which may be established to other service units. Defaults to |
119 | + 1 for `requires` relations, and to "none" (no limit) for |
120 | + `provides` and `peers` relations. While you may define it, |
121 | + this field is not yet enforced by Ensemble. |
122 | |
123 | * **optional:** - Whether this relation is required for the |
124 | - service unit to function or not. Defaults to `false`, meaning |
125 | - that the relation is required (note: that's not yet supported). |
126 | + service unit to function or not. Defaults to `false`, which |
127 | + means the relation is required. While you may define it, this |
128 | + field is not yet enforced by Ensemble. |
129 | |
130 | As a shortcut, if these properties are not defined, and instead |
131 | - a single string value is provided next to the relation name, |
132 | - the string is taken as the interface value. For example:: |
133 | + a single string value is provided next to the relation name, the |
134 | + string is taken as the interface value, as seen in this |
135 | + example:: |
136 | |
137 | requires: |
138 | db: mysql |
139 | @@ -86,88 +92,129 @@ |
140 | Hooks |
141 | ----- |
142 | |
143 | -Hooks are the mechanism through which service units are notified of |
144 | -events happening around them. Each hook is an executable within the |
145 | -`hooks/` directory of the formula bundle or directory. |
146 | - |
147 | -Hooks are able to modify the relation settings via command line tools |
148 | -offered by Ensemble. These changes are only perceived by its peers |
149 | -when the hook has finished running successfully. If a hook exits with |
150 | -a non-zero error code state changes are not committed. |
151 | - |
152 | -Some hooks are named after the formula relation which they want to be |
153 | -notified about. |
154 | - |
155 | -The following hooks are currently defined: |
156 | - |
157 | - * **install** - Run just once during the life time of a service unit. |
158 | - |
159 | - * **start** - Run when the formula is started. This happens before |
160 | - any relation hooks are called. The purpose of this hook is to get |
161 | - the service ready for relations to be established. |
162 | - |
163 | - * **stop** - Run when the formula is stopped. This will run after any |
164 | - established relations are broken. |
165 | - |
166 | - * **<relation name>-relation-established** - This hook is run when a |
167 | - defined relation is established with one or more peers. Any |
168 | - actions related to this relation being established should be |
169 | - performed. |
170 | - |
171 | - An example might be providing via `relation-set` the TCP port of |
172 | - an offered XML-RPC service, or perhaps notifying the started web |
173 | - application that the MySQL database is now available. |
174 | - |
175 | - * **<relation name>-relation-broken** - This hook is run when a |
176 | - relation which had at least one other relation hook run for it |
177 | - (successfully or not) is now unavailable. Its purpose is to |
178 | - allow the formula to clean up established state. |
179 | - |
180 | - An example might be cleaning up the configuration changes which |
181 | - were performed when HAProxy was asked to load-balance for another |
182 | +Ensemble uses hooks to notify a service unit about changes happening |
183 | +in its lifecycle or the larger distributed environment. A hook running |
184 | +for a service unit can query this environment, make any desired local |
185 | +changes on its underlying machine, and change the relation |
186 | +settings. |
187 | + |
188 | +Each hook for a formula is implemented by placing an executable with |
189 | +the desired hook name under the ``hooks/`` directory of the formula |
190 | +directory. Ensemble will execute the hook based on its file name when |
191 | +the corresponding event occurs. |
192 | + |
193 | +All hooks are optional. Not including a corresponding executable in |
194 | +the formula is treated by Ensemble as if the hook executed and then |
195 | +exited with an exit code of 0. |
196 | + |
197 | +The following hooks are with respect to the lifecycle of a service unit: |
198 | + |
199 | + * **install** - Runs just once during the life time of a service |
200 | + unit. Currently this hook is the right place to ensure any package |
201 | + dependencies are met. However, in the future Ensemble will use the |
202 | + formula metadata to perform this role instead. |
203 | + |
204 | + * **start** - Runs when the service unit is started. This happens |
205 | + before any relation hooks are called. The purpose of this hook is |
206 | + to get the service unit ready for relations to be established. |
207 | + |
208 | + * **stop** - Runs when the service unit is stopped. If relations |
209 | + exist, they will be broken and the respective hooks called before |
210 | + this hook is called. |
211 | + |
212 | +The following hooks are called on each service unit as the membership |
213 | +of an established relation changes: |
214 | + |
215 | + * **<relation name>-relation-joined** - Runs upon each time a remote |
216 | + service unit joins the relation. |
217 | + |
218 | + * **<relation name>-relation-changed** - Runs upon each time the |
219 | + following events occur: |
220 | + |
221 | + 1. A remote service unit joins the relation, right after the |
222 | + **<relation name>-relation-joined** hook was called. |
223 | + |
224 | + 2. A remote service unit changes its relation settings. |
225 | + |
226 | + This hook enables the formula to modify the service unit state |
227 | + (configuration, running processes, or anything else) to adapt to |
228 | + the relation settings of remote units. |
229 | + |
230 | + An example usage is that HAProxy needs to be aware of web servers |
231 | + as they become available, including details like its IP |
232 | + address. Web server service units can publish their availability |
233 | + by making the appropriate relation settings in the hook that makes |
234 | + the most sense. Assume the HAProxy uses the relation name of |
235 | + ``server``. Then upon that happening, the HAProxy in its |
236 | + ``server-relation-changed hook`` can then change its own |
237 | + configuration as to what is available to be proxied. |
238 | + |
239 | + * **<relation name>-relation-departed** - Runs upon each time a |
240 | + remote service unit leaves a relation. This could happen because |
241 | + the service unit has been removed, its service has been destroyed, |
242 | + or the relation between this service and the remote service has |
243 | + been removed. |
244 | + |
245 | + An example usage is that HAProxy needs to be aware of web servers |
246 | + when they are no longer available. It can remove each web server |
247 | + its configuration as the corresponding service unit departs the |
248 | + relation. |
249 | + |
250 | +This relation hook is with respect to the relation itself: |
251 | + |
252 | + * **<relation name>-relation-broken** - Runs when a relation which |
253 | + had at least one other relation hook run for it (successfully or |
254 | + not) is now unavailable. Its purpose is to allow the formula to |
255 | + clean up established state |
256 | + |
257 | + The service unit can then clean up any established state. An |
258 | + example might be cleaning up the configuration changes which were |
259 | + performed when HAProxy was asked to load-balance for another |
260 | service unit. |
261 | |
262 | - * **<name>-relation-changed** - This hook is called when: |
263 | - |
264 | - 1. A new remote service unit joins the relation. |
265 | - |
266 | - 2. A remote service unit changes its relation settings. |
267 | - |
268 | - 3. A remote service unit which was part of the relation has |
269 | - had its relation broken. |
270 | +Note that the coupling between formulas is defined by which settings |
271 | +are required and made available to them through the relation hooks and |
272 | +how these settings are used. Those conventions then define what the |
273 | +relation interface really is, and the **interface** name in the |
274 | +`metadata.yaml` file is simply a way to refer to them and avoid the |
275 | +attempting of incompatible conversations. Keep that in mind when |
276 | +designing your formulas and relations, since it is a good idea to |
277 | +allow the implementation of the formula to change and be replaced with |
278 | +alternative versions without changing the relation conventions in a |
279 | +backwards incompatible way. |
280 | |
281 | |
282 | Hook environment |
283 | ---------------- |
284 | |
285 | Hooks can expect to be invoked with a standard environment and |
286 | -context. The following be included: |
287 | +context. The following environment variables are set: |
288 | |
289 | - * `$ENSEMBLE_UNIT_NAME` - The name of the local unit executing, |
290 | - in the form `<service name>/<unit sequence>`. E.g. myblog/3. |
291 | + * **$ENSEMBLE_UNIT_NAME** - The name of the local unit executing, |
292 | + in the form ``<service name>/<unit sequence>``. E.g. ``myblog/3``. |
293 | |
294 | Hooks called for relation changes will have the follow additional |
295 | -environment variables available to them. |
296 | - |
297 | - * `$ENSEMBLE_RELATION` - The relation name this hook is running |
298 | - for. It's redundant with the hook name, but is necessary for |
299 | - the command line tools to know the current context. |
300 | - |
301 | - * `$ENSEMBLE_REMOTE_UNIT` - The unit name of the remote unit |
302 | - which has triggered the hook execution. |
303 | +environment variables set: |
304 | + |
305 | + * **$ENSEMBLE_RELATION** - The relation name this hook is running |
306 | + for. It's redundant with the hook name, but is necessary for |
307 | + the command line tools to know the current context. |
308 | + |
309 | + * **$ENSEMBLE_REMOTE_UNIT** - The unit name of the remote unit |
310 | + which has triggered the hook execution. |
311 | |
312 | |
313 | Hook tools |
314 | ---------- |
315 | |
316 | -To implement their functionality, hooks may leaverage a set of |
317 | -utilities provided by Ensemble. These utilities enable the hook to |
318 | -collaborate about configuration state, and to inquire about the peers |
319 | -the service unit has relations with. |
320 | +In implementing their functionality, hooks can leverage a set of |
321 | +command tools provided by Ensemble. These utilities enable the hook |
322 | +to collaborate on their relation settings, and to inquire about the |
323 | +peers the service unit has relations with. |
324 | |
325 | The following command line tools are made available: |
326 | |
327 | - * **relation-get** - Queries a setting from an established relation |
328 | + * **relation-get** - Queries a setting from an established relation |
329 | with one or more service units. This command will read some |
330 | context information from environment variables (e.g. |
331 | $ENSEMBLE_RELATION_NAME). |
332 | @@ -210,13 +257,19 @@ |
333 | |
334 | * **relation-list** - List all service units participating in the |
335 | established relation. This list excludes the local service unit |
336 | - which is executing the command. For provides and requires |
337 | - relation, this will always return a single service unit. |
338 | + which is executing the command. For `provides` and `requires` |
339 | + relations, this command will always return a single service unit. |
340 | |
341 | Example:: |
342 | |
343 | MEMBERS=$(relation-list) |
344 | |
345 | +Changes to relation settings are only committed if the hook exits with |
346 | +a non-zero status code. Such changes will then trigger further hook |
347 | +execution in the remote unit(s), through the **<relation |
348 | +name>-relation-changed** hook. This mechanism enables a general |
349 | +communication mechanism for service units to coordinate. |
350 | + |
351 | |
352 | Sample metadata.yaml files |
353 | -------------------------- |
Typo line-259 says "with with respect"