commit 092f606adcd7120195e9a71afe80893a9d512f03
Author: Matt Thompson <email address hidden>
Date: Fri Aug 21 12:04:30 2015 +0100
Update how neutron migrations are handled
We're seeing some neutron db sync failures in master branch (liberty).
It looks like there may be a few issues with the way we're handling
migrations:
1. We're not capturing the correct information in the 'Check last DB
revision' task as the first line returned by 'neutron-db-manage
history' is a header (this also means that the 'Inspect on disk
neutron DB revision' task will never do what we intend).
2. We delegate 'Check last DB revision' to 'neutron_all' group, but in
an ideal world this is probably only necessary on 'neutron_server'.
3. When stopping neutron server to run 'Perform a Neutron DB Upgrade',
we're only stopping it on groups['neutron_server'][0], while all
other neutron server containers are up servicing requests.
4. Perform a db stamp, which doesn't appear to be necessary.
This change makes the following changes:
1. Bumps neutron SHA to include 43c00a9, which introduces new
--expand / --contract upgrade options (otherwise, you have to
specify liberty_expand@head / liberty_contract@head which may no
longer work when neutron gets bumped in the future)
2. Checks if migrations have previously run, and if not runs a 'neutron-db-manage upgrade heads'
3. If migrations have previously run:
a) it runs an online migration against expand alembic branch using 'neutron-db-manage upgrade --expand'.
b) it stops all neutron-server services
c) it runs an offline migration against contract alembic branch
using 'neutron-db-manage upgrade --contract'
d) it starts all neutron-server instances
4. It removes the temporary pin introduced in https://review.openstack.org/218572 as the SHA bump includes the
upstream fix https://review.openstack.org/218723
TODO: Currently, we upgrade expand and contract branches (shutting down neutron-server in the proceses), even if there are no pending migrations. We need to find a clean way to check what migration
we are on and compare to alembic HEADS file to see if we're up to
date. Unfortunately, 'neutron-db-manage current' doesn't indicate
which migration is in which alembic branch, so you would have to
further grep for each migration in the neutron migrations code to
determine the branch.
NOTE: Liberty introduces the split alembic branches for online/offline migrations, see [1] for more information.
Reviewed: https:/ /review. openstack. org/215584 /git.openstack. org/cgit/ stackforge/ os-ansible- deployment/ commit/ ?id=092f606adcd 7120195e9a71afe 80893a9d512f03
Committed: https:/
Submitter: Jenkins
Branch: master
commit 092f606adcd7120 195e9a71afe8089 3a9d512f03
Author: Matt Thompson <email address hidden>
Date: Fri Aug 21 12:04:30 2015 +0100
Update how neutron migrations are handled
We're seeing some neutron db sync failures in master branch (liberty).
It looks like there may be a few issues with the way we're handling
migrations:
1. We're not capturing the correct information in the 'Check last DB 'neutron_ server' ][0], while all
revision' task as the first line returned by 'neutron-db-manage
history' is a header (this also means that the 'Inspect on disk
neutron DB revision' task will never do what we intend).
2. We delegate 'Check last DB revision' to 'neutron_all' group, but in
an ideal world this is probably only necessary on 'neutron_server'.
3. When stopping neutron server to run 'Perform a Neutron DB Upgrade',
we're only stopping it on groups[
other neutron server containers are up servicing requests.
4. Perform a db stamp, which doesn't appear to be necessary.
This change makes the following changes:
1. Bumps neutron SHA to include 43c00a9, which introduces new contract@ head which may no
'neutron- db-manage upgrade heads'
'neutron- db-manage upgrade --expand'. /review. openstack. org/218572 as the SHA bump includes the /review. openstack. org/218723
--expand / --contract upgrade options (otherwise, you have to
specify liberty_expand@head / liberty_
longer work when neutron gets bumped in the future)
2. Checks if migrations have previously run, and if not runs a
3. If migrations have previously run:
a) it runs an online migration against expand alembic branch using
b) it stops all neutron-server services
c) it runs an offline migration against contract alembic branch
using 'neutron-db-manage upgrade --contract'
d) it starts all neutron-server instances
4. It removes the temporary pin introduced in
https:/
upstream fix https:/
TODO: Currently, we upgrade expand and contract branches (shutting down
neutron- server in the proceses), even if there are no pending
migrations. We need to find a clean way to check what migration
we are on and compare to alembic HEADS file to see if we're up to
date. Unfortunately, 'neutron-db-manage current' doesn't indicate
which migration is in which alembic branch, so you would have to
further grep for each migration in the neutron migrations code to
determine the branch.
NOTE: Liberty introduces the split alembic branches for online/offline
migrations, see [1] for more information.
[1] http:// docs.openstack. org/developer/ neutron/ devref/ alembic_ migrations. html
Change-Id: I1176b5fe12cad1 ee732486ae179e7 6deea5623e1
Closes-Bug: #1486593