These are the commits to DevStack for the last six months. For the complete list see the DevStack project in Gerrit.
- -DevStack has always tried to be mostly-functional with a minimal amount of configuration. The number of options has ballooned as projects add features, new projects added and more combinations need to be tested. Historically DevStack obtained all local configuration and customizations from a localrc file. The number of configuration variables that are simply passed-through to the individual project configuration files is also increasing. The old mechanism for this (EXTRAS_OPTS and friends) required specific code for each file and did not scale well.
In Oct 2013 a new configuration method was introduced (in review 46768) to hopefully simplify this process and meet the following goals:
-localrc to smooth the transition processThe new configuration file is local.conf and resides in the root DevStack directory like the old localrc file. It is a modified INI format file that introduces a meta-section header to carry additional information regarding the configuration files to be changed.
The new header is similar to a normal INI section header but with double brackets ([[ ... ]]) and two internal fields separated by a pipe (|):
[[ <phase> | <config-file-name> ]] -- -
where <phase> is one of a set of phase names defined by stack.sh and <config-file-name> is the configuration filename. The filename is eval'ed in the stack.sh context so all environment variables are available and may be used. Using the project config file variables in the header is strongly suggested (see the NOVA_CONF example below). If the path of the config file does not exist it is skipped.
The defined phases are:
-localrc from local.conf before stackrc is sourcedextra.d are executed
- The file is processed strictly in sequence; meta-sections may be specified more than once but if any settings are duplicated the last to appear in the file will be used.
-[[post-config|$NOVA_CONF]] -[DEFAULT] -use_syslog = True - -[osapi_v3] -enabled = False -- -
A specific meta-section local|localrc is used to
- provide a default localrc file (actually
- .localrc.auto). This allows all custom settings
- for DevStack to be contained in a single file. If localrc
- exists it will be used instead to preserve backward-compatibility. More
- details on the contents of localrc are available.
[[local|localrc]] -FIXED_RANGE=10.254.1.0/24 -ADMIN_PASSWORD=speciale -LOGFILE=$DEST/logs/stack.sh.log -- -
Note that Q_PLUGIN_CONF_FILE is unique in that it is assumed to NOT start with a / (slash) character. A slash will need to be added:
[[post-config|/$Q_PLUGIN_CONF_FILE]] -- -
Also note that the localrc section is sourced as a shell script fragment amd = (equals).
While stack.sh is happy to run without a localrc section in local.conf, devlife is better when there are a few minimal variables set. This is an example of a minimal configuration that touches the values that most often need to be set.
FIXED_RANGE and FLOATING_RANGE, commented out below)HOST_IP, commented out below)[[local|localrc]] -ADMIN_PASSWORD=secrete -DATABASE_PASSWORD=$ADMIN_PASSWORD -RABBIT_PASSWORD=$ADMIN_PASSWORD -SERVICE_PASSWORD=$ADMIN_PASSWORD -SERVICE_TOKEN=a682f596-76f3-11e3-b3b2-e716f9080d50 -#FIXED_RANGE=172.31.1.0/24 -#FLOATING_RANGE=192.168.20.0/25 -#HOST_IP=10.3.4.5-
If the *_PASSWORD variables are not set here you will be prompted to enter values for them by stack.sh.
The network ranges must not overlap with any networks in use on the host. Overlap is not uncommon as RFC-1918 'private' ranges are commonly used for both the local networking and Nova's fixed and floating ranges.
-HOST_IP is normally detected on the first run of stack.sh but often is indeterminate on later runs due to the IP being moved from an Ethernet integace to a bridge on the host. Setting it here also makes it available for openrc to set OS_AUTH_URL. HOST_IP is not set by default.
DEST=/opt/stackDEST variable. By setting it early in the localrc section you can reference it in later variables. It can be useful to set it even though it is not changed from the default value.
- DEST=/opt/stack
LOGFILE="" LOGDAYS=7 LOG_COLOR=Truestack.sh output is only written to the console where is runs. It can be sent to a file in addition to the console by setting LOGFILE to the fully-qualified name of the destination log file. A timestamp will be appended to the given filename for each run of stack.sh.
- LOGFILE=$DEST/logs/stack.sh.log- Old log files are cleaned automatically if
LOGDAYS is set to the number of days of old log files to keep.
- LOGDAYS=1- The some of the project logs (Nova, Cinder, etc) will be colorized by default (if
SYSLOG is not set below); this can be turned off by setting LOG_COLOR False.
- LOG_COLOR=False
SCREEN_LOGDIR=""screen which is useful for watching log and debug output. However, in automated testing the interactive screen sessions may not be available after the fact; setting SCREEN_LOGDIR enables logging of the screen sessions in the specified diretory. There will be one file per screen session named for the session name and a timestamp.
- SCREEN_LOGDIR=$DEST/logs/screen- Note the use of
DEST to locate the main install directory; this is why we suggest setting it in local.conf.SYSLOG=False SYSLOG_HOST=$HOST_IP SYSLOG_PORT=516SYSLOG to True. If the destination log host is not localhost SYSLOG_HOST and SYSLOG_PORT can be used to direct the message stream to the log host.
- SYSLOG=True -SYSLOG_HOST=$HOST_IP -SYSLOG_PORT=516
RECLONE=""stack.sh only clones the project repos if they do not exist in $DEST. stack.sh will freshen each repo on each run if RECLONE is set to yes. This avoids having to manually remove repos in order to get the current branch from $GIT_BASE.
- RECLONE=yes
SWIFT_HASH="" SWIFT_REPLICAS=1 SWIFT_DATA_DIR=$DEST/data/swiftENABLED_SERVICES) is automatically disabled. Enable Swift by adding it services to ENABLED_SERVICES:
- enable_service s-proxy s-object s-container s-account- Setting Swift's hash value is required and you will be prompted for it if Swift is enabled so just set it to something already: -
SWIFT_HASH=66a3d6b56c1f479c8b4e70ab5c2000f5- For development purposes the default number of replicas is set to
1 to reduce the overhead required. To better simulate a production deployment set this to 3 or more.
- SWIFT_REPLICAS=3- The data for Swift is stored in the source tree by default - (in
$DEST/swift/data) and can be moved by setting
- SWIFT_DATA_DIR. The specified directory will be created if it does not exist.
- SWIFT_DATA_DIR=$DEST/data/swift- Note: Previously just enabling
swift was sufficient to start the Swift services. That does not provide proper service granularity, particularly in multi-host configurations, and is considered deprecated. Some service combination tests now check for specific Swift services and the old blanket acceptance will longer work correctly.
- KEYSTONE_CATALOG_BACKEND=sqlsql service catalog backend. An alternate template backend is also available. However, it does not support the service-* and endpoint-* commands of the keystone CLI. To
- do so requires the sql backend be enabled:
- KEYSTONE_CATALOG_BACKEND=template- DevStack's default configuration in
sql mode is set in
- files/keystone_data.shVOLUME_GROUP="stack-volumes" VOLUME_NAME_PREFIX="volume-" VOLUME_BACKING_FILE_SIZE=10250MVOLUME_GROUP, the logical volume name prefix is set with VOLUME_NAME_PREFIX and the size of the volume backing file is set with VOLUME_BACKING_FILE_SIZE.
- VOLUME_GROUP="stack-volumes" -VOLUME_NAME_PREFIX="volume-" -VOLUME_BACKING_FILE_SIZE=10250M
MULTI_HOST=Falselocal.conf section for each host. The master is the same as a single host installation with MULTI_HOST=True. The slaves have fewer services enabled and a couple of host variables pointing to the master.
- MULTI_HOST=True- - Slave -
MYSQL_HOST=w.x.y.z -RABBIT_HOST=w.x.y.z -GLANCE_HOSTPORT=w.x.y.z:9292 -ENABLED_SERVICES=n-vol,n-cpu,n-net,n-api
API_RATE_LIMIT=TrueAPI_RATE_LIMIT=False.
- API_RATE_LIMIT=False
CINDER_PERIODIC_INTERVAL):
-[[post-config|$CINDER_CONF]] -[DEFAULT] -periodic_interval = 60 -
local.conf with screen logging enabled:
-[[local|localrc]] -FIXED_RANGE=10.254.1.0/24 -NETWORK_GATEWAY=10.254.1.1 -LOGDAYS=1 -LOGFILE=$DEST/logs/stack.sh.log -SCREEN_LOGDIR=$DEST/logs/screen -ADMIN_PASSWORD=quiet -DATABASE_PASSWORD=$ADMIN_PASSWORD -RABBIT_PASSWORD=$ADMIN_PASSWORD -SERVICE_PASSWORD=$ADMIN_PASSWORD -SERVICE_TOKEN=a682f596-76f3-11e3-b3b2-e716f9080d50
DevStack uses the standard OpenStack contribution process as outlined in the OpenStack wiki 'How To Contribute'. This means that you will need to meet the requirements of the Contribututors License Agreement (CLA). If you have already done that for another OpenStack project you are good to go.
- -The official DevStack repository is located at git://git.openstack.org/openstack-dev/devstack.git, replicated from the repo maintained by Gerrit. GitHub also has a mirror at git://github.com/openstack-dev/devstack.git.
The blueprint and bug trackers are on Launchpad. It should be noted that DevStack generally does not use these as strongly as other projects, but we're trying to change that.
-The Gerrit review queue is, however, used for all commits except for the text of this website. That should also change in the near future.
- -Like most OpenStack projects, DevStack includes a HACKING.rst file that describes the layout, style and conventions of the project. Because HACKING.rst is in the main DevStack repo it is considered authoritative. Much of the content on this page is taken from there.
Around the time of the OpenStack Havana release we added a tool to do style checking in DevStack similar to what pep8/flake8 do for Python projects. It is still _very_ simplistic, focusing mostly on stray whitespace to help prevent -1 on reviews that are otherwise acceptable. Oddly enough it is called bashate. It will be expanded to enforce some of the documentation rules in comments that are used in formatting the script pages for devstack.org and possibly even simple code formatting. Run it on the entire project with ./run_tests.sh.
The DevStack repo generally keeps all of the primary scripts at the root level.
-docs - Contains the source for this website. It is built using tools/build_docs.sh.
exercises - Contains the test scripts used to validate and demonstrate some OpenStack functions. These scripts know how to exit early or skip services that are not enabled.
extras.d - Contains the dispatch scripts called by the hooks in stack.sh, unstack.sh and clean.sh. See the plugins docs for more information.
files - Contains a variety of otherwise lost files used in configuring and operating DevStack. This includes templates for configuration files and the system dependency information. This is also where image files are downloaded and expanded if necessary.
lib - Contains the sub-scripts specific to each project. This is where the work of managing a project's services is located. Each top-level project (Keystone, Nova, etc) has a file here. Additionally there are some for system services and project plugins.
samples - Contains a sample of the local files not included in the DevStack repo.
tests - the DevStack test suite is rather sparse, mostly consisting of test of specific fragile functions in the functions file.
tools - Contains a collection of stand-alone scripts, some of which have aged a bit (does anyone still do ramdisk installs?). While these may reference the top-level DevStack configuration they can generally be run alone. There are also some sub-directories to support specific environments such as XenServer.
eucarc creates EC2 credentials for the current user as
- defined by OS_TENANT_NAME:OS_USERNAME.
- eucarc sources openrc at the beginning
- (which in turn sources stackrc and localrc)
- in order to set credentials to create EC2 credentials in Keystone.
-
OS_TENANT_NAME:OS_USERNAME.
- EC2_URL=$(keystone catalog --service ec2 | awk '/ publicURL / { print $4 }')OS_TENANT_NAME:OS_USERNAME.
- export S3_URL=$(keystone catalog --service s3 | awk '/ publicURL / { print $4 }')CREDS=$(keystone ec2-credentials-create)
-export EC2_ACCESS_KEY=$(echo "$CREDS" | awk '/ access / { print $4 }')
-export EC2_SECRET_KEY=$(echo "$CREDS" | awk '/ secret / { print $4 }')exercises/bundle.sh demonstrated
- retrieving certificates using the Nova CLI.
- EC2_PRIVATE_KEY=pk.pem
-EC2_CERT=cert.pem
-NOVA_CERT=cacert.pem
-EUCALYPTUS_CERT=${NOVA_CERT}© Openstack Foundation 2011-2013 — An - OpenStack program - created by Rackspace Cloud Builders
- - -exerciserc is used to configure settings for the
- exercise scripts. The values shown below are the default values.
- Thse can all be overridden by setting them in the localrc
- section.
ACTIVE_TIMEOUT==30
ASSOCIATE_TIMEOUT=15
BOOT_TIMEOUT=30
RUNNING_TIMEOUT=$(($BOOT_TIMEOUT + $ACTIVE_TIMEOUT))
TERMINATE_TIMEOUT=30
© Openstack Foundation 2011-2013 — An - OpenStack program - created by Rackspace Cloud Builders
- - -stack.sh's use of root is primarily to support the activities that would be handled by packaging in "real" deployments. To remove additional protections that will be desired/required in production would be a step backward.README.md. DevStack is only supported on releases other than those documented in README.md on a best-effort basis.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.stack.sh to handle this. But the testing on py26 is valuable so we do it...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.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.disable_service xxx to local.conf (using n-vol in this example):
- disable_service n-vol-
enable_service qpid-
*_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-
tools/pip-requiresrequirements.txt to grab project dependencies?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.local.conf thusly:
- [[local|localrc]] -HEAT_STANDALONE=True -ENABLED_SERVICES=rabbit,mysql,heat,h-api,h-api-cfn,h-api-cw,h-eng -KEYSTONE_SERVICE_HOST=<keystone-host> -KEYSTONE_AUTH_HOST=<keystone-host>-
tools/install_prereqs.sh has a timer that skips the package installation checks if it was run within the last PREREQ_RERUN_HOURS hours (default is 2). To override this, set FORCE_PREREQ=1 and the package checks will never be skipped.
- tools/fixup_stuff.sh is broken and shouldn't 'fix' just one version of packages.httplib2 and prettytable specific problems with specific versions are being worked around. If later releases have those problems than we'll add them to the script. Knowing about the broken future releases is valuable rather than polling to see if it has been fixed.Here is OpenStack in a realistic test configuration with multiple physical servers.
-You need to have a system with a fresh install of Linux. You can download the Minimal CD for Ubuntu releases since DevStack will download & install all the additional dependencies. The netinstall ISO is available for Fedora and CentOS/RHEL.
- -Install a couple of packages to bootstrap configuration:
-apt-get install -y git sudo || yum install -y git sudo- -
The first iteration of the lab uses OpenStack's FlatDHCP network controller so - only a single network will be required. It should be on its own subnet without DHCP; - the host IPs and floating IP pool(s) will come out of this block. This example - uses the following:
-Configure each node with a static IP.
- For Ubuntu edit /etc/network/interfaces:
auto eth0 -iface eth0 inet static - address 192.168.42.11 - netmask 255.255.255.0 - gateway 192.168.42.1 --
For Fedora and CentOS/RHEL edit
- /etc/sysconfig/network-scripts/ifcfg-eth0:
BOOTPROTO=static -IPADDR=192.168.42.11 -NETMASK=255.255.255.0 -GATEWAY=192.168.42.1 -- - - -
OpenStack runs as a non-root user that has sudo access to root. There is nothing special
- about the name, we'll use stack here. Every node must use the same name and
- preferably uid. If you created a user during the OS install you can use it and give it
- sudo privileges below. Otherwise create the stack user:
groupadd stack -useradd -g stack -s /bin/bash -d /opt/stack -m stack-
This user will be making many changes to your system during installation and operation - so it needs to have sudo privileges to root without a password:
-echo "stack ALL=(ALL) NOPASSWD: ALL" >> /etc/sudoers-
From here on use the stack user. Logout and login as the
- stack user.
Set up the stack user on each node with an ssh key for access:
-mkdir ~/.ssh; chmod 700 ~/.ssh -echo "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCyYjfgyPazTvGpd8OaAvtU2utL8W6gWC4JdRS1J95GhNNfQd657yO6s1AH5KYQWktcE6FO/xNUC2reEXSGC7ezy+sGO1kj9Limv5vrvNHvF1+wts0Cmyx61D2nQw35/Qz8BvpdJANL7VwP/cFI/p3yhvx2lsnjFE3hN8xRB2LtLUopUSVdBwACOVUmH2G+2BWMJDjVINd2DPqRIA4Zhy09KJ3O1Joabr0XpQL0yt/I9x8BVHdAx6l9U0tMg9dj5+tAjZvMAFfye3PJcYwwsfJoFxC8w/SLtqlFX7Ehw++8RtvomvuipLdmWCy+T9hIkl+gHYE4cS3OIqXH7f49jdJf jesse@spacey.local" > ~/.ssh/authorized_keys- -
Grab the latest version of DevStack:
-git clone https://git.openstack.org/openstack-dev/devstack -cd devstack- -
Up to this point all of the steps apply to each node in the cluster. From here on - there are some differences between the cluster controller (aka 'head node') and the - compute nodes.
- -The cluster controller runs all OpenStack services. Configure the cluster controller's DevStack in local.conf:
[[local|localrc]] -HOST_IP=192.168.42.11 -FLAT_INTERFACE=eth0 -FIXED_RANGE=10.4.128.0/20 -FIXED_NETWORK_SIZE=4096 -FLOATING_RANGE=192.168.42.128/25 -MULTI_HOST=1 -LOGFILE=/opt/stack/logs/stack.sh.log -ADMIN_PASSWORD=labstack -MYSQL_PASSWORD=supersecret -RABBIT_PASSWORD=supersecrete -SERVICE_PASSWORD=supersecrete -SERVICE_TOKEN=xyzpdqlazydog- - -
In the multi-node configuration the first 10 or so IPs in the private subnet are usually reserved. Add this to local.sh to have it run after every stack.sh run:
for i in `seq 2 10`; do /opt/stack/nova/bin/nova-manage fixed reserve 10.4.128.$i; done- -
Fire up OpenStack:
-./stack.sh-
A stream of activity ensues. When complete you will see a summary of
- stack.sh's work, including the relevant URLs, accounts and passwords to poke at your
- shiny new OpenStack. The most recent log file is available in stack.sh.log.
The compute nodes only run the OpenStack worker services. For additional machines, create a local.conf with:
HOST_IP=192.168.42.12 # change this per compute node -FLAT_INTERFACE=eth0 -FIXED_RANGE=10.4.128.0/20 -FIXED_NETWORK_SIZE=4096 -FLOATING_RANGE=192.168.42.128/25 -MULTI_HOST=1 -LOGFILE=/opt/stack/logs/stack.sh.log -ADMIN_PASSWORD=labstack -MYSQL_PASSWORD=supersecret -RABBIT_PASSWORD=supersecrete -SERVICE_PASSWORD=supersecrete -SERVICE_TOKEN=xyzpdqlazydog -DATABASE_TYPE=mysql -SERVICE_HOST=192.168.42.11 -MYSQL_HOST=192.168.42.11 -RABBIT_HOST=192.168.42.11 -GLANCE_HOSTPORT=192.168.42.11:9292 -ENABLED_SERVICES=n-cpu,n-net,n-api,c-sch,c-api,c-vol -NOVA_VNC_ENABLED=True -NOVNCPROXY_URL="http://192.168.42.11:6080/vnc_auto.html" -VNCSERVER_LISTEN=$HOST_IP -VNCSERVER_PROXYCLIENT_ADDRESS=$VNCSERVER_LISTEN -- - - -
Fire up OpenStack:
-./stack.sh-
A stream of activity ensues. When complete you will see a summary of
- stack.sh's work, including the relevant URLs, accounts and passwords to poke at your
- shiny new OpenStack. The most recent log file is available in stack.sh.log.
Shutting down OpenStack is now as simple as running the included unstack.sh script:
./unstack.sh- -
A more aggressive cleanup can be performed using clean.sh. It removes certain troublesome packages and attempts to leave the system in a state where changing the database or queue manager can be reliably performed.
-
./clean.sh- -
Sometimes running instances are not cleaned up. DevStack attempts to do this when it - runs but there are times it needs to still be done by hand:
-sudo rm -rf /etc/libvirt/qemu/inst*
-sudo virsh list | grep inst | awk '{print $1}' | xargs -n1 virsh destroy
-
- DevStack creates two OpenStack users (admin and demo) and two tenants (also admin and demo). admin is exactly what it sounds like, a privileged administrative account that is a member of both the admin and demo tenants. demo is a normal user account that is only a member of the demo tenant. Creating additional OpenStack users can be done through the dashboard, sometimes it is easier to do them in bulk from a script, especially since they get blown away every time
- stack.sh runs. The following steps are ripe for scripting:
# Get admin creds -. openrc admin admin - -# List existing tenants -keystone tenant-list - -# List existing users -keystone user-list - -# Add a user and tenant -NAME=bob -PASSWORD=BigSecrete -TENANT=$NAME -keystone tenant-create --name=$NAME -keystone user-create --name=$NAME --pass=$PASSWORD -keystone user-role-add --user-id=<bob-user-id> --tenant-id=<bob-tenant-id> --role-id=<member-role-id> -# member-role-id comes from the existing member role created by stack.sh -# keystone role-list- -
Swift requires a significant amount of resources and is disabled by default in DevStack.
- The support in DevStack is geared toward a minimal installation but can be used for
- testing. To implement a true multi-node test of Swift required more than DevStack provides.
- Enabling it is as simple as enabling the swift service in local.conf:
-
enable_service s-proxy s-object s-container s-account- -
Swift will put its data files in SWIFT_DATA_DIR (default /opt/stack/data/swift).
- The size of the data 'partition' created (really a loop-mounted file) is set by
- SWIFT_LOOPBACK_DISK_SIZE. The Swift config files are located in
- SWIFT_CONFIG_DIR (default /etc/swift). All of these settings can be overridden in
- (wait for it...) local.conf.
DevStack will automatically use an existing LVM volume group named stack-volumes
- to store cloud-created volumes. If stack-volumes doesn't exist, DevStack
- will set up a 5Gb loop-mounted file to contain it. This obviously limits the
- number and size of volumes that can be created inside OpenStack. The size can be
- overridden by setting VOLUME_BACKING_FILE_SIZE in local.conf.
stack-volumes can be pre-created on any physical volume supported by
- Linux's LVM. The name of the volume group can be changed by setting VOLUME_GROUP
- in localrc. stack.sh deletes
- all logical volumes in VOLUME_GROUP that begin with
- VOLUME_NAME_PREFIX as part of cleaning up from previous runs.
- It is recommended to not use the root volume group as VOLUME_GROUP.
The details of creating the volume group depends on the server hardware involved - but looks something like this:
-pvcreate /dev/sdc -vgcreate stack-volumes /dev/sdc- -
DevStack is capable of using rsyslog to aggregate logging across the cluster.
- It is off by default; to turn it on set SYSLOG=True in local.conf.
- SYSLOG_HOST defaults to HOST_IP; on the compute nodes it
- must be set to the IP of the cluster controller to send syslog output there. In the example
- above, add this to the compute node local.conf:
SYSLOG_HOST=192.168.42.11- -
The git repositories for all of the OpenStack services are defined in stackrc.
- Since this file is a part of the DevStack package changes to it will probably be overwritten
- as updates are applied. Every setting in stackrc can be redefined in
- local.conf.
To change the repository or branch that a particular OpenStack service is created from,
- simply change the value of *_REPO or *_BRANCH corresponding to
- that service.
After making changes to the repository or branch, if RECLONE is not set
- in localrc it may be necessary to remove the corresponding directory from
- /opt/stack to force git to re-clone the repository.
For example, to pull Nova from a proposed release candidate in the primary Nova - repository:
-NOVA_BRANCH=rc-proposed- -
To pull Glance from an experimental fork:
-GLANCE_BRANCH=try-something-big -GLANCE_REPO=https://github.com/mcuser/glance.git- -
How to reset the bridge configuration:
-sudo brctl delif br100 eth0.926 -sudo ip link set dev br100 down -sudo brctl delbr br100- - -
If you forgot to set the root password you can do this:
-mysqladmin -u root -pnova password 'supersecret'- -
Boot DevStack from a PXE server to a RAM disk.
-The whole point of this exercise is to have a highly portable boot server, so using a small router with a USB port is the desired platform. This guide uses a Buffalo WZR-HP-G300NH as an example, but it is easily generalized for other supported platforms. See openwrt.org for more.
- -Any recent 'Backfire' build of OpenWRT will work for the boot server project. We build from trunk and have made the images available at http://openwrt.xr7.org/openwrt.
-This process follows the OpenWRT doc OEM Install to tftp the new image onto the router. You need a computer to set up the router, we assume it is a recent Linux or OS/X installation.
-wget http://openwrt.xr7.org/openwrt/ar71xx/openwrt-ar71xx-wzr-hp-g300nh-squashfs-tftp.bin-
arp -s 192.168.11.1 <mac-address>-
tftp 192.168.11.1 -binary -rexmt 1 -timeout 60 -put openwrt-ar71xx-wzr-hp-g300nh-squashfs-tftp.bin-
arp -d 192.168.11.1-
/etc/opkg.conf to point to our repo:
- src/gz packages http://192.168.5.13/openwrt/build/ar71xx/packages-
uci delete fstab.@mount[0] -uci commit fstab -/etc/init.d/fstab restart-
uci set dhcp.lan.start=65 -uci set dhcp.lan.limit=60 -uci commit dhcp-
uci set dhcp.@dnsmasq[0].enable_tftp=1 -uci set dhcp.@dnsmasq[0].tftp_root=/mnt/sda1/tftpboot -uci set dhcp.@dnsmasq[0].dhcp_boot=pxelinux.0 -uci commit dhcp -/etc/init.d/dnsmasq restart-
/tmp/tftpboot structure and populate it:
- cd ~/devstack -tools/build_pxe_boot.sh /tmp- This calls
tools/build_ramdisk.sh to create a 2GB ramdisk
- containing a complete development Oneiric OS plus the
- OpenStack code checkouts.
- tftpboot to a USB drive:
- mount /dev/sdb1 /mnt/tmp -rsync -a /tmp/tftpboot/ /mnt/tmp/tftpboot/ -umount /mnt/tmp-
Now return to the RAM disk Guide to kick - off your DevStack experience.
- -Run DevStack from a RAM disk to give it a whirl before making the - commitment to install it. We'll cover booting from a USB drive or - over the network via PXE. We'll even thow in configuring a home - router to handle the PXE boot. You will need a minimum of 3GB - for both of these configurations as the RAM disk itself is 2GB.
-This guide covers the creation of a bootable USB drive. Your - computer BIOS must support booting from USB.
- -This guide covers the installation of OpenWRT on a home router - and configuring it as a PXE server, plus the creation of the - boot images and PXE support files. -
Grab the latest version of DevStack via https:
-sudo apt-get install git -y -git clone https://git.openstack.org/openstack-dev/devstack -cd devstack- -
Pick your boot method and follow the guide to prepare to build - the RAM disk and set up the boot process:
- - -devstack/localrc if you wish to change any
- of the configuration variables. You will probably want to at
- least set the admin login password to something memorable rather
- than the default 20 random characters:
- ADMIN_PASSWORD=openstack-
./run.sh-
screen -x-
http://<ip-address>/Things are about to get real! Using OpenStack in containers or VMs is nice for kicking the tires, but doesn't compare to the feeling you get with hardware.
-You need to have a system with a fresh install of Linux. You can download the Minimal CD for Ubuntu releases since DevStack will download & install all the additional dependencies. The netinstall ISO is available for Fedora and CentOS/RHEL. You may be tempted to use a desktop distro on a laptop, it will probably work but you may need to tell Network Manager to keep its fingers off the interface(s) that OpenStack uses for bridging.
- -Determine the network configuration on the interface used to integrate your - OpenStack cloud with your existing network. For example, if the IPs given out on your network - by DHCP are 192.168.1.X - where X is between 100 and 200 you will be able to use IPs - 201-254 for floating ips.
-To make things easier later change your host to use a static IP instead of DHCP (i.e. 192.168.1.201).
-We need to add a user to install DevStack. (if you created a user during install you can skip this step and just give the user sudo privileges below)
-adduser stack-
Since this user will be making many changes to your system, it will need to have sudo privileges:
-apt-get install sudo -y || yum install -y sudo -echo "stack ALL=(ALL) NOPASSWD: ALL" >> /etc/sudoers-
From here on you should use the user you created. Logout and login as that user.
- -We'll grab the latest version of DevStack via https:
-sudo apt-get install git -y || yum install -y git -git clone https://git.openstack.org/openstack-dev/devstack -cd devstack- -
Now to configure stack.sh. DevStack includes a sample in devstack/samples/local.conf. Create local.conf as shown below to do the following:
FLOATING_RANGE to a range not used on the local network, i.e. 192.168.1.224/27. This configures IP addresses ending in 225-254 to be used as floating IPs.FIXED_RANGE and FIXED_NETWORK_SIZE to configure the internal address space used by the instances.FLAT_INTERFACE to the Ethernet interface that connects the host to your local network. This is the interface that should be configured with the static IP address mentioned above.local.conf should look something like this:
[[local|localrc]] -FLOATING_RANGE=192.168.1.224/27 -FIXED_RANGE=10.11.12.0/24 -FIXED_NETWORK_SIZE=256 -FLAT_INTERFACE=eth0 -ADMIN_PASSWORD=supersecret -MYSQL_PASSWORD=iheartdatabases -RABBIT_PASSWORD=flopsymopsy -SERVICE_PASSWORD=iheartksl- -
Run DevStack:
-./stack.sh-
A seemingly endless stream of activity ensues. When complete you will see a summary of
- stack.sh's work, including the relevant URLs, accounts and passwords to poke at your
- shiny new OpenStack.
At this point you should be able to access the dashboard from other computers on the - local network. In this example that would be http://192.168.1.201/ for the dashboard (aka Horizon). - Launch VMs and if you give them floating IPs and security group access those VMs will be accessible from other machines on your network.
- -Some examples of using the OpenStack command-line clients nova and glance
- are in the shakedown scripts in devstack/exercises. exercise.sh
- will run all of those scripts and report on the results.
Use the cloud to build the cloud! Use your cloud to launch new versions of OpenStack - in about 5 minutes. When you break it, start over! The VMs launched in the cloud will - be slow as they are running in QEMU (emulation), but their primary use is testing - OpenStack development and operation. Speed not required.
-DevStack should run in any virtual machine running a supported Linux release. It will perform best with 2Gb or more of RAM.
- -If the cloud service has an image with cloud-init pre-installed, use it. You can
- get one from Ubuntu's Daily Build
- site if necessary. This will enable you to launch VMs with userdata that installs
- everything at boot time. The userdata script below will install and run
- DevStack with a minimal configuration. The use of cloud-init
- is outside the scope of this document, refer to the
- cloud-init docs for more information.
If you are directly using a hypervisor like Xen, kvm or VirtualBox you can manually kick off - the script below as a non-root user in a bare-bones server installation.
-This cloud config grabs the latest version of DevStack via git, creates a minimal
- local.conf file and kicks off stack.sh. It should
- be passed as the user-data file when booting the VM.
#cloud-config - -users: - - default - - name: stack - lock_passwd: False - sudo: ["ALL=(ALL) NOPASSWD:ALL\nDefaults:stack !requiretty"] - shell: /bin/bash - -write_files: - - content: | - #!/bin/sh - DEBIAN_FRONTEND=noninteractive sudo apt-get -qqy update || sudo yum update -qy - DEBIAN_FRONTEND=noninteractive sudo apt-get install -qqy git || sudo yum install -qy git - sudo chown stack:stack /home/stack - cd /home/stack - git clone https://git.openstack.org/openstack-dev/devstack - cd devstack - 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 - ./stack.sh - path: /home/stack/start.sh - permissions: 0755 - -runcmd: - - su -l stack ./start.sh-
As DevStack will refuse to run as root, this configures cloud-init
- to create a non-root user and run the start.sh script as that user.
Using a hypervisor directly, launch the VM and either manually perform the steps in the - embedded shell script above or copy it into the VM.
- -At this point you should be able to access the dashboard. Launch VMs and if you give them floating IPs access those VMs from other machines on your network.
- -One interesting use case is for developers working on a VM on their laptop. Once
- stack.sh has completed once, all of the pre-requisite packages are installed
- in the VM and the source trees checked out. Setting OFFLINE=True in
- local.conf enables stack.sh to run multiple times without an Internet
- connection. DevStack, making hacking at the lake possible since 2012!
Boot DevStack from a USB disk into a RAM disk.
-This guide covers the creation of a bootable USB drive. Your - computer BIOS must support booting from USB and You will want at least 3GB of - RAM. You also will need a USB drive of at least 2GB.
- -Ubuntu 11.10 (Oneiric Ocelot) is required on host to create images.
-sdb. Do not mount the device.tools/build_usb_boot.sh /dev/sdb1-
This calls tools/build_ramdisk.sh to create a 2GB ramdisk
- containing a complete development Oneiric OS plus the
- OpenStack code checkouts. It then writes a syslinux boot sector
- to the specified device and creates /syslinux.
mount /dev/sdb1 /mnt/tmp -# foo -umount /mnt/tmp-
Now return to the RAM disk Guide to kick - off your DevStack experience.
- -A documented shell script to build complete OpenStack development environments.
- An OpenStack program maintained by the developer community.
git clone https://git.openstack.org/openstack-dev/devstack-
cd devstack && ./stack.sh-
Only Ubuntu 14.04 (Trusty), Fedora 20 and CentOS/RHEL 6.5 are documented here. OpenStack also runs and is packaged on other flavors of Linux such as OpenSUSE and Debian.
-In order to correctly install all the dependencies, we assume a specific minimal version of the supported distributions to make it as easy as possible. We recommend using a minimal install of Ubuntu or Fedora server in a VM if this is your first time.
-git clone https://git.openstack.org/openstack-dev/devstack-
The devstack repo contains a script that installs OpenStack and templates for configuration files
We recommend at least a minimal configuration be set up.
-cd devstack; ./stack.sh-
It takes a few minutes, we recommend reading the script while it is building.
-| Title | -Description | -Link | -
|---|---|---|
| Virtual Machine | -Run OpenStack in a VM. The VMs launched in your cloud will be slow as they are running in QEMU (emulation), but it is useful if you don't have spare hardware laying around. | -Read » | -1 Guide | - -
These guides tell you how to virtualize your OpenStack cloud in virtual machines. This means that you can get started without having to purchase any hardware.
-| Title | -Description | -Link | -
|---|---|---|
| All-In-One | -Run OpenStack on dedicated hardware to get real performance in your VMs. This can include a server-class machine or a laptop at home. | -Read » | -
| Multi-Node + VLANs | -Setup a multi-node cluster with dedicated VLANs for VMs & Management. | -Read » | -2 Guides | - -
These guides tell you how to deploy a development environment on real hardware. Guides range from running OpenStack on a single laptop to running a multi-node deployment on datacenter hardware.
-An overview of DevStack goals and priorities
-Configuring and customizing the stack
-| Filename | -Link | -
|---|---|
| stack.sh | -Read » | -
| functions | -Read » | -
| functions-common | -Read » | -
| lib/apache | -Read » | -
| lib/baremetal | -Read » | -
| lib/ceilometer | -Read » | -
| lib/cinder | -Read » | -
| lib/config | -Read » | -
| lib/database | -Read » | -
| lib/glance | -Read » | -
| lib/heat | -Read » | -
| lib/horizon | -Read » | -
| lib/infra | -Read » | -
| lib/ironic | -Read » | -
| lib/keystone | -Read » | -
| lib/ldap | -Read » | -
| lib/zaqar | -Read » | -
| lib/neutron | -Read » | -
| lib/nova | -Read » | -
| lib/oslo | -Read » | -
| lib/rpc_backend | -Read » | -
| lib/sahara | -Read » | -
| lib/savanna | -Read » | -
| lib/stackforge | -Read » | -
| lib/swift | -Read » | -
| lib/tempest | -Read » | -
| lib/tls | -Read » | -
| lib/trove | -Read » | -
| unstack.sh | -Read » | -
| clean.sh | -Read » | -
| run_tests.sh | -Read » | -
| extras.d/50-ironic.sh | -Read » | -
| extras.d/70-zaqar.sh | -Read » | -
| extras.d/70-sahara.sh | -Read » | -
| extras.d/70-savanna.sh | -Read » | -
| extras.d/70-trove.sh | -Read » | -
| extras.d/80-opendaylight.sh | -Read » | -
| extras.d/80-tempest.sh | -Read » | -
| Filename | -Link | -
|---|---|
| local.conf | -Read » | -
| stackrc | -Read » | -
| openrc | -Read » | -
| exerciserc | -Read » | -
| eucarc | -Read » | -
| Filename | -Link | -
|---|---|
| tools/info.sh | -Read » | -
| tools/build_docs.sh | -Read » | -
| tools/create_userrc.sh | -Read » | -
| tools/fixup_stuff.sh | -Read » | -
| tools/install_prereqs.sh | -Read » | -
| tools/install_pip.sh | -Read » | -
| tools/upload_image.sh | -Read » | -
| Filename | -Link | -
|---|---|
| local.sh | -Read » | -
| localrc | -Read » | -
| Filename | -Link | -
|---|---|
| exercise.sh | -Read » | -
| exercises/aggregates.sh | -Read » | -
| exercises/boot_from_volume.sh | -Read » | -
| exercises/bundle.sh | -Read » | -
| exercises/client-args.sh | -Read » | -
| exercises/client-env.sh | -Read » | -
| exercises/euca.sh | -Read » | -
| exercises/floating_ips.sh | -Read » | -
| exercises/horizon.sh | -Read » | -
| exercises/neutron-adv-test.sh | -Read » | -exercises/sahara.sh | -Read » | - -exercises/savanna.sh | -Read » | - -
| exercises/sec_groups.sh | -Read » | -
| exercises/swift.sh | -Read » | -exercises/trove.sh | -Read » | - -
| exercises/volumes.sh | -Read » | -
| exercises/zaqar.sh | -Read » | -
local.conf is a user-maintained setings file that is
- sourced in stackrc. It contains a section that replaces
- the historical localrc file. See
- the description of local.conf for
- more details about the mechanics of the file.
localrc is the old file used to configure DevStack. It is deprecated and has been replaced by local.conf. DevStack will continue to use localrc if it is present and ignore the localrc section in local.conf.. Remove localrc to switch to using the new file.
openrc configures login credentials suitable for use
- with the OpenStack command-line tools. openrc sources
- stackrc at the beginning (which in turn sources
- the localrc setion of local.conf) in
- order to pick up HOST_IP
- and/or SERVICE_HOST to use in the endpoints.
- The values shown below are the default values.
OS_TENANT_NAME=demo
OS_USERNAME=demo
OS_PASSWORD=secrete
HOST_IP. SERVICE_HOST
- may also be used to specify the endpoint, which is convenient for
- some localrc configurations. Typically, HOST_IP
- is set in the localrc section.
- HOST_IP=127.0.0.1 -SERVICE_HOST=$HOST_IP
OS_AUTH_URL=http://$SERVICE_HOST:5000/v2.0
HOST_IP. If its running elsewhere
- it can be set here.
- GLANCE_HOST=$HOST_IP
DEBUG. These are
- commented out by default.
- # export KEYSTONECLIENT_DEBUG=1 -# export NOVACLIENT_DEBUG=1
© Openstack Foundation 2011-2013 — An - OpenStack program - created by Rackspace Cloud Builders
- - -DevStack has evolved to support a large number of configuration options and alternative platforms and support services. That evolution has grown well beyond what was originally intended and the majority of configuration combinations are rarely, if ever, tested. DevStack is not a general OpenStack installer and was never meant to be everything to everyone..
-Below is a list of what is specifically is supported (read that as "tested") going forward.
- -The OpenStack Technical Committee (TC) has defined the current CI strategy to include the latest Ubuntu release and the latest RHEL release (for Python 2.6 testing).
-As packaged by the host OS
-As packaged by the host OS
-As packaged by the host OS
-Default to Nova Network, optionally use Neutron
-The default services configured by DevStack are Identity (Keystone), Object Storage (Swift), Image Storage (Glance), Block Storage (Cinder), Compute (Nova), Network (Nova), Dashboard (Horizon), Orchestration (Heat)
-Additional services not included directly in DevStack can be tied in to stack.sh using the plugin mechanism to call scripts that perform the configuration and startup of the service.
The DevStack exercise scripts are no longer used as integration and gate testing as that job has transitioned to Tempest. They are still maintained as a demonstrations of using OpenStack from the command line and for quick operational testing.
- -DevStack has a couple of plugin mechanisms to allow easily adding support for additional projects and features.
- -These relatively new hooks are an extension of the existing calls from stack.sh at the end of its run, plus unstack.sh and clean.sh. A number of the higher-layer projects are implemented in DevStack using this mechanism.
The script in extras.d is expected to be mostly a dispatcher to functions in a lib/* script. The scripts are named with a zero-padded two digits sequence number prefix to control the order that the scripts are called, and with a suffix of .sh. DevSack reserves for itself the sequence numbers 00 through 09 and 90 through 99.
Below is a template that shows handlers for the possible command-line arguments:
- --# template.sh - DevStack extras.d dispatch script template - -# check for service enabled -if is_service_enabled template; then - - if [[ "$1" == "source" ]]; then - # Initial source of lib script - source $TOP_DIR/lib/template - fi - - if [[ "$1" == "stack" && "$2" == "pre-install" ]]; then - # Set up system services - echo_summary "Configuring system services Template" - install_package cowsay - - elif [[ "$1" == "stack" && "$2" == "install" ]]; then - # Perform installation of service source - echo_summary "Installing Template" - install_template - - elif [[ "$1" == "stack" && "$2" == "post-config" ]]; then - # Configure after the other layer 1 and 2 services have been configured - echo_summary "Configuring Template" - configure_template - - elif [[ "$1" == "stack" && "$2" == "extra" ]]; then - # Initialize and start the template service - echo_summary "Initializing Template" - ##init_template - fi - - if [[ "$1" == "unstack" ]]; then - # Shut down template services - # no-op - : - fi - - if [[ "$1" == "clean" ]]; then - # Remove state and transient data - # Remember clean.sh first calls unstack.sh - # no-op - : - fi -fi -- -
The arguments are: -
extras.d hooks; this replaces directly sourcing the lib/* script.stack.sh three times for different phases of its run:
- unstack.sh before other services are shut down.clean.sh before other services are cleaned, but after unstack.sh has been called.
- Hypervisor plugins are fairly new and condense most hypervisor configuration into one place.
- -The initial plugin implemented was for Docker support and is a useful template for the required support. Plugins are placed in lib/nova_plugins and named hypervisor-<name> where <name> is the value of VIRT_DRIVER. Plugins must define the following functions:
install_nova_hypervisor - install any external requirementsconfigure_nova_hypervisor - make configuration changes, including those to other servicesstart_nova_hypervisor - start any external servicesstop_nova_hypervisor - stop any external servicescleanup_nova_hypervisor - remove transient data and cachestackrc is the primary configuration file for DevStack.
- It contains all of the settings that control the services started
- and the repositories used to download the source for those services.
- stackrc sources the localrc section of
- local.conf to perform the default overrides.
mysql,
- postgresql is also available.ENABLED_SERVICES=g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-net,n-cond,cinder,c-sch,c-api,c-vol,n-sch,n-novnc,n-xvnc,n-cauth,horizon,rabbit,tempest,$DATABASE_TYPE- Other services that are not enabled by default can be enabled in -
localrc. For example, to add Swift, use the following service names:
- enable_service s-proxy s-object s-container s-account- A service can similarly be disabled: -
disable_service horizon
*_REPO points to the repository and *_BRANCH
- selects which branch to check out. These may be overridden in
- local.conf to pull source from a different repo for testing,
- such as a Gerrit branch proposal. GIT_BASE points to the primary repository server.
- NOVA_REPO=$GIT_BASE/openstack/nova.git -NOVA_BRANCH=master- To pull a branch directly from Gerrit, get the repo and branch from the - Gerrit review page: -
git fetch https://review.openstack.org/p/openstack/nova refs/changes/50/5050/1 && git checkout FETCH_HEAD- The repo is the stanza following
fetch and the branch
- is the stanza following that:
- NOVA_REPO=https://review.openstack.org/p/openstack/nova -NOVA_BRANCH=refs/changes/50/5050/1