Ryan, Thanks for sharing your inputs. By looking through your response, I couldn't find the reasoning about why a young project is the perfect time to enforce a strict object version rule. I think a young project often starts with a static (or non-frequently changing) version until a point in time the project reaches a certain level of maturity. Isn't it? As a core reviewer of Magnum, I observe that the project is under fast development and objects are changing from time to time. It is very heavy to do all the work for strictly enforcing the version (bump version number, document the changed fields, re-generate the hashes, implement the compatibility check, etc.). Instead, I would prefer to let all objects stay in a beta version, until a time in future, the team decides to start bumping it.
Best regards, Hongbin From: Ryan Rossiter [mailto:rlros...@linux.vnet.ibm.com] Sent: August-27-15 2:41 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [magnum] versioned objects changes 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.gra...@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-requ...@lists.openstack.org?subject:unsubscribe<mailto:openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Thanks, Ryan Rossiter
__________________________________________________________________________ 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
