WikiSponsors
SDB:DevStack
tagline: From openSUSE
Contents |
[edit] Using DevStack on openSUSE
Starting with Grizzly, DevStack fully supports openSUSE (12.2 or higher). There is no openSUSE support in the stable/diablo, stable/essex and stable/folsom branches.
You might want to take a look at this upstream guide for DevStack if using DevStack for the first time. The configuration hinted below is taken from there.
[edit] Preliminary notes
A few notes worth mentioning before you use DevStack:
- Using DevStack will install packages and change some configuration bits, so it is recommended to either do this in a VM, or on a test machine you don't care much about.
- Only stable versions of openSUSE are officially supported. Running DevStack on Factory should work, but you'll need to use FORCE=yes when executing ./stack.sh.
- DevStack expects to be run as non-root. If you run ./stack.sh as root, it will create a stack user and run again as that user.
- DevStack will not update git checkouts of the code after the first checkout is done, unless RECLONE=yes is used.
- A full DevStack run can last up to 20 minutes.
[edit] Configuration
The configuration of DevStack is done via simple environment variables that you set in localrc. You can look at stackrc to see some of the variables that can be set. Here is a useful subset of variables:
- DEST: where DevStack will put its files (git checkouts, and more). Defaults to /opt/stack.
- ENABLED_SERVICES: the services that will be configured and run by DevStack. See the README to learn how to enable/disable some services (the disable_service and enable_service are one way of doing this). If you don't know what services you want, the default value should be good enough.
- *_PASSWORD: a set of variables to configure the password for different services. If they are not set, DevStack will prompt you to get values.
- LOGFILE: log the output to the specified file, in addition to the output getting printed. A timestamp will be appended to the given name, so that a successive run of DevStack don't overwrite the log file.
- IMAGE_URLS: a comma-separated list of images to upload to glance. By default, the CirrOS image is uploaded.
[edit] Step-by-step guide
First, install git:
zypper --non-interactive install git-core
Then, get the DevStack code:
git clone https://github.com/openstack-dev/devstack.git cd devstack
Create a minimal configuration:
echo ADMIN_PASSWORD=password > localrc echo MYSQL_PASSWORD=password >> localrc echo RABBIT_PASSWORD=password >> localrc echo SERVICE_PASSWORD=password >> localrc echo SERVICE_TOKEN=tokentoken >> localrc echo FLAT_INTERFACE=br100 >> localrc echo LOGFILE=\$DEST/logs/stack.sh.log >> localrc
And run it:
./stack.sh
It will ask you for the root password at first (via sudo), or if you are logged in as root, it will create a stack user first, before running the script as this user.
There will be a lot of output during the execution; you can ignore that if you don't want to see what DevStack is doing. Once it's done, it should output something similar to:
Horizon is now available at http://192.168.100.210/ Keystone is serving at http://192.168.100.210:5000/v2.0/ Examples on using novaclient command line is in exercise.sh The default users are: admin and demo The password: password This is your host ip: 192.168.100.210 stack.sh completed in 380 seconds.
You can now access the OpenStack web interface (horizon) or use the OpenStack command line tools to interact with OpenStack. To populate your environment with preconfigured variables to access OpenStack from the command line, simply source the openrc and the eucarc files:
source ./openrc source ./eucarc
You can also check the log of what DevStack did in $DEST/logs (assuming you set the $LOGFILE variable).
[edit] Example of command line tools usage
Here's a quick session showing the usage of command line tools:
$ source openrc
$ # let's list the images available in the cloud
$ glance image-list
+--------------------------------------+---------------------------------+-------------+------------------+----------+--------+
| ID | Name | Disk Format | Container Format | Size | Status |
+--------------------------------------+---------------------------------+-------------+------------------+----------+--------+
| 79d4de59-6037-4ddb-9e70-1cd5d8f71c10 | cirros-0.3.0-x86_64-uec | ami | ami | 25165824 | active |
| 0c7e2e3c-74eb-4cf3-9233-0a088c5d7a1f | cirros-0.3.0-x86_64-uec-kernel | aki | aki | 4731440 | active |
| fcecc879-869b-4313-b3c4-b0bb3404ebda | cirros-0.3.0-x86_64-uec-ramdisk | ari | ari | 2254249 | active |
+--------------------------------------+---------------------------------+-------------+------------------+----------+--------+
$ # let's boot an instance with one of the images
$ nova boot --image cirros-0.3.0-x86_64-uec --flavor m1.tiny cirros-test
+------------------------+--------------------------------------+
| Property | Value |
+------------------------+--------------------------------------+
| OS-DCF:diskConfig | MANUAL |
| OS-EXT-STS:power_state | 0 |
| OS-EXT-STS:task_state | scheduling |
| OS-EXT-STS:vm_state | building |
| accessIPv4 | |
| accessIPv6 | |
| adminPass | JBQyHuvHpg8a |
| config_drive | |
| created | 2012-12-20T17:59:21Z |
| flavor | m1.tiny |
| hostId | |
| id | 78d93752-a14c-4cb1-8aea-a97b2b40259c |
| image | cirros-0.3.0-x86_64-uec |
| key_name | None |
| metadata | {} |
| name | cirros-test |
| progress | 0 |
| security_groups | [{u'name': u'default'}] |
| status | BUILD |
| tenant_id | 21896ae22a1042b49e24ea7beb5cdb5e |
| updated | 2012-12-20T17:59:22Z |
| user_id | 8250ba978fe547e9bec9024b4708e62b |
+------------------------+--------------------------------------+
$ # now, what instances are in our cloud?
$ nova list
+--------------------------------------+-------------+--------+------------------+
| ID | Name | Status | Networks |
+--------------------------------------+-------------+--------+------------------+
| 78d93752-a14c-4cb1-8aea-a97b2b40259c | cirros-test | BUILD | private=10.0.0.2 |
+--------------------------------------+-------------+--------+------------------+
$ # hrm, the one that we started is building. Let's wait a bit and then check again...
$ nova list
+--------------------------------------+-------------+--------+------------------+
| ID | Name | Status | Networks |
+--------------------------------------+-------------+--------+------------------+
| 78d93752-a14c-4cb1-8aea-a97b2b40259c | cirros-test | ACTIVE | private=10.0.0.2 |
+--------------------------------------+-------------+--------+------------------+
$ # there we are, it's running!
[edit] Automatically running tasks after a successful stack.sh
DevStack will automatically run local.sh if it exists after ./stack.sh completed successfully. This can be used to do some additional configuration of OpenStack (uploading keypairs, creating new flavors, etc.), for instance. See the local.sh example for more details.
[edit] Seeing the output of OpenStack services
DevStack starts the OpenStack services in a screen session. You can simply use ./rejoin-stack.sh to attach to the screen session. Each OpenStack service has its own window in the screen session, so it's easy to see what's going on for a specific service, but also to stop/start a service again (don't be afraid of Ctrl-C).
[edit] Stopping DevStack
Simply run ./unstack.sh to kill all the OpenStack processes. You can pass the --all parameter to also stop services that were started by DevStack.
[edit] Following runs
Following runs of ./stack.sh will still execute the whole script. The rationale is that this will force the latest configuration of the OpenStack deployment, as wanted by DevStack. Obviously, following runs won't reinstall the packages.
Please note that following runs of DevStack will not update the OpenStack code to latest git. This enables the use of DevStack against specific versions of the code. If you want to update to the latest git, you shall do this manually with git in each of the git checkouts that are in /opt/stack (or $DEST, if you changed it in localrc), or run ./stack.sh with RECLONE=yes.
[edit] Using DevStack on SLE
While SLE is not officially supported, DevStack should mostly work well with an up-to-date SLE11 SP2. You will need to make sure you have all the required packages available somehow, though, as some of them are not shipped as part of SLE. You will also likely hit a few roadbumps here and there, but they shouldn't be hard to fix (it's a shell script, after all).
If you still want to go ahead with DevStack on SLE, just follow the instructions for openSUSE: they should work for SLE too.
[edit] Testing a patch / Using a specific branch of some OpenStack component
The main point of DevStack is to be able to test some experimental OpenStack code. After the first DevStack run, there will be git checkouts of the code for the OpenStack components that are configured to be used in /opt/stack (or $DEST, if you changed it in localrc).
To test a patch or use a specific branch for an OpenStack component, simply change the code in /opt/stack and run ./stack.sh again.
[edit] FAQ
I can't start ./stack.sh again, it warns me about some screen that is running.
Simply call ./unstack.sh to completely kill the currently running devstack deployment.
I can't access the dashboard (or any other services) after running ./stack.sh
Make sure your firewall is allowing access to the ports, or simply disable your firewall if you're in a secure environment.
I have another issue.
You can contact Vincent if you think it's an openSUSE-specific issue. Otherwise, please file a bug upstream.