Revision ec3b36c8 doc/design-upgrade.rst
| b/doc/design-upgrade.rst | ||
|---|---|---|
| 279 | 279 |
undrain will then be restricted to filters by gnt-upgrade. |
| 280 | 280 |
|
| 281 | 281 |
|
| 282 |
Requirement of opcode backwards compatibility
|
|
| 283 |
==============================================
|
|
| 282 |
Requirement of job queue update
|
|
| 283 |
=============================== |
|
| 284 | 284 |
|
| 285 | 285 |
Since for upgrades we only pause jobs and do not fully drain the |
| 286 | 286 |
queue, we need to be able to transform the job queue into a queue for |
| 287 |
the new version. The way this is achieved is by keeping the |
|
| 288 |
serialization format backwards compatible. This is in line with |
|
| 289 |
current practice that opcodes do not change between versions, and at |
|
| 290 |
most new fields are added. Whenever we add a new field to an opcode, |
|
| 291 |
we will make sure that the deserialization function will provide a |
|
| 292 |
default value if the field is not present. |
|
| 293 |
|
|
| 294 |
|
|
| 287 |
the new version. The preferred way to obtain this is to keep the |
|
| 288 |
serialization format backwards compatible, i.e., only adding new |
|
| 289 |
opcodes and new optional fields. |
|
| 290 |
|
|
| 291 |
However, even with soft drain, no job is running at the moment `cfgupgrade` |
|
| 292 |
is running. So, if we change the queue representation, including the |
|
| 293 |
representation of individual opcodes in any way, `cfgupgrade` will also |
|
| 294 |
modify the queue accordingly. In a jobs-as-processes world, pausing a job |
|
| 295 |
will be implemented in such a way that the corresponding process stops after |
|
| 296 |
finishing the current opcode, and a new process is created if and when the |
|
| 297 |
job is unpaused again. |
|
Also available in: Unified diff