[openstack-dev] [neutron] Neutron rolling upgrade - are we there yet?
akamyshnikova at mirantis.com
Thu Oct 15 07:56:52 UTC 2015
Thanks a lot for bringing up this theme! I'm interested in working on online
data migration in Mitaka.
3. Database migration
a. Online schema migration was done in Liberty release, any work left
The work here is finished. The only thing is that I'm aware of is some
extra tests https://review.openstack.org/#/c/220091/. But this needs some
Alembic changes. All main functionality is implemented.
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
Unfortunately sometimes we may need such changes, despite we always tried
to avoid it. As plugins were moved out of Neutron it can be easier now, but
I'm still not sure we can have restriction.
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.
On Wed, Oct 14, 2015 at 9:27 PM, Dan Smith <dms at danplanet.com> wrote:
> > 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.
> Glad to see this work really picking up steam in other projects!
> > 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.
> I'll just point to this:
> and if you go check the logs for the partial-ncpu job, you'll see
> something like this:
> nova.compute.rpcapi Automatically selected compute RPC version 4.5
> from minimum service version 2
> I think that some amount of RPC pinning is probably going to be required
> for most people in most places, given our current model. But I assume
> the concern is around requiring this to be a manual task the operators
> have to manage. The above patch is the first step towards nova removing
> this as something the operators have to know anything about.
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev