On 8/26/15 4:47 AM, Grasza, Grzegorz wrote:
Hi,
I noticed that right now, when we make changes (adding/removing
fields) in
https://github.com/openstack/magnum/tree/master/magnum/objects , we
don't change object versions.
The idea of objects is that each change in their fields should be
versioned, documentation about the change should also be written in a
comment inside the object and the obj_make_compatible method should be
implemented or updated. See an example here:
https://github.com/openstack/nova/commit/ad6051bb5c2b62a0de6708cd2d7ac1e3cfd8f1d3#diff-7c6fefb09f0e1b446141d4c8f1ac5458L27
The question is, do you think magnum should support rolling upgrades
from next release or maybe it's still too early?
If yes, I think core reviewers should start checking for these
incompatible changes.
To clarify, rolling upgrades means support for running magnum services
at different versions at the same time.
In Nova, there is an RPC call in the conductor to backport objects,
which is called when older code gets an object it doesn’t understand.
This patch does this in Magnum: https://review.openstack.org/#/c/184791/ .
I can report bugs and propose patches with version changes for this
release, to get the effort started.
In Mitaka, when Grenade gets multi-node support, it can be used to add
CI tests for rolling upgrades in Magnum.
from my POV I don't have strong feelings about using versioned objects
early, however I do feel that the actual database migration model itself
should *not* rely on expand/contract early in a project's lifecycle;
expand/contract places severe limitations on the kinds of changes that
can easily be made to a database schema and is better applied once the
schema is mostly solidified in overall form, and the only changes that
continue to be made are simple additions of new tables, columns and indexes.
/ Greg
__________________________________________________________________________
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
__________________________________________________________________________
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
