follow the usual process as described in the `OpenStack
wiki <http://wiki.openstack.org/HowToContribute>`__ even though
DevStack is not an official OpenStack project. This site is housed
in the CloudBuilder's
`github <http://github.com/cloudbuilders/devstack>`__ 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 and CentOS/RHEL are 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: Neutron is not fully supported prior to Fedora 18 due lack of
OpenVSwitch packages.
Q: How about RHEL 6?
A: RHEL 6 has Python 2.6 and many old modules packaged and is a
challenge to support. There are a number of specific RHEL6
work-arounds in ``stack.sh`` to handle this. But the testing on py26
is valuable so we do it...
Operation and Configuration
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Q: Can DevStack handle a multi-node installation?
A: Indirectly, yes. You run DevStack on each node with the
appropriate configuration in ``local.conf``. 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
``local.conf`` (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 ``local.conf``. Swift is on its own release schedule so pick a tag in the Swift repo that is just before the milestone release. For example:
::
[[local|localrc]]
GLANCE_BRANCH=stable/grizzly
HORIZON_BRANCH=stable/grizzly
KEYSTONE_BRANCH=stable/grizzly
NOVA_BRANCH=stable/grizzly
GLANCE_BRANCH=stable/grizzly
NEUTRON_BRANCH=stable/grizzly
SWIFT_BRANCH=1.10.0
Q: Why not use [STRIKEOUT:``tools/pip-requires``]\ ``requirements.txt`` to grab project dependencies?
[STRIKEOUT: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.] Certain Linux
distributions have a 'lack of workaround' in their Python
configurations that installs vendor packaged Python modules and
pip-installed modules to the SAME DIRECTORY TREE. This is causing
heartache and moving us in the direction of installing more modules
from PyPI than vendor packages. However, that is only being done as
necessary as the packaging needs to catch up to the development
cycle anyway so this is kept to a minimum.
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.
Q: How can I set up Heat in stand-alone configuration?
