If the user had oslo.config installed prior to us setting up the
oslo.config out of git they can get themselves into this very funny
situation where pip doesn't see oslo.config 1.1.x, however some
packages might. This manifests itself as a user error trying to
start nova-api which uses DeprecatedOption, not in oslo.config 1.1.x
Because of the funny state pip is in, you can't uninstall oslo.config.
So in these situations, if we see old oslo.config in the filesystem,
pip install / uninstall it to ensure that everyone ends up using the
git version instead.
To reduce the amount of user confusion, do this on every
install_oslo for a while, which we can purge after Havana ships.
Change-Id: If92073be5a431840701c952a194e63a7c452c9ca
Install a known working recent version of pip that handles installation
dependencies more correctly than before. Extract to a separate script
so it can be used apart from stack.sh.
* Install distro setuptools if it not already present
* Install pip from source tarball as get-pip.py proved to be unreliable
* Remove python-distribute and python-pip from all prereq files,
move python-setuptools to 'general'
* Remove the earlier unfubar_setuptppls() call that attenpted to fix this
* Only update requirements.txt when no changes in repo
Tested on Precise, F18 and CentOS6.
* Fedora and RHEL allow pip to install packages ON TOP OF RPM-installed
packages. THIS IS BROKEN. And is one reason we have to be so picky
about order and so forth.
Change-Id: Ibb4b42119dc2e51577c77bbbbffb110863e5324d
It turns out our fix for package madness breaks when running on
xenserver. Put in a simple exclusion for that case until we figure out a
more total and systemic solution to everyone's problems.
Change-Id: I491917015337f83206937c53949a62aa63f4679f
Partial-Bug 1207402
This patch executes Neutron DB migrations (based on alembic)
before starting the Neutron services, similar to what happens
for most of other openstack projects managed by devstack.
This will ensure devstack always creates correctly version-stamped
Neutron databases.
Change-Id: Ia941c426a1563bcc4cb5eae64ea30c0bf7677220
Add an ability to ask keystone about users and groups
through keystoneclient in cinder.
blueprint volume-acl
Change-Id: Ice261e9709833d057722b4f13c404df54e10b204
We've agreed that we should be using global requirements, so
force projects to be updated to global requirements before we
test them.
Co-Authored-With: Monty Taylor <mordred@inaugust.com>
Change-Id: I0652f639673e600fd7508a9869ec85f8d5ce4518
The ML2 code in devstack was not correctly configuring the mechanism_drivers
when asked to do so. This corrects the typo in the variable assignment, and
also actually sets these in the plugin configuration file.
Fixes bug 1208557
Change-Id: I3746ca099f45d44dcf1cc2ca1c3726745b8e8a1d
We have some complex logic in here to try to do the right things with
the requirements before doing the install of the package which still
winds up being wrong in some cases. Since having written this code,
we've learned that the logic we're trying to achieve is actually what
pip install -e does. So just use that. We have to follow up with a chown
of the resulting egg-info directory, because the sudo command will cause
it to be written by root, which prevents subsequent commands from
operating without privilege in the directory.
Change-Id: Iffd068c94ef84475ebb30758bcf612075d225bea
Adjust DevStack to the current DIB's naming to kernel/ramdisk.
BM_HOST_CURRENT_KERNEL is removed since the kernel is extracted from
a diskimage with the ramdisk and the host's kernel is not used.
BM_BUILD_DEPLOY_RAMDISK is added to control whether use DIB or not.
If you set BM_BUILD_DEPLOY_RAMDISK=False, you must BM_DEPLOY_KERNEL
and BM_DEPLOY_RAMDISK to point existing deploy kernel/ramdisk.
Fixes bug 1207719
Change-Id: I62af0b1942b07ac12665c0ed3619d64c1cccbe1f
when ./stack.sh encounters error, the output may look like this:
[ERROR] ./stack.sh:698 nova-api did not start
The source filename is wrong. Actually, it should be like this:
[ERROR] /<path_of_devstack>/lib/nova:698 nova-api did not start
stack.sh uses bash as interpreter, which define "Shell Variables"
BASH_SOURCE:
An array variable whose members are the source filenames where
the corresponding shell function names in the FUNCNAME array
variable are defined. The shell function
${FUNCNAME[$i]} is defined in the file ${BASH_SOURCE[$i]}
and called from ${BASH_SOURCE[$i+1]}.
The function "err" is called by function "die" ( and "err_if_not_set",
and "err_if_not_set" is not used at all). ${BASH_SOURCE[2]} will
ignore the deepest two call entries, which corresponding to the shell
functions: "err" and "die".
In one sentence, this change will print the source filename where the
function is defined and exits via function "die".
Fixes bug #1207658
Change-Id: I2aa6642c5cf4cfe781afe278b3dec3e7cba277fa
Call trace can help user to locate problem quickly.
stack.sh uses bash as interpreter, which defines a series of
"Shell Variables":
BASH_SOURCE:
An array variable whose members are the source filenames
BASH_LINENO:
An array variable whose members are the line numbers in source
files where each corresponding member of FUNCNAME was invoked.
FUNCNAME:
An array variable containing the names of all shell functions
currently in the execution call stack.
run "man bash" and search the variable name to get detailed info.
In function backtrace, it gets the call deepth from
${#BASH_SOURCE[@]}, then print the call stack from top to down.
In function die, backtrace is called with parameter "2" to ignore
the call trace of function "die" and "backtrace".
I add a broken function in lib/database, and call it in stack.sh,
the output looks like this:
[Call Trace]
./stack.sh:104:broken
/home/kui/osd/devstack/lib/database:24:die
[ERROR] ./stack.sh:24 It is broken
Fixes bug # 1207660
Change-Id: I04d0b3ccf783c769e41582c20f48694c19917334
When using the fake VIRT_DRIVER, we can launch an arbitrary number of
instances, the next step for performance testing is running an arbitrary
number of n-cpus. This can be done with the following settings in your localrc
VIRT_DRIVER=fake
NUMBER_FAKE_NOVA_COMPUTE=50
This can be used for things like measuring load from n-cpu's periodic tasks.
Change-Id: I40e0f05374e2c10c48ea6b8816ef6e7609b3dc80
As part of bp:tempest-repo-restructure, the scenario directory is added and
scenario tests are moved there. The tempest test sample should be updated
in README.md.
Fixes bug #1207109
Change-Id: I25067e4b42697985e8f4b808fad5eb801c805f9f
DHCP, L3 and Metadata agents' config files no longer need to
duplicate this info; it's available in neutron.conf
Change-Id: I7bea25d1c2b9249ddacce3f4638f7a8ed4f43197
* Adds support for vmdk files as glance images in upload_image function
* Set default image url to use for vsphere driver in stackrc
* Now using a more stable url
Change-Id: If6d45bc8dfd3c812ded5e1bcf69ad7ebd9b64f34
This commit will correctly set the tempest output logging to dump
all of tempest logs into a tempest.log file in
$DEST/tempest/tempest.log. This will also fix the logging for
tempest in the gate so it will no longer print every log message on
the console.
Fixes bug 1207066
Change-Id: I91f2ee781c4a7a18c561ea3e3b26832b97431464
move the infrastructure projects to a dedicated lib/infra, which
gives us access to this during grenade upgrade tests.
Change-Id: I1e832792b61d41ad290b4b2ab26fe664e710cebd
