Revision ec3b36c8
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