FAQ Why did you do it this way?!
- Q: Can I use DevStack for production?
- A: No. We mean it. Really. DevStack makes some implementation choices that are not appropriate for production deployments. We warned you!
- Q: Why a shell script, why not chef/puppet/...
- A: The script is meant to be read by humans (as well as ran by computers); it is the primary documentation after all. Using a recipe system requires everyone to agree and understand chef or puppet.
- Q: Why not use Crowbar?
- A: DevStack is optimized for documentation & developers. As some of us use Crowbar for production deployments, we hope developers documenting how they setup systems for new features supports projects like Crowbar.
- Q: I'd like to help!
- A: That isn't a question, but please do! The source for DevStack is github and bug reports go to LaunchPad. Contributions follow the usual process as described in the OpenStack wiki even though DevStack is not an official OpenStack project. This site is housed in the CloudBuilder's github in the gh-pages branch.
- Q: Why not use packages?
- A: Unlike packages, DevStack leaves your cloud ready to develop - checkouts of the code and services running in screen. However, many people are doing the hard work of packaging and recipes for production deployments. We hope this script serves as a way to communicate configuration changes between developers and packagers.
- Q: Why isn't $MY_FAVORITE_DISTRO supported?
- A: DevStack is meant for developers and those who want to see how OpenStack really works. DevStack is known to run on the distro/release combinations listed in
README.md. DevStack is only supported on releases other than those documented in README.md on a best-effort basis.
- Q: What about Fedora/RHEL/CentOS?
- A: Fedora 16 is supported via rpm dependency files and specific checks in
stack.sh. Support will follow the pattern set with the Ubuntu testing, i.e. only a single release of the distro will receive regular testing, others will be handled on a best-effort basis.
- Q: Are there any differences between Ubuntu and Fedora support?
- A: LXC support is not complete on Fedora; Quantum is not fully supported on Fedora 16 due lack of OpenVSwitch packages.
- Q: Can DevStack handle a multi-node installation?
- A: Indirectly, yes. You run DevStack on each node with the appropriate configuration in
localrc. The primary considerations are turning off the services not required on the secondary nodes, making sure the passwords match and setting the various API URLs to the right place.
- Q: How can I document the environment that DevStack is using?
- A: DevStack includes a script (
tools/info.sh) that gathers the versions of the relevant installed apt packages, pip packages and git repos. This is a good way to verify what Python modules are installed.
- Q: How do I turn off a service that is enabled by default?
- A: Services can be turned off by adding
disable_service xxx to localrc (using n-vol in this example):
disable_service n-vol
- Q: Is enabling a service that defaults to off done with the reverse of the above?
- A: Of course!
enable_service qpid
- Q: How do I run a specific OpenStack milestone?
- A: OpenStack milestones have tags set in the git repo. Set the appropriate tag in the
*_BRANCH variables in localrc. Swift is on its own release schedule so pick a tag in the Swift repo that is just before the milestone release. For example:
GLANCE_BRANCH=stable/essex
HORIZON_BRANCH=stable/essex
KEYSTONE_BRANCH=stable/essex
NOVA_BRANCH=stable/essex
GLANCE_BRANCH=stable/essex
QUANTUM_BRANCH=stable/essex
SWIFT_BRANCH=1.4.8
- Q: Why not use
tools/pip-requires to grab project dependencies?
- The majority of deployments will use packages to install OpenStack that will have distro-based packages as dependencies. DevStack installs as many of these Python packages as possible to mimic the expected production environemnt.
- Q: What can I do about RabbitMQ not wanting to start on my fresh new VM?
- A: This is often caused by
erlang not being happy with the hostname resolving to a reachable IP address. Make sure your hostname resolves to a working IP address; setting it to 127.0.0.1 in /etc/hosts is often good enough for a single-node installation. And in an extreme case, use clean.sh to eradicate it and try again.