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 machineis
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 Devstackstackrcto pull RC1 branches of OpenStack Projects
Devstack contains a file calledstackrcthat is sourced by the mainstack.shscript to create your OpenStack environment. Thestackrcfile
contains environment variables that tellstack.shwhich 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:
stackrc before...
And here is what it should look like after you change the master branches to milestone-proposed branches appropriately:
stackrc after...
Setting Up Your Devstacklocalrcfor 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 yourlocalrcfile
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 yourlocalrcinstalled, it’s time to run the mainstack.shscript that will install OpenStack on your test machine.
It’s as easy as running thestack.shscript. 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.shscript to verify all went well:
jpipes@librebox:~/repos/devstack$ ./tools/info.sh
git|glance|milestone-proposed
git|horizon|milestone-proposed
git|keystone|milestone-proposed
git|nova|milestone-proposed
git|noVNC|master
git|python-keystoneclient|milestone-proposed
git|python-novaclient|milestone-proposed
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 NUMkey combination, whereNUMis the number of the screen window you see at the bottom of your console. Type<Ctrl>-a
dto detach from your screen session. The screenshot below shows what your screen session may look like. In the screenshot, I’ve hit<Ctrl>-a 4to switch to then-apiscreen
window which is showing the Nova API server daemon output.
screen session showing the Nova API server window...
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:
jpipes@uberbox:~/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.samplefile. You will see something like this:
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
# 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
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 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…
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
# 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
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.
jpipes@uberbox:~/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=Noption 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=2to
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
Great post Jay. Thanks very much for sharing.
[*]
Anne Gentle
Hi Jay, asking here since others may have the same question. When I scroll past line 46 in stackrc, I see the quantum service and quantum client listed and scrolling further, melange and tempest. Do I want a milestone-proposed branch from these projects as
well or do I stop editing at line 46?
Thanks for the write up, excited to try it out.
[*]
http://joinfu.com/Jay Pipes
Hi Anne!
You only need to set those to milestone-proposed if you are testing out Quantum and Melange. If you are, remember to add quantum and melange to your ENABLED_SERVICES, too!
ENABLED_SERVICES=”$ENABLED_SERVICES,quantum,melange”
-jay
[*]
Pingback:Community Weekly Review (Mar 23-30) » The OpenStack Blog
[*]
Beyounn
Hello,
This is very useful info. I just see the news that essex is justofficially released. Does it mean that the current master branch has full essex code already?
Thanks
Yi
[*]
http://joinfu.com/Jay Pipes
Yep, absolutely. In the spot in the article where you change master branches to milestone-proposed in the stackrc article, you can ignore change that to stable/essex instead of milestone-proposed. Or leave it at master to test the development trunk (Folsom
now).
best,
-jay
页:
[1]