Revision 7786784e
| b/doc/design-daemons.rst | ||
|---|---|---|
| 311 | 311 |
The WConfD daemon will be responsible for removing stale lock files of |
| 312 | 312 |
jobs that didn't remove its lock files themselves. |
| 313 | 313 |
|
| 314 |
**Statelessness of the protocol:** To keep our protocols stateless, |
|
| 315 |
the job id and the path the to lock file are sent as part of every |
|
| 316 |
request that deals with resources, in particular the Ganeti Locks. |
|
| 317 |
All resources are owned by the pair (job id, lock file). In this way, |
|
| 318 |
several jobs can live in the same process (as it will be in the |
|
| 319 |
transition period), but owner death detection still only depends on the |
|
| 320 |
owner of the resource. In particular, no additional lookup table is |
|
| 321 |
needed to obtain the lock file for a given owner. |
|
| 322 |
|
|
| 314 | 323 |
**Considered alternatives:** An alternative to creating a separate lock |
| 315 | 324 |
file would be to lock the job status file. However, file locks are kept |
| 316 | 325 |
only as long as the file is open. Therefore any operation followed by |
| ... | ... | |
| 328 | 337 |
replies with a JSON response document containing either the result of |
| 329 | 338 |
signalling a failure. |
| 330 | 339 |
|
| 331 |
There will be a special RPC call for identifying a client when connecting to |
|
| 332 |
WConfD. The client will tell WConfD it's job number and process ID. WConfD will |
|
| 333 |
fail any other RPC calls before a client identifies this way. |
|
| 334 |
|
|
| 335 | 340 |
Any state associated with client processes will be mirrored on persistent |
| 336 | 341 |
storage and linked to the identity of processes so that the WConfD daemon will |
| 337 | 342 |
be able to resume its operation at any point after a restart or a crash. WConfD |
Also available in: Unified diff