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