openstack开发部署环境
http://www.joinfu.com/2012/03/testing-essex-rc1-with-devstack-and-tempest/
Testing Essex RC1 with Devstack and Tempest
This past week,thefirstreleasecandidatesof a number of OpenStack projects was released. From this point until theOpenStack Design Summit, we are pretty much focused on testing the release candidates. One way you can help out is to test the release candidate code, and this article will walk you through doing that with the Devstack and Tempest projects.
Setting up an OpenStack Essex RC1 Environment with Devstack
Before you test, you need an OpenStack environment. The easiest way to get an OpenStack environment up and running on a single machine[1]is to useDevstack. To get a version of Devstack that is designed to run against the release candidate branches of the OpenStack projects, simply clone the main repo of Devstack, like so:
git clone git://github.com/openstack-dev/devstack
Setting Up Your Devstackstackrc
to pull RC1 branches of OpenStack Projects
Devstack contains a file calledstackrc
that is sourced by the mainstack.sh
script to create your OpenStack environment. Thestackrc
file
contains environment variables that tellstack.sh
which repositories and branches of OpenStack projects to clone. We will need to change the branches in the stackrc file from master to milestone-proposed to grab
the release candidate branches. You will want to change the target branches for Nova, Glance, Keystone, and their respective client libraries. Here is what the default stackrc will look like:
And here is what it should look like after you change the master branches to milestone-proposed branches appropriately:
Setting Up Your Devstacklocalrc
for Running Tempest
There are a couple things you will want to put into your Devstack’s localrc file before actually creating your OpenStack environment for testing with Tempest. So, open up your editor of choice and make sure that you have at least the following in yourlocalrc
file
in Devstack’s root source directory. (If the file does not exist, simply create it)
API_RATE_LIMIT=False MYSQL_PASSWORD=pass RABBIT_PASSWORD=pass SERVICE_PASSWORD=pass ADMIN_PASSWORD=pass SERVICE_TOKEN=servicetoken
The first line instructs devstack to disable the default ratelimit middleware in the Nova API server. We need to do this because Tempest issues hundreds of API requests in a short amount of time as it runs its tests. If we don’t do this, Tempest will take a much longer time to run and you will likely get test failures with a bunch of overLimitFault messages.
The other lines simply set the various passwords to an easy-to-remember password “pass” for testing. And the final line is needed currently to set up some services but should be deprecated fairly soon…
Installing the OpenStack RC1 Environment
Now that you’ve got your devstack scripts cloned and yourlocalrc
installed, it’s time to run the mainstack.sh
script that will install OpenStack on your test machine.
It’s as easy as running thestack.sh
script. After running &mdash and be patient, on a first run the script can take ten or more minutes to complete — you will see a bunch of output and then something like this:
$> ./stack.sh <snip lots and lots of output...> The default users are: admin and demo The password: pass This is your host ip: 192.168.1.98 stack.sh completed in 517 seconds.
At this point, feel free to run theinfo.sh
script to verify all went well:
[email protected]:~/repos/devstack$ ./tools/info.sh git|glance|milestone-proposed[f4a7035] git|horizon|milestone-proposed[97fc4f8] git|keystone|milestone-proposed[f3ce326] git|nova|milestone-proposed[4e02ba1] git|noVNC|master[22b9a75] git|python-keystoneclient|milestone-proposed[bf13df1] git|python-novaclient|milestone-proposed[aa0e87f] os|vendor=Ubuntu os|release=11.10 pkg|pep8|0.6.1-2ubuntu1 pkg|pylint|0.23.0-1 pkg|python-pip|1.0-1 <snip a whole bunch of package versions...> pip|pika|0.9.5 localrc|API_RATE_LIMIT=False localrc|HOST_IP=192.168.1.98 localrc|SERVICE_TOKEN=servicetoken
At this point, you have a fully functioning OpenStack RC1 environment. You can do the following to check into the logs (actually just the daemon output in a screen window):
$> screen -x
Switch screen windows using the<Ctrl>-a NUM
key combination, whereNUM
is the number of the screen window you see at the bottom of your console. Type<Ctrl>-a
d
to detach from your screen session. The screenshot below shows what your screen session may look like. In the screenshot, I’ve hit<Ctrl>-a 4
to switch to then-api
screen
window which is showing the Nova API server daemon output.
Testing the OpenStack Essex RC1 Environment with Tempest
TheTempestproject is an integration test suite for the OpenStack projects. Personally, in my testing setup at home, I run Tempest from a different machine on my local network than the machine that I run devstack on. However, you are free to run Tempest on the same machine you just installed Devstack on.
Grab Tempest by cloning the canonical repo:
$> git clone git://github.com/openstack/tempest
Once cloned, change directory into tempest.
Creating Your Tempest Configuration File
Tempest needs some information about your OpenStack environment to run properly. Because Tempest executes a series of API commands against the OpenStack environment, it needs to know where to find the main Compute API endpoint or where it can find the Keystone server that can return a service catalog. In addition, Tempest needs to know the UUID of the base image(s) that Devstack downloaded and installed in the Glance server.
Create the tempest configuration file by copying the sample config file included in Tempest$tempest_dir/etc/tempest.conf.sample
.
$> cp etc/tempest.conf.sample etc/tempest.conf
Next, you will want to query the Glance API server to get the UUID of the base AMI image used in testing. To do this, issue a call like so:
[email protected]:~/repos/tempest$ glance -I admin -K pass -T admin -N http://192.168.1.98:5000/v2.0 -S keystone index | grep ami | cut -f1 | awk '{print $1}' 99a48bc4-d356-4b4d-95d4-650f707699c2
Of course, you will want to replace the appropriate parts of the call above with your own environment. In my case above, my devstack environment is running on a host 192.168.1.98 and I’m accessing Glance with an “admin” user in an “admin” tenant with a password of “pass”. Copy the UUID identifier of the image that is returned from the command above (in my case, that UUID is99a48bc4-d356-4b4d-95d4-650f707699c2).
Now go ahead and open up the configuration file you just created by copying thetempest.conf.sample
file. You will see something like this:
[identity] use_ssl=False host=127.0.0.1 port=5000 api_version=v2.0 path=tokens user=admin password=admin-password tenant_name=admin-project strategy=keystone [compute] # Reference data for tests. The ref and ref_alt should be # distinct images/flavors. image_ref=e7ddc02e-92fa-4f82-b36f-59b39bf66a67 image_ref_alt=346f4039-a81e-44e0-9223-4a3d13c92a07 flavor_ref=1 flavor_ref_alt=2 ssh_timeout=300 build_interval=10 build_timeout=600 catalog_type=compute create_image_enabled=true resize_available=true [image] username=admin password=******** tenant=admin auth_url=http://localhost:5000/v2.0
You will want to replace the various configuration option values with ones that correspond to your environment. For the image_ref and image_ref_alt values in the [compute] scetion of the config file, use the UUID you copied from above.
Here is what my fully-replaced config file looks like. Keep in mind, my Devstack environment is running on 192.168.1.98. I’ve highlighted the values different from the sample config…
[identity] use_ssl=False host=192.168.1.98 port=5000 api_version=v2.0 path=tokens user=demo password=pass tenant_name=demo strategy=keystone [compute] # Reference data for tests. The ref and ref_alt should be # distinct images/flavors. image_ref=99a48bc4-d356-4b4d-95d4-650f707699c2 image_ref_alt=99a48bc4-d356-4b4d-95d4-650f707699c2 flavor_ref=1 flavor_ref_alt=2 ssh_timeout=300 build_interval=10 build_timeout=600 catalog_type=compute create_image_enabled=true resize_available=true [image] username = demo password = pass tenant= demo auth_url=http://192.168.1.98:5000/v2.0
Fire Away
The only thing left to do is fire Tempest at your OpenStack environment. Below, I’m executing Tempest in verbose mode.Nosetestsis our standard test runner.
[email protected]:~/repos/tempest$ nosetests -v tempest All public and private addresses for ... ok Providing a network type should filter ... ok <snip a whole bunch of tests> An access IPv6 address must match a valid address pattern ... ok Use an unencoded file when creating a server with personality ... ok Create a server with name parameter empty ... ok ---------------------------------------------------------------------- Ran 131 tests in 798.125s OK (SKIP=5)
After you’re done running Tempest — and hopefully everything runs OK — feel free to hit your Devstack Horizon dashboard and log in as your demo user. Unless you made some changes when installing Devstack above, your Horizon dashboard will be available athttp://$DEVSTACK_HOST_IP
.
If you encounter any test failures or issues, please be sure to log bugs for the appropriate project!
Known Issues
You can try running Tempest with the--processes=N
option which uses thenosetest
multiprocessing plugin. You might get a successful test run … but probably not
Likely, you will hit two issues: the first is that you will likely hit the quote limits for your demo user because multiple processes will be creating instances and volumes. You can remedy this by altering the quotas for the tenant you are running the compute tests with.
Secondly, you may run into error output that looks like this:
====================================================================== ERROR: An image for the provided server should be created ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/jpipes/repos/tempest/tempest/tests/test_images.py", line 38, in test_create_delete_image self.servers_client.wait_for_server_status(server['id'], 'ACTIVE') File "/home/jpipes/repos/tempest/tempest/services/nova/json/servers_client.py", line 147, in wait_for_server_status raise exceptions.BuildErrorException(server_id=server_id) BuildErrorException: Server 2e0b78fc-cc98-485b-8471-753778bee472 failed to build and is in ERROR status
And in your nova-compute log (or screen output) you might notice something like this:
libvirtError: operation failed: cannot restore domain 'instance-0000001f' uuid 2453b24b-87e1-4f85-9c25-ce3706a8c1d1 from a file which belongs to domain 'instance-0000001f' uuid deb8e941-4693-4768-90cc-03ad98444c85
I’ve not quite gotten to the bottom of this, but there seems to be a race condition that gets triggered in the Compute API when a similar request is received nearly simulataneously. I can reliably reproduce the above error by simply adding--processes=2
to
my invocation of Tempest. I believe there is an issue with the seeding of identifiers, but it’s just a guess. I still have to figure it out. But in the meantime, be aware of the issue.
1.You can certainly use devstack to install a multi-node OpenStack environment, but this tutorial sticks to a single-node environment for simplicity reasons.
This entry was posted on March 26, 2012, 8:36 pm and is filed underopenstack,Python,Testing,Web 2.0. You can follow any responses to this entry throughRSS 2.0. You canleave a response, ortrackbackfrom your own site.
-
Adrian Smith
-
Anne Gentle
-
http://joinfu.com/Jay Pipes
-
-
Pingback:Community Weekly Review (Mar 23-30) » The OpenStack Blog
-
Beyounn
-
http://joinfu.com/Jay Pipes
-