-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)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Reply via email to