[openstack-dev] [magnum] versioned objects changes

Mike Bayer mbayer at redhat.com
Mon Aug 31 17:33:23 UTC 2015



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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150831/4c8c7dba/attachment.html>


More information about the OpenStack-dev mailing list