Commit ec3b36c8 authored by Klaus Aehlig's avatar Klaus Aehlig

Update future upgrade plans

Now that mandatory opcode fields are mandatory also on disk,
document that, once we use soft drains during upgrades, the disk
representation of the job queue needs to be updated by cfgupgrade
as well.
Signed-off-by: default avatarKlaus Aehlig <>
Reviewed-by: default avatarMichele Tartara <>
parent a9e1819b
......@@ -279,16 +279,19 @@ disappear, once :doc:`design-optables` is implemented, as then the
undrain will then be restricted to filters by gnt-upgrade.
Requirement of opcode backwards compatibility
Requirement of job queue update
Since for upgrades we only pause jobs and do not fully drain the
queue, we need to be able to transform the job queue into a queue for
the new version. The way this is achieved is by keeping the
serialization format backwards compatible. This is in line with
current practice that opcodes do not change between versions, and at
most new fields are added. Whenever we add a new field to an opcode,
we will make sure that the deserialization function will provide a
default value if the field is not present.
the new version. The preferred way to obtain this is to keep the
serialization format backwards compatible, i.e., only adding new
opcodes and new optional fields.
However, even with soft drain, no job is running at the moment `cfgupgrade`
is running. So, if we change the queue representation, including the
representation of individual opcodes in any way, `cfgupgrade` will also
modify the queue accordingly. In a jobs-as-processes world, pausing a job
will be implemented in such a way that the corresponding process stops after
finishing the current opcode, and a new process is created if and when the
job is unpaused again.
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment