SDB:DevStack
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.
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 point you to ./tools/create-stack-user.sh, which can be run with sudo to create a stack user. (Older devstack versions would attempt to create the user for you.)
- 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, longer if additional services are configured.
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.
Step-by-step guide
First, install git:
zypper --non-interactive install git-core
On Leap 42.3 and other releases you may also need to install pip
zypper --non-interactive install python-pip
Then, get the DevStack code:
git clone https://github.com/openstack-dev/devstack.git cd devstack
Create a minimal configuration:
echo "[[local|localrc]]" > local.conf echo ADMIN_PASSWORD=password >> local.conf echo MYSQL_PASSWORD=password >> local.conf echo RABBIT_PASSWORD=password >> local.conf echo SERVICE_PASSWORD=password >> local.conf echo SERVICE_TOKEN=tokentoken >> local.conf echo FLAT_INTERFACE=br100 >> local.conf echo LOGFILE=\$DEST/logs/stack.sh.log >> local.conf
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:
This is your host IP address: 192.168.100.210 This is your host IPv6 address: ::1 Horizon is now available at http://192.168.100.210/dashboard Keystone is serving at http://192.168.100.210/identity/ The default users are: admin and demo The password: password DevStack Version: pike
You can now access the OpenStack web interface (horizon) or use the OpenStack command line tools to interact with OpenStack. To use the command line tools, simply source the openrc file:
source ./openrc
(Note that in Liberty and earlier you could also source the eucarc file to populate with some preconfigued variables for EC2.)
You can also check the log of what DevStack did in $DEST/logs (assuming you set the $LOGFILE variable).
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!
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.
Seeing the output of OpenStack services
For recent DevStack versions the OpenStack services are controlled through systemctl. You can easily see a list of services controlled by DevStack by running:
systemctl list-unit-files | grep devstack
In older versions (and still for some services that haven't updated), 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).
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.
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.
Using PostgreSQL as database backend
DevStack supports both MySQL/MariaDB and PostgreSQL as database backend. By default, MySQL is used (and MariaDB can be used by simply installing MariaDB before running DevStack). To switch to PostgreSQL, the following lines can be added to localrc:
disable_service mysql enable_service postgresql
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.
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.
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.