Open Stack

Hi all,

I've read that versioned objects are favored for supporting different
versions between RPC services and to support rolling upgrades. I'm
looking to follow the pattern for Heat. Basically, it is the classic
problem where we want to migrate from writing to a column in one table
to having that column live in a different table. Looking at nova code,
the version for a given versioned object is a constant in the given
object/<the_object_name>.py file. To properly support rolling upgrades
where we have older and newer heat-engine processes running
simultaneously (thus avoiding downtime), we have to write to both the
old column and the new column. Once all processes have been upgraded,
we can upgrade again to only write to the new location (but still able
to read from the old location of course). Following the existing
pattern, this means the operator has to upgrade <the_object_name.py>
twice (it may be possible to increment VERSION in <the_object_name.py>
only once, however, the first time).

The drawback of the above is it means cutting two releases (since two
different .py files). However, I wanted to check if anyone has gone
with a different approach so only one release is required. One way to
do that would be by specifying a version (or some other flag) in
heat.conf. Then, only one <the_object_name>.py release would be
required -- the logic of whether to write to both the old and new
location (the intermediate step) versus just the new location (the
final step) would be in <the_object_name>.py, dictated by the config
value. The advantage to this approach is now there is only one .py
file released, though the operator would still have to make a config
change and restart heat processes a second time to move from the
intermediate step to the final step.

Thanks,
--Crag