Open Stack

Hi all,
I would like to gather all upgrade activities in Neutron in one place, in order to summarizes the current status and future activities on rolling upgrades in Mitaka.


1.      RPC versioning

a.      It is already implemented in Neutron.

b.      TODO: To have the rolling upgrade we have to implement the RPC version pinning in conf.

                                                    i.     I'm not a big fan of this solution, but we can work out better idea if needed.

c.      Possible unit/functional tests to catch RPC version incompatibilities between RPC revisions.

d.      TODO: Multi-node Grenade job to have rolling upgrades covered in CI.

2.      Message content versioning - versioned objects

a.      TODO: implement Oslo Versionobject in Mitaka cycle. The interesting entities to be implemented: network, subnet, port, security groups...

b.      Will OVO have impact on vendor plugins?

c.      Be strict on changes in version objects in code review, any change in object structure should increment the minor (backward-compatible) or major (breaking change) RPC version.

d.      Indirection API - message from newer format should be translated to older version by neutron server.

3.      Database migration

a.      Online schema migration was done in Liberty release, any work left to do?

b.      TODO: Online data migration to be introduced in Mitaka cycle.

                                                    i.     Online data migration can be done during normal operation on the data.

                                                   ii.     There should be also the script to invoke the data migration in the background.

c.      Currently the contract phase is doing the data migration. But since the contract phase should be run offline, we should move the data migration to preceding step. Also the contract phase should be blocked if there is still relevant data in removed entities.

                                                    i.     Contract phase can be executed online, if there is all new code running in setup.

d.      The other strategy is to not drop tables, alter names or remove the columns from the DB - what's in, it's in. We should put more attention on code reviews, merge only additive changes and avoid questionable DB modification.

e.      The Neutron server should be updated first, in order to do data translation between old format into new schema. When doing this, we can be sure that old data would not be inserted into old DB structures.

I have performed the manual Kilo to Liberty upgrade, both in operational manner and in code review of the RPC APIs. All is working fine.
We can have some discussion on cross-project session [7] or we can also review any issues with Neutron upgrade in Friday's unplugged session [8].

Sources:
[1] http://www.danplanet.com/blog/2015/10/05/upgrades-in-nova-rpc-apis/
[2] http://www.danplanet.com/blog/2015/10/06/upgrades-in-nova-objects/
[3] http://www.danplanet.com/blog/2015/10/07/upgrades-in-nova-database-migrations/
[4] https://github.com/openstack/neutron/blob/master/doc/source/devref/rpc_callbacks.rst
[5] http://www.danplanet.com/blog/2015/06/26/upgrading-nova-to-kilo-with-minimal-downtime/
[6] https://github.com/openstack/neutron-specs/blob/master/specs/liberty/online-schema-migrations.rst
[7] https://etherpad.openstack.org/p/mitaka-cross-project-session-planning
[8] https://etherpad.openstack.org/p/mitaka-neutron-unplugged-track

Regards,
Artur Korzeniewski
IRC: korzen
--------------------------------------------
Intel Technology Poland sp. z o.o.
KRS 101882
ul. Slowackiego 173, 80-298 Gdansk


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