This is needed because we're changing up some things in devstack, and
this ensures the pike defaults don't flip the deployment mode mid way
through an ocata upgrade.
Change-Id: I5aa1e3017365df120fa8c8ea676c63ddf99f21b4
This allows the use of LIBS_FROM_GIT in upgrade testing which will
give you the latest versions of libs from branches on the target as
well as the base.
Change-Id: I33c3dcdada6f5ef7b042ab8c2217ae8eddc951e3
When we do an upgrade, there may be new rpms/debs that may be
needed. For example, Swift does not have liberasurecode1 in
stable/liberty as the older pyeclib downloads, compiles and
installs things it needs. However the newer pyeclib does not
and the devstack master has been updated to install newer
items needed by pyeclib in:
Idbc2ca3f677f1b8153ebf3a5912f4354525a55c7
So when we do an upgrade, we should run install_prereqs.sh
from the new devstack to lay down the new dependencies.
Change-Id: Ied844017732461661e3c24e2ce38b413c881bea9
pip constrains is from requirements repo, but change in devstack
I42e981c8c5ce1b8a57b9f6cce213065c72d6af11a removed the requirements
clone from install_infra, causing the grenade "pip_install -U pbr" fail.
Make changes for grenade accordingly.
Change-Id: Ie228bd9399c5cc9341cc5503f02df90eb42d851f
Closes-bug: #1487259
In devstack openrc -> stackrc -> functions
I think it's fair to say nobody is really thinking about idempotency
when they write these rc files; it's assumed they're sourced once
per-run. I3ca4e576aa3fb8992c08ca44900a8c53dd4b4163 is an example of
this.
Reduce some of the duplicate imports here by just importing the
top-level (either openrc if that's wanted, or stackrc)
Change-Id: I6fbae12f950a03afab39f341132746d3db9f788c
Commit 2f0fd969ff added another
sourcing of stackrc in a cleaner place but did not remove the one
that followed a few lines later.
Change-Id: I4ddbdc5f3fec38f317e9b7cf5fa5ed6e29bfa134
Otherwise we get the error:
build_wheels.sh: line 61: pip_install: command not found
Since the grenade functions do not have pip_install
Change-Id: I8b0ad682203f77f68a03b9b7f56624df6d15ac50
Populate ADDITIONAL_VENV_PACKAGES on target side so venvs get
the packages they need.
Depends-On: I9cf298b936fd10c95e2ce5f51aab0d49d4b7f37f
Change-Id: Icc324fe6b0a8464027a624f9773030d08ca7c176
There were a remarkable number of scripts that we ran during the
target setup phase, that all boiled down to very small
activities.
- upgrade-devstack - copied 1 file
- upgrade-infra - cloned gr
- upgrade-oslo - actually *did nothing* (now that we install
libraries from pypi)
Consolidating them all into a unified prep-target makes understanding
what's happening on the target setup simpler.
Change-Id: I0a1a41714fd9749857ccfc0825414f331f44ec2a
This refactor's the grenade code to remove the copy/pasted
functions-common from devstack and instead use the functions from
TARGET_DEVSTACK. In order to accomplish this we need to refactor when
the devstack trees are pulled, so that we always pull both the base
and target devstack trees *extremely* early.
We also need to include a small number of functions (mostly related to
git) in grenade to be able to bootstrap these trees. This is done in
the inc/bootstrap tree.
There are some slightly unrelated function moves into inc/upgrade to
consolidate all the upgrade functions which were scattered through the
codebase for clarity. inc/* will be the contract library interfaces
out of grenade (mirroring devstack).
To do this grenaderc has to be split between variables which can be
set without devstack functions, and variables we compute later. These
later variables will be moved into project specific directories based
on the plugin plan.
Change-Id: I1a2d1a1fed7858c4f3b51a19be2d12cc2d260a24
* Build a wheel cache for the target environment
* Change the target ervice etups to use the new virtual-env
interface stack_service_install(): keystone, glance, cinder, nova,
swift, ironic, ceilometer
Change-Id: I1c0bf73d30ec138f2a8321b656c664770be571a7
* Source target DevStack's functions in upgrade scripts to match what the
project config functions expect.
* Source target DevStack's lib/tls in upgrade scripts that source
target's lib/keystone (is_ssl_enabled_service())
Change-Id: Iab78d1efb7e40a3a67408f6e9a071723a3e931ff
stop-base already stop services, so don't need to do it again in
upgrade-nova. This is needed So we can keep the old nova-compute up for
rolling upgrade testing. Instead of killing the entire screen process
kill all the services inside of it.
stop-base is the preferred place to manage the stop logic, because it
has access to the base devstack's stop-* commands.
Change-Id: Ifa2b6305f1f6bbe41407ca12a0f3cbc99b09f301
Use the Grenade devstack.localrc.* files as the 'default' for DevStack
by pre-pending them to the devstack-vm-gate.sh generated localrc.
devstack.localrc is now appended to the combined DevStack localrc
to still allow it to be the final config. Normally this will be empty.
Change-Id: I18cb963c4baeeeb447bcb1436521100f1372882a
Paths get stuffed in the database so rather than rewrite them
just leave the data in-place for both versions. This is how
real upgrades are likely to be done anyway...
Change-Id: I3610d93227b54d4c2f5c832478e7d23afe1bd173
Sean Dague