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,

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,

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


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:

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 

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)





Ryan Rossiter
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Reply via email to