History

Matt Thompson 092f606adc 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.

[1] http://docs.openstack.org/developer/neutron/devref/alembic_migrations.html

Change-Id: I1176b5fe12cad1ee732486ae179e76deea5623e1
Closes-Bug: #1486593

2015-09-03 05:45:35 +00:00

openstack_clients.yml

Updated master for new dev work - 15 Aug 2015

2015-08-15 13:44:00 +01:00

openstack_other.yml

Updated master for new dev work - 15 Aug 2015

2015-08-15 13:44:00 +01:00

openstack_services.yml

Update how neutron migrations are handled

2015-09-03 05:45:35 +00:00

python2_lxc.yml

Moved the playbook vars to defaults

2015-05-14 12:32:36 -05:00

readme.rst

Moved the playbook vars to defaults

2015-05-14 12:32:36 -05:00

readme.rst

Packages built by python from git

date: 2014-09-01 09:57
tags: python, pip, wheel, lxc, openstack, cloud, ansible
category: *nix

Packages Downloads and Installable

Any and all packages that need to be installed for this repository to work should be specified here in the, repo_packages directory. The files in this directory are given to the python wheel builder for construction.

Inside these files all download-able objects such as tar-balls and random files should also be specified. While the packaging roles may not be used to process these links the stated purpose of this directory is to have anything that is "installable" in a single location with the goal to allow for easily manipulation of requirements as they change.

NOTICE on items in this file:

If you use anything in the "*._git_install_branch" field that is not a TAG make sure to leave an in-line comment as to "why".

For the sake of anyone else editing this file:

If you add clients to this file please do so in alphabetical order.
Every entry should be name spaced with the name of the client followed by an "_"

The basic structure of all of these files:

git_repo: string URI to the git repository to clone from.
git_fallback_repo: string URI to an alternative git repository to clone from when git_repo fails.
git_dest: string full path to place a cloned git repository. This will normally incorporate the repo_path variable for consistency purposes.
git_install_branch: string branch, tag or SHA of a git repository to clone into.
git_repo_plugins: list of hashes with keys: path, package | This is used to install additional packages which may be installable from the same base repository.