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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev