OpenDev Migration Patch
This commit was bulk generated and pushed by the OpenDev sysadmins as a part of the Git hosting and code review systems migration detailed in these mailing list posts: http://lists.openstack.org/pipermail/openstack-discuss/2019-March/003603.html http://lists.openstack.org/pipermail/openstack-discuss/2019-April/004920.html Attempts have been made to correct repository namespaces and hostnames based on simple pattern matching, but it's possible some were updated incorrectly or missed entirely. Please reach out to us via the contact information listed at https://opendev.org/ with any questions you may have.
|6 days ago|
|data||1 year ago|
|doc/source||1 year ago|
|inc||1 month ago|
|playbooks/legacy||6 days ago|
|projects||4 months ago|
|tools||1 month ago|
|.gitignore||1 year ago|
|.gitreview||6 days ago|
|.zuul.yaml||6 days ago|
|HACKING.rst||3 years ago|
|LICENSE||6 years ago|
|PLUGINS.rst||7 months ago|
|README.rst||1 month ago|
|TODO.rst||5 years ago|
|cache_git.sh||3 years ago|
|clean.sh||7 months ago|
|devstack.local.conf.base||2 years ago|
|devstack.local.conf.target||1 year ago|
|devstack.localrc.base||2 years ago|
|devstack.localrc.example||2 years ago|
|devstack.localrc.target||2 years ago|
|functions||7 months ago|
|grenade.sh||7 months ago|
|grenaderc||1 month ago|
|prep-target||2 years ago|
|run_resource.sh||4 years ago|
|save-state||2 years ago|
|setup-grenade||3 years ago|
|setup.cfg||3 years ago|
|setup.py||3 years ago|
|test-requirements.txt||1 year ago|
|tox.ini||7 months ago|
|upgrade-tempest||2 years ago|
Grenade is an OpenStack test harness to exercise the upgrade process between releases. It uses DevStack to perform an initial OpenStack install and as a reference for the final configuration. Currently Grenade can upgrade Keystone, Glance, Nova, Neutron, Cinder, Swift, and Ceilometer in their default DevStack configurations.
Grenade has the following goals:
Grenade works under the following theory of upgrade.
New code should work with old configs
The upgrade process should not require a config change to run a new release. All config behavior is supposed to be deprecated over a release cycle, so that upon release new code works with the last releases configs. Those configs may create deprecation warnings which need to be addressed before the next release, but they should still work and largely have the same behavior.
New code should need nothing more than 'db migrations'
Clearly the release of new code may include new database models. Standard upgrade procedure is to turn off all services that touch the database, run the db migration script, and start with new code.
Resources created by services before upgrade, should still be there after the system is upgraded
When upgrading Nova you expect all your VMs to still function during the entire upgrade (whether or not Nova services are up). Taking down the control plane should not take down your VMs.
Any other required changes on upgrade are an exception and must be called out in the release notes.
Grenade supports per release specific upgrade scripts (from-juno, from-kilo). These are designed to support upgrades where additional manual steps are needed for a specific upgrade (i.e. from juno to kilo). These should be used sparingly.
The Grenade core team requires the following before landing these kinds of changes:
While we expect the various deployment projects within the OpenStack ecosystem, for example TripleO, Kolla, etc, to read the release notes of each project, it is good practice to communicate any exceptional upgrade changes made to Grenade to those teams directly or at least via the openstack-dev mailing list.
Grenade is now running on every patch for projects that support upgrade. Gating Grenade configurations exist for the following in OpenStack's CI system.
The grenade.sh script attempts to be reasonably readable, so it's worth looking there to see what's really going on. This is the super high level version of what that does.
Grenade has two DevStack installs present and distinguished between then as 'base' and 'target'.
Grenade creates a set of directories for both the base and target OpenStack installation sources and DevStack:
$STACK_ROOT |- logs # Grenade logs |- save # Grenade state logs |- <base> | |- data # base data | |- logs # base DevStack logs | |- devstack | |- images # cache of downloaded images | |- cinder | |- ... | |- swift |- <target> | |- data # target data | |- logs # target DevStack logs | |- devstack | |- cinder | |- ... | |- swift
This is a non-exhaustive list of dependencies:
Get Grenade from GitHub in the usual way:
git clone https://git.openstack.org/openstack-dev/grenade
There is an optional setup-grenade script that is useful if you are running Grenade against a remote VM from a local laptop.
Grenade knows how to install the current master branch using the included
setup-grenade script. The arguments are the hostname of the target system that will run the upgrade testing and the user for the target system:
./setup-grenade [testbox [testuser]]
If you are running Grenade on the same maching you cloned to, you do not need to do this.
The Grenade repo and branch used can be changed by adding something like this to
If you need to configure your local devstacks for your specific environment you can do that by creating
devstack.localrc. This will get appended to the stub devstack configs for BASE and TARGET.
For instance, specifying interfaces for Nova is a common use of
grenade.sh for more details of the steps that happen from here.