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
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
