Open Stack

If you want my inexperienced opinion, a young project is the perfect 
time to start this. Nova has had a bunch of problems with versioned 
objects that don't get realized until the next release (because that's 
the point in time at which grenade (or worse, operators) catch this). At 
that point, you then need to hack things around and backport them in 
order to get them working in the old branch. [1] is an excellent example 
of Nova having to backport a fix to an object because we weren't using 
strict object testing.

I don't feel that this should be adding overhead to contributors and 
reviewers. With [2], this test absolutely helps both contributors and 
reviewers. Yes, it requires "fixing" things when a change happens to an 
object. Learning to do this "fix" to update object hashes is extremely 
easy to do and I hope my updated comment on there makes it even easier 
(also be aware I am new to OpenStack & Nova as of about 2 months ago, so 
this stuff was new to me too not very long ago).

I understand that something like [2] will cause a test to fail when you 
make a major change to a versioned object. But you *want* that. It helps 
reviewers more easily catch contributors to say "You need to update the 
version, because the hash changed". The sooner you start using versioned 
objects in the way they are designed, the smaller the upfront cost, and 
it will also be a major savings later on if something like [1] pops up.

[1]: https://bugs.launchpad.net/nova/+bug/1474074
[2]: https://review.openstack.org/#/c/217342/

On 8/27/2015 9:46 AM, Hongbin Lu wrote:
>
> -1 from me.
>
> IMHO, the rolling upgrade feature makes sense for a mature project 
> (like Nova), but not for a young project like Magnum. It incurs 
> overheads for contributors & reviewers to check the object 
> compatibility in each patch. As you mentioned, the key benefit of this 
> feature is supporting different version of magnum components running 
> at the same time (i.e. running magnum-api 1.0 with magnum-conductor 
> 1.1). I don’t think supporting this advanced use case is a must at the 
> current stage.
>
> However, I don’t mean to against merging patches of this feature. I 
> just disagree to enforce the rule of object version change in the near 
> future.
>
> Best regards,
>
> Hongbin
>
> *From:*Grasza, Grzegorz [mailto:grzegorz.grasza at intel.com]
> *Sent:* August-26-15 4:47 AM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* [openstack-dev] [magnum] versioned objects changes
>
> 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.
>
> / 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

-- 
Thanks,

Ryan Rossiter

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