Add for Ubuntu installations; this eliminates use of NBD. Commit 70237 merged 31 Jan 2014
+
Fix Tempest config settings
+
Cleans up a number of configuration issues between DevStack and Tempest. Commit 68532 merged 31 Jan 2014
+
Merge Gantt support
+
Gantt support is added to the repo as a plugin. Commit 67666 merged 31 Jan 2014
+
Set Keystone admin_bind_host
+
This works around an odd problem with Keystone's use of port 35357 and its use as an ephemeral port. Commit 57577 merged 30 Jan 2014
+
Generate Tempest service list
+
This eliminates the manual maintenance of the services Tempest checks for. Commit 70015 merged 30 Jan 2014
+
Fix stop_swift()
+
Kill all swift processes correctly with pkill. Commit 69440 merged 28 Jan 2014
+
Update Cinder cert script to use run_tempest
+
Update following changes to Tempest's run_tests.sh script. Commit 66904 merged 25 Jan 2014
+
Add missing mongodb client
+
The mongodb client was skipped on Fedora. Commit 65147 merged 25 Jan 2014
+
Fix reverting local changes in repo
+
Work around a bug in git diff --quiet used in reverting the repo changes during global requirements handling. Commit 68546 merged 25 Jan 2014
+
Add cirros 3.0 image for Xenserver
+
Xenserver wants the cirros 3.0 vhd image Commit 68136 merged 25 Jan 2014
+
Tweak upload_image.sh for .vmdk
+
Relax the vmdk regex for parsing metadata out of the filename. Commit 68821 merged 25 Jan 2014
+
Keystone use common logging
+
Switch Keystone to use common logging configuration. Commit 68530 merged 25 Jan 2014
+
Do not set bind_host for Heat APIs
+
Let the Heat API service bind to 0.0.0.0 to be consistent with other DevStack services. Commit 67683 merged 25 Jan 2014
+
Fine tune libvirt logging
+
Disable client-side log and tune server-side to usable levels. Commit 68194 merged 24 Jan 2014
+
Add check framework for Neutron server/backen integration
+
Add the framework to verify Neutron controllers and backend service configurations per plugin requirements. Commit 64754 merged 17 Jan 2014
+
Add Marconi to Tempest config
+
Check if Marconi is enabled in Tempest configuration Commit 65478 merged 13 Jan 2014
+
Enable libvirt logging
+
Enable server- and client-side logging for libvirt Commit 65834 merged 13 Jan 2014
+
Clean up Heat/Cloud Formation catalog template
+
The service catalog entries in the template file for orchestration and cloud formation were out of whack. Commit 65916 merged 13 Jan 2014
+
Create Ceilometer service accounts
+
Create the Ceilometer service accounts in Keystone. Commit 65678 merged 13 Jan 2014
+
Freshen Ubuntu supported eleases
+
Remove oneiric and quantal support. Commit 64836 merged 13 Jan 2014
+
Strengthen server shutdown
+
Add screen_stop() to kill server process groups to ensure shutdown of child processes. Commit 66080 merged 13 Jan 2014
+
Support for VMware NSX plugin
+
This is the Nicira NVP plugin renamed. Commit 65002 merged 13 Jan 2014
+
Remove --tenant_id usage
+
Remove remaining uses of --tenant_id and replace with --tenant-id. Commit 65682 merged 11 Jan 2014
+
Identity API version configuration for Cinder, Glance and Heat
+
Use IDENTITY_API_VERISON to configure Cinder, Glance and Heat. Commit 57620 merged 11 Jan 2014
+
Fedora 20 Support
+
Add support for Fedora 20, remove Fedora 16 and 17 support. Commit 63647 merged 11 Jan 2014
+
Trove service availablility in Tempest
+
Check if Trove is enabled in Tempest configuration. Commit 64913 merged 11 Jan 2014
+
+
Change libvirtd log level to DEBUG
+
Keep libvirtd logs in the gate log stash. Commit 63992 merged 02 Jan 2014
+
Fix section start bug in get_meta_section()
+
get_meta_section() would incorrectly interpret '[[' and ']]' in shell command lines inside local.conf. Commit 63280 merged 21 Dec 2013
+
Use Fedora 20 final release
+
Set the URL to get the final Fedora 20 release image. Commit 63200 merged 21 Dec 2013
+
Use Ubuntu 'saucy' as XenAPI DomU
+
Updated the XenAPI DomU to Ubuntu Saucy release. Commit 60107 merged 21 Dec 2013
+
Begin support for RHEL7 Beta
+
Adjust the sed regex in GetOSVersion() to handle text between the version and codename in RHEL-style release strings. Commit 62543 merged 17 Dec 2013
+
Configure Tempest tests for network extensions
+
Puts the value of NETWORK_API_EXTENSIONS into tempest.conf. Commit 62054 merged 17 Dec 2013
+
Default floating IP range to /24
+
Set the default FLOATING_RANGE=172.24.4.0/24 to accomodate parallel testing in Tempest. Commit 58284 merged 17 Dec 2013
+
Support oslo-rootwrap in Cinder
+
Cinder can use both cinder-rootwrap and oslo-rootwrap for a transitional period. Commit 62003 merged 16 Dec 2013
+
Heat tests can use test image if present
+
If HEAT_CREATE_TEST_IMAGE is defined and the image named in its value is present Heat will use it rather than invoke diskimage-builder. Commit 59893 merged 15 Dec 2013
+
Fix iniset() pipe ('|') bug
+
iniset() did not properly handle a value containing a pipe ('|') character. Commit 60170 merged 14 Dec 2013
+
Define Q_L3_ENABLED=True for MidoNet plugin
+
Q_L3_ENABLED=True for MidoNet plugin. Commit 56459 merged 12 Dec 2013
+
Fix Swift workers for non-proxies
+
Swift spawned more proxy workers than required in DevStack environments, reduce it to '1'. Commit 61122 merged 12 Dec 2013
+
Add Keystone auth port to Nova config
+
Set keystone_authtoken:auth_port to KEYSTONE_AUTH_PORT in nova.conf. Commit 60736 merged 12 Dec 2013
+
Increase additional flavor RAM on ppc64
+
Create the nano and micro flavors with 128MB and 256MB RAM respectively on ppc64. Commit 60606 merged 12 Dec 2013
+
Increase XenAPI DomU memory
+
Increase XenAPI DomU memory (OSDOMU_MEM_MB) to 4GB by default. Commit 59792 merged 10 Dec 2013
+
Assign unique names to fake nova-computes
+
Assign each fake nova-compute instance a unique name so the scheduler works properly. Commit 58700 merged 09 Dec 2013
+
Fix whitespace bugs in merge_config_file()
+
Merge_config_file() did not properly skip lines with only whitespace. Commit 60112 merged 09 Dec 2013
+
Setup Savanna user and endpoints
+
Create savanna user, and savanna and data_processing endpoints. Commit 60077 merged 09 Dec 2013
+
Display DevStack status at XenAPI DomU login
+
Add DevStack setup setvice status to /etc/issue so it is displayed at the DomU login. Commit 48444 merged 09 Dec 2013
+
Fix install_get_pip using proxy
+
install_get_pip did not work properly through an HTTP proxy. Commit 60242 merged 07 Dec 2013
+
Add color logs to Trove
+
Add the colorized log output to Trove. Commit 58363 merged 06 Dec 2013
+
Update LDAP support
+
Update DevStack's LDAP support to make the DN configurable. Commit 58590 merged 06 Dec 2013
+
Add Marconi support
+
Add Marconi support via extras.d plugin. Commit 47999 merged 05 Dec 2013
+
Split Ceilometer collector service
+
Split Celio collector service into ceilometer-collector and ceilometer-agent-notification. Commit 58600 merged 05 Dec 2013
+
Add 'post-extra' configuration phase
+
The 'post-extra' configuration phase is processed after the 'extra' plugin phase is executed. Commit 55583 merged 05 Dec 2013
+
Enable user interaction with stack.sh in XenAPI
+
Multiple changes to how DevStack is configured to run under XenServer. Commit 48092 merged 04 Dec 2013
+
Handle VMDK metadata
+
upload_image.sh now attempts to get the metadata for a *.vmdk file from *-flat.vmdk. Commit 58356 merged 04 Dec 2013
+
Deploy Keystone with SSL
+
Configure Keystone to use SSL rather than using the tls-proxy function. Commit 47076 merged 03 Dec 2013
+
change default Git base to git.openstack.org
+
Pull repos from git.openstack.org where possible. Commit 56749 merged 02 Dec 2013
+
Fix Neutron color log format
+
Fix Neutron color log format. Commit 58350 merged 01 Dec 2013
+
Truncate PKI token logging
+
Limit the PKI token logged to 12 characters. Commit 57526 merged 26 Nov 2013
+
Support memchace for Keystone token backend
+
Use memcache backend with KEYSTONE_TOKEN_BACKEND=memcache. Commit 56691 merged 26 Nov 2013
+
Remove powervm hypervisor support
+
The powervm arch is EOL, will be replaced in the future. Commit 57789 merged 25 Nov 2013
+
Increase default Swift timeouts
+
node_timeout and conn_timeout needed to be increased for testing in slow VM environments. Commit 57514 merged 25 Nov 2013
+
Add hacking rules for shell scripts
+
Record the previously unwritten rules for common formatting. Commit 55024 merged 24 Nov 2013
+
Default to Cinder API v2
+
Set OS_VOLUME_API_VERSION=2 by default. Commit 43045 merged 22 Nov 2013
+
Drop nodejs dependency
+
Horizon no longer needs nodejs. Commit 55255 merged 22 Nov 2013
+
Change to use STACK_USER rather than USER
+
This changes DevStack to use STACK_USER for username references. Commit 57212 merged 22 Nov 2013
+
Enable specifying FLAT_NETWORK_BRIDGE in XenAPI
+
Set FLAT_NETWORK_BRIDGE for DomU. Commit 48296 merged 22 Nov 2013
+
Add file: URL handling to upload_image.sh
+
upload_image.sh can now use file: URLs as the image source. Commit 56721 merged 21 Nov 2013
+
Increase Swift backing storage size
+
Swift now has SWIFT_LOOPBACK_DISK_SIZE_DEFAULT=6G. Commit 56116 merged 13 Nov 2013
+
Fix Horizon config for Apache 2.4
+
Handle Apache config differences according to Apache version and not distro release. Commit 54738 merged 11 Nov 2013
+
Add FORCE_CONFIG_DRIVE to nova.conf
+
Add FORCE_CONFIG_DRIVE, default to 'always'. Commit 54746 merged 01 Nov 2013
+
Turn off Nova firewall when using Neutron
+
Sets firewall_driver when Neutron is enabled. Commit 54827 merged 01 Nov 2013
+
Use nova.conf for auth_token config
+
Eliminates using api-paste.ini. Commit 53212 merged 01 Nov 2013
+
Use conder.conf for auth_token config
+
Eliminates using api-paste.ini. Commit 53213 merged 01 Nov 2013
+
Add Cinder support for NFS driver
+
Set CINDER_DRIVER=nfs. Commit 53276 merged 31 Oct 2013
+
Add Postgres for Ceilometer backend
+
Set CEILOMETER_BACKEND=postgresql. Commit 53715 merged 31 Oct 2013
+
Add Ubuntu Trusty
+
Add support for Ubuntu Trusty. Commit 53965 merged 30 Oct 2013
+
Enable Keystone auth in Ironic
+
Always use Keystone for Ironic auth. Commit 51845 merged 25 Oct 2013
+
Add bash8 tool
+
Perform basic format tests in CI gate. Commit 51676 merged 23 Oct 2013
+
Add Savanna support
+
Add Savanna support using the plugin mech. Commit 50601 merged 22 Oct 2013
+
Install Ironic client
+
Add python-ironicclient repo. Commit 51853 merged 22 Oct 2013
+
+
Fix fixup_stuff.sh for RHEL6
+
fixup_stuff.sh didn't work properly on RHEL6/Python 2.6 Commit 52176 merged 17 Oct 2013
+
Add more extras.d hooks
+
Add more hooks to call into extras.d to support adding services without modifying core DevStack scripts. Commit 51939 merged 16 Oct 2013
+
Add run_tests.sh
+
Add a simple run_tests.sh for running bash8. Commit 51711 merged 15 Oct 2013
+
Add bash8 style checker
+
Add bash8 to check certain style constraints in shell scripts. Commit 51676 merged 15 Oct 2013
+
Add trove-conductor service
+
Add trove-conductor service to Trove support Commit 49237 merged 14 Oct 2013
+
Add new local configuration file
+
Add local.conf support to replace localrc, includes ability to set values in arbitrary config files. Commit 46768 merged 14 Oct 2013
+
Remove 'stack' account creation from stack.sh
+
This forces stack.sh to not be run as root and provides the account creation as a separate script. Commit 49798 merged 05 Oct 2013
+
Support running Keystone under Apache
+
Run Keystone under Apache along with Swift and Horizon Commit 46866 merged 26 Sep 2013
+
Increase default Swift storage for Tempest
+
When Tempest is enabled increase the default Swift storage to 4Gb Commit 46770 merged 18 Sep 2013
+
Keystone mixed backend support
+
Add support for Keystone to use mixed backend configuration Commit 44605 merged 16 Sep 2013
+
Add Trove support
+
Add support for Trove service Commit 38169 merged 12 Sep 2013
+
Enable Neutron L3 plugon
+
Support Neutron's L3 plugin Commit 20909 merged 10 Sep 2013
+
Configure VPNaaS panel in Horizon
+
If enabled configure VPNaaS panel in Horizon by default Commit 45751 merged 10 Sep 2013
+
Enable multi-threaded Nova API servers
+
Sets the Nova API servers to use four worker threads by default Commit 45314 merged 09 Sep 2031
+
Handle .vmdk custom properties
+
Parses property values out of the .vmdk filename and includes them in the glance upload. Commit 45181 merged 09 Sep 2013
Add support for OpenStack Networking Firewall (FWaaS). Commit 37147 merged 29 Aug 2013
+
Add new #testonly tag for package prereq files
+
Add INSTALL_TESTONLY_PACKAGES to enable installing packages marked with #testonly. These packages are required only for running unit tests. Commit 38127 merged 28 Aug 2013
+
Add support for Heat environments
+
Install Heat global environment config files. Commit 43387 merged 28 Aug 2013
+
Configure bash completion
+
Configure bash completion for cinder, keystone, neutron, nova and nova-manage. Commit 41928 merged 26 Aug 2013
+
Change horizon Apache config file to horizon.conf
+
Add .conf to horizon Apache config file to be consistent with Fedora practice. Commit 40352 merged 22 Aug 2013
+
Echo service start failures
+
Echo service start failures to console so status is obvious in gate logs. Commit 42427 merged 16 Aug 2013
+
Colorize Heat logs
+
Add Nova-style color support to Heat logging. Commit 40342 merged 16 Aug 2013
+
Add Cinder support to VMware configuration
+
Configures Cinder to use VMware backend. Commit 41612 merged 15 Aug 2013
+
Default PIP_USE_MIRRORS to False
+
Pip mirrors no longer used by default, can stil be enabled with PIP_USE_MIRRORS=True. Commit 40623 merged 13 Aug 2013
+
Configure Volume API v2
+
Configure both SQL and template backends with Volume API v2. Commit 22489 merged 13 Aug 2013
+
Enable Tempest debug logging
+
Enable Tempest debug logging for the same output verbosity under testr. Commit 41113 merged 12 Aug 2013
+
Configure Cinder for Ceilometer notifications
+
Enable Cinder to send notifications when Ceilometer is enabled. Commit 41108 merged 12 Aug 2013
+
Support Heat-only configuration
+
Allows stack.sh to start a standalone Heat installation. Commit 39602 merged 10 Aug 2013
+
Add tools/install_pip.sh
+
Install pip from source in order to get a current version rather than the out-of-date OS-supplied version Commit 39827 merged 08 Aug 2013
+
Add call trace to error message
+
Display the bash call stack in die() output. Commit 39887 merged 08 Aug 2013
+
Configure Keystone client in Cinder
+
Configure auth creds in Cinder to allow queries to Keystone. Commit 39747 merged 07 Aug 2013
+
Update all repos to global requirements
+
Force update project repos to global requirements before tests. Commit 35705 merged 06 Aug 2013
+
Don't add 'bulk' middleware for Swift
+
The bulk middleware is already in the sample so don't add it. Commit 39826 merged 06 Aug 2013
+
Enable using Apache as Swift frontend
+
Refactor apache functions into lib/apache; configure apache2 vhost and wsgi files for Swift proxy, account, container and object server. Commit 33946 merged 02 Aug 2013
+
Launch Ceilometer alarm services
+
Add ceilometer-alarm-notify and ceilometer-alarm-eval to the Ceilometer services. Commit 39300 merged 01 Aug 2013
+
Fix Tempest logging configuration
+
Correctly set the tempest output logging to dump all of tempest logs into a tempest.log file. Also fixes logging in the gate no longer print every log message on the console. Commit 39571 merged 31 Jul 2013
+
Install Oslo from source
+
Install the gradulated Oslo libraries from source into $DEST. Commit 39450 merged 31 Jul 2013
+
Multiple fixes for cell support
+
Start Nova cell services; skip unsupported exercises; use 'default' security group in exercises. Commit 38897 merged 29 Jul 2013
+
Add MySQL support for Ceilometer
+
Add MySQL storage support for Ceilometer. Commit 37413 merged 19 Jul 2013
+
Create Compute API v3 endpoint
+
Configures SQL and templated backends for Compute API v3. The service type is 'computev3'. Commit 33277 merged 18 Jul 2013
+
Add Neutron VPNaaS support
+
Add Support for OpenStack Networking VPNaaS (IPSec) Commit 32174 merged 15 Jul 2013
+
Configure Swift functional tests
+
The default Swift configuration now has functional tests properly configured. Commit 35793 merged 12 Jul 2013
+
Enable all Nova notifications
+
Nova now sends all notification events to Ceilometer. Commit 35258 merged 08 Jul 2013
+
Add IDENTITY_API_VERSION
+
IDENTITY_API_VERSION defaults to '2.0', enables setting '3' for API v3. Commit 34884 merged 08 Jul 2013
+
+
Rename Qunatum repos to Neutron
+
Part of the project renaming process. This does not change the process short names ('q-api', 'q-agt', etc) or the variable names starting with Q_. Some Nova and Horizon changes remain to be completed. The change has been applied to stable/grizzly (35860) and stable/folsom (35861). Commit 35981, 35861, 35860, 35859 merged 07 Jul 2013
+
Direct installation of Python prerequisites
+
Python prereqs are now installed by pip (and not easy_install) directly from each projects requirements.txt. Commit 35696 merged 07 Jul 2013
+
Enable Fedora 19
+
Fedora 19 is now supported directly. Commit 35071 merged 03 Jul 2013
+
Fix Cinder clones on RHEL 6/CentOS
+
On RHEL 6/CentOS 6 cloned LVM volumes required more space for metadata storage. Commit 34640 merged 28 Jun 2013
+
Use lower case section names in Quantum
+
The service code now supports lowercase section names, change DevStack to use them by default. Commit 34177 merged 27 Jun 2013
+
Set default VOLUME_BACKING_FILE to 10Gb
+
The previous default of 5Gb was not large enough for some Tempest usage requirements. Commit 33885 merged 21 Jun 2013
+
Use service role for service accounts
+
Use an account with service role assigned rather than a full admin account for swift, heat, ceilometer. Ceilometer was later restored to admin account in 33838. Commit 31687 merged 16 Jun 2013
+
Enable Nova API v3
+
Nova disables API v3 by default so explicitly enable it. Commit 31190 merged 31 May 2013
+
Enable Debian support
+
Allows Devstack to run on Debian as an unsupported OS. Commit 28215 merged 9 May 2013
+
Default SWIFT_DATA_DIR to use $DATA_DIR
+
Previously SWIFT_DATA_DIR was in $DEST/data. Commit 27749 merged 3 May 2013
+
Set default S3_URL port to 8080
+
Set port to 8080 if swift3 is enabled, previously was nove objectstore value of 3333. Commit 27404 merged 25 Apr 2013
+
+
Use example settings in horizon repo as local_settings.py
+
Removes files/horizon_settings.py and copies the same file from the Horizon repo. Commit 25510 merged 28 Mar 2013
+
Add support for iso files as glance images
+
Add support for iso files as glance images Commit 25290 merged 28 Mar 2013
+
+
Allow processes to run without screen
+
Add USE_SCREEN=False to localrc to cause all server processes to run without screen. This is expected to be used primarily in the CI tests and should address the failures seen when screen does not start a process. Commit 23148 merged 20 Mar 2013
+
Add clean.sh
+
This is intended to remove as much of the non-packaged (both OS and pip) remnants of DevStack from the system. It is suitable for changing queue managers and databases as those packages are uninstalled. It does not change the network configuration that Nova performs nor does it even attempt to undo anything that Quantum does. Commit 24360 merged 15 Mar 2013
+
Add support for running a specific set of exercises
+
Set RUN_EXERCISES to a comma separated list of exercise names to run. SKIP_EXERCISES is ignored in this mode. Commit 23846 merged 15 Mar 2013
+
Deprecate DATABASE_TYPE and use_database
+
This changes the way that a database is selected back to using only ENABLED_SERVICES. Backward compatibility is maintained until after Grizzly is released. Commit 22635 merged 22 Feb 2013
+
Create tools/install_prereqs.sh
+
This factors out the installation/upgrade of required OS packages so it can run independently of stack.sh. It also adds a time marker so it does not run again within a set amount of time, default is 2 hours. Remove .prereqs to reset this timeout. Commit 21397 merged 10 Feb 2013
+
Add initial LDAP support
+
Installs and configures OpenLDAP for Keystone. Select by adding enable_service ldap and KEYSTONE_IDENTITY_BACKEND=ldap to localrc. Commit 20249 merged 07 Feb 2013
+
Add variable to set Keystone token backend
+
Change the default Keystone token backend from kvs to sqlby setting KEYSTONE_TOKEN_BACKEND=sql. Commit 20739 merged 30 Jan 2013
+
Add Sheepdog support in Cinder
+
This enables using Sheepdog as a Cinder backend storage by setting CINDER_DRIVER=sheepdog. Commit 19931 merged 18 Jan 2013
+
Support SPICE
+
Adds an 'n-spice' service (off by default) that supports SPICE in the Nova libvirt driver. It also allows running in a SPICE only environment. Commit 19934 merged 18 Jan 2013
+
+
Add a mechanism to automatically load additional projects at the end of stack.sh
+
This differs from loca.sh in that scripts can be dropped into local.d and stack.sh will source them in alphanumeric order. Commit 19367 merged 11 Jan 2013
+
Add support fir baremetal hypervisor
+
This is the first of a set of commits that enable baremetal support. Commit 15941 merged 28 Dec 2012
+
Add support for OpenSuSE 12.2
+
This is actually just the commit to remove the need for FORCE=yes, OpenSuSE support has been coming along for a while. Commit 18479 merged 27 Dec 2012
+
Save selected environment variables from stack.sh for later use
+
Write a set of environment variables to .stackenv so they can be quickly used by other scripts. These are mostly the variables that are derived and not statically set. .stackenv is overwritten on every stack.sh run.Commit 18094 merged 19 Dec 2012
+
Enable Tempest by default
+
Tempest is now downloaded and configured by default in DevStack. This is to encourage more developers to use it as part of their workflow. Tempest configuration is now handled in lib/tempest; tools/configure_tempest.sh has been removed. Commit 17808 merged 12 Dec 2012
+
+
Add PostgreSQL support
+
Adds an abstraction layer to database configuration and adds support for PostgreSQL under that. MySQL is still the default. To use add use_database postgresql to localrcCommit 15224 merged 05 Nov 2012
+
Add PKI token configuration support
+
Adds configuration KEYSTONE_TOKEN_FORMAT to select PKI or UUID token format. The default is PKI.Commit 14895 merged 29 Oct 2012
+
Add Ubuntu Raring Ringtail support
+
Adds raring to the list of supported Ubuntu releasesCommit 14692 merged 24 Oct 2012
+
Add support for Quantum Ryu plugin
+
Ryu plugin lets Quantum link Open vSwitch and Ryu OpenFlow controllerCommit 10117 merged 20 Oct 2012
+
Configure and launch HEAT API
+
Creates a new enpoint using service type 'orchestration'.Commit 14195 merged 10 Oct 2012
+
Fix upload image handling
+
Detect qcow, raw, vdi, vmdk image formats and sets Glance's disk format accordingly. Commit 13044 merged 24 Sep 2012
+
+
Add non-verbose output mode
+
Set VERBOSE=False in localrc and see only periodic status messages on the screen. The detailed output continues to be written to the log file if LOGFILE is set. Commit 12996 merged 17 Sep 2012
+
+
Move data directories out of source repos
+
Data for Glance (images and cache) and Nova (instances, all state info) have historically been in the source repo. They have been moved to $DEST/data/<project> by default. Commit 12989 merged 14 Sep 2012
+
+
Change default Keystone backend to SQL
+
Keystone now uses the SQL backend by default enabling the use of the CRUD API; now keystone service-create ... works. Set KEYSTONE_CATALOG_BACKEND=template to maintain the previous behaviour. Commit 12746 merged 12 Sep 2012
+
+
Set FLAT_INTERFACE for local-only use
+
Allow FLAT_INTERFACE to be defined as "" to prevent the HOST_IP from being moved to br100. Commit 12671 merged 09 Sep 2012
+
+
Add support for Quantum L3 agent
+
Only available with OpenVSwitch plugin. Commit 11380 merged 08 Sep 2012
Chmouel has brought Vishy's colored log file patch to Cinder. Commit 10769 merged 16 Aug 2012
+
+
Keystone auth middleware from Swift
+
Swift now uses keystoneauth by default. Commit 10876 merged 16 Aug 2012
+
+
Add support for NO_PROXY
+
Added support for the standard no_proxy environment variable. Commit 10264 merged 10 Aug 2012
+
+
Use default route to find HOST_IP
+
This changed the login for hunting down the value of HOST_IP to look on the interface that has the default route. Commit 9291 merged 10 Aug 2012
+
+
Enable testing of OpenVZ guests
+
Allows using OpenVZ virtualization layer. Commit 10317 merged 07 Aug 2012
+
+
Cinder is the default volume service
+
DevStack is now configured to use Cinder as its volume service by default. Commit 9662 merged 27 Jul 2012
+
+
Increase size of default volume backing file
+
The volume backing file is now 5Gb by default. It can still be set using VOLUME_BACKING_FILE_SIZE in localrc. Commit 9837 merged 19 Jul 2012
+
+
Configure pip cache location
+
Set PIP_DOWNLOAD_CACHE to the location of a root-writable directory to cache downloaded packages. Commit 9766 merged 16 Jul 2012
+
+
Add functions to manipulate ENABLED_SERVICES
+
Now ENABLED_SERVICES can be edited in localrc by using enable_service() and disable_service(). Commit 9407 merged 13 Jul 2012
+
+
Change default Nova virt driver configuration
+
Change the Nova configuration to use compute_driver rather than connection_type. Commit 9635 merged 13 Jul 2012
+
+
Add support for Keystone PKI
+
Initializes Keystone's PKI configuration to support delegation and scaling. Commit 9240 merged 13 Jul 2012
+
+
Disable Swift S3 support by default
+
Swift's S3 API support can be enabled by adding swift3 to ENABLED_SERVICES. Commit 9346 merged 12 Jul 2012
+
+
Set libvirt CPU mode
+
Force libvirt_cpu_move=none to work around some nested virtualization issues. Commit 9718 merged 12 Jul 2012
+
+
Support Nova rootwrap
+
Add support for Nova rootwrap configuration. Commits 8842 merged 25 Jun 2012 and 8750 merged 20 Jun 2012
+
+
Add Cinder support
+
Cinder can now be enabled by adding c-api,c-sch,c-vol to ENABLED-sERVICES. This also changed a couple of defaults: VOLUME_GROUP is now stack-volumes and VOLUME_BACKING_FILE is now ${DEST}/data/${VOLUME_GROUP}-backing-file. Commit 7042 merged 20 Jun 2012
+
+
Set default image for exercises
+
Set DEFAULT_IMAGE_NAME in stackrc to the cirros images downloaded. This avoids the ambiguous search for an 'ami'. Commit 7910 merged 14 Jun 2012
+
+
Use default Swift config files
+
Use the configuration files shipped with Swift source rather than carrying files in the DevStack sources. Commit 8223 merged 14 Jun 2012
+
+
Install Swift client
+
Install the new Swift client when Swift is enabled. Commit 7663 merged 11 Jun 2012
+
+
Use pip to install Python dependencies
+
Use the dependencies in the *.egg-info/requires.txt and *.egg-info/dependency_links.txt to prevent easy_install from resolving the dependencies. Commit 8289 merged 07 Jun 2012
+
+
Remove support for DevStack pip dependencies
+
Remove DevStack Python dependency files files/pips/* and handle Python dependencies through tools/pip-requires. Commit 8263 merged 07 Jun 2012
+
+
Update XenServer support
+
Updates to work with xcp-xapi package on Ubuntu 12.04 and fix a number of other minor install problems. Commits 7673 and 7449 merged 01 Jun 2012
+
+
Enable Quantum multi-node
+
Enable running Quantum agents on multiple nodes. Commit 7001 merged 26 May 2012
+
+
Reinitialize Swift data store
+
Create a new XFS filesystem on the Swift data store on every stack.sh run. Commit 7554 merged 22 May 2012
+
+
Add support for Qpid
+
Configure Qpid RPC by replacing rabbit with qpid in ENABLED_SERVICES. Commit 6501 merged 17 May 2012
+
+
Glance uses Swift if enabled
+
If Swift is enabled Glance will store images there by default. Commit 7277 merged 15 May 2012
+
+
Add Quantum linuxbridge support
+
Support using linuxbridge in Quantum. Commit 7300 merged 10 May 2012
+
+
Change Nova volume name template
+
Change Nova's volume_name_template to ${VOLUME_NAME_PREFIX}%s. Commit 7004 merged 02 May 2012
+
+
Change MySQL engine default
+
Use InnoDB engine in MySQL by default. Commit 6185 merged 30 Apr 2012
+
+
Add Glance client
+
Add new python-glanceclient to override the clinet in the Glance repo. Config 6533 merged 26 Apr 2012
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:
+
+
contain all non-default local configuration in a single file
+
be backward-compatible with localrc to smooth the transition process
+
allow settings in arbitrary configuration files to be changed
+
+
+
local.conf
+
The 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 two '[[ ]]' chars 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:
+
+
local - extracts localrc from local.conf before stackrc is sourced
+
post-config - runs after the layer 2 services are configured and before they are started
+
extra - runs after services are started and before any files in extra.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.
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.
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]]
+
+
+
The existing ``EXTRAS_OPTS`` and similar variables are now deprecated. If used a warning will be printed at the end of the stack.sh run.
+
+
+
Minimal Configuration
+
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.
+
+
no logging
+
pre-set the passwords to prevent interactive prompts
+
move network ranges away from the local network (FIXED_RANGE and FLOATING_RANGE, commented out below)
+
set the host IP if detection is unreliable (HOST_IP, commented out below)
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.
+
+
Common Configuration Variables
+
+
Set DevStack install directory
+
Default: DEST=/opt/stack
+ The DevStack install directory is set by the DEST 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
+
+
stack.sh logging
+
Defaults: LOGFILE="" LOGDAYS=7 LOG_COLOR=True
+ By default stack.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 logging
+
Default: SCREEN_LOGDIR=""
+ By default DevStack runs the OpenStack services using 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.
+
+
One syslog to bind them all
+
Default: SYSLOG=False SYSLOG_HOST=$HOST_IP SYSLOG_PORT=516
+ Logging all services to a single syslog can be convenient. Enable syslogging by seting SYSLOG 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.
+
Default: RECLONE=""
+ By default 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
+
Default: SWIFT_HASH="" SWIFT_REPLICAS=1 SWIFT_DATA_DIR=$DEST/data/swift
+ Swift is now used as the back-end for the S3-like object store. When enabled Nova's objectstore (n-obj in ENABLED_SERVICES) is automatically disabled. Enable Swift by adding it services to ENABLED_SERVICES:
+
+ 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.
+
+
+
Service Catalog Backend
+
Default: KEYSTONE_CATALOG_BACKEND=sql
+ DevStack uses Keystone's sql 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.sh
+
+
Cinder
+
Default: VOLUME_GROUP="stack-volumes" VOLUME_NAME_PREFIX="volume-" VOLUME_BACKING_FILE_SIZE=10250M
+ The logical volume group used to hold the Cinder-managed volumes is set by VOLUME_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.
+
Default: MULTI_HOST=False
+ Running DevStack with multiple hosts requires a custom local.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.
+
Default: API_RATE_LIMIT=True
+ Integration tests such as Tempest will likely run afoul of the default rate limits configured for Nova. Turn off rate limiting during testing by setting API_RATE_LIMIT=False.
+
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.
+
+
Things To Know
+
+ Where Things Are
+
The official DevStack repository is located at git://github.com/openstack-dev/devstack.git and git://git.openstack.org/openstack-dev/devstack.git, both mirrors of the official repo maintained by Gerrit.
+
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.
+
+ HACKING.rst
+
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.
+
+ bash8 Formatting
+
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 bash8. 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.
+
+
Code
+
+ Repo Layout
+
The DevStack repo generally keeps all of the primary scripts at the root level.
+
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 pamdisk 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 and Docker.
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.
+
+
+
+
EC2_URL
+
Set the EC2 url for euca2ools. The endpoint is extracted from the
+ service catalog for OS_TENANT_NAME:OS_USERNAME.
+
Euca2ools requires certificate files to enable bundle uploading.
+ The exercise script exercises/bundle.sh demonstrated
+ retrieving certificates using the Nova CLI.
+
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
+
Max time to wait while vm goes from build to active state
+
ACTIVE_TIMEOUT==30
+
+
ASSOCIATE_TIMEOUT
+
Max time to wait for proper IP association and dis-association.
+
ASSOCIATE_TIMEOUT=15
+
+
BOOT_TIMEOUT
+
Max time till the vm is bootable
+
BOOT_TIMEOUT=30
+
+
RUNNING_TIMEOUT
+
Max time from run instance command until it is running
+
A: No. We mean it. Really. DevStack makes some implementation choices that are not appropriate for production deployments. We warned you!
+
+
Q: Then why selinux in enforcing mode?
+
A: That is the default on current Fedora and RHEL releases. DevStack has (rightly so) a bad reputation for its security practices; it has always been meant as a development tool first and system integration later. This is changing as the security issues around OpenStack's use of root (for example) have been tightened and developers need to be better equipped to work in these environments. 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.
+
+
Q: But selinux is disabled in RHEL 6!
+
A: Today it is, yes. That is a specific exception that certain DevStack contributors fought strongly against. The primary reason it was allowed was to support using RHEL6 as the Python 2.6 test platform and that took priority time-wise. This will not be the case with RHEL 7.
+
+
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 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: LXC support is not complete on Fedora; 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...
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:
+
Q: Why not use tools/pip-requiresrequirements.txt 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. 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?
A: You may have run into the package prerequisite installation timeout. 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.
+
Q: tools/fixup_stuff.sh is broken and shouldn't 'fix' just one version of packages.
+
A: [Another not-a-question] No it isn't. Stuff in there is to correct problems in an environment that need to be fixed elsewhere or may/will be fixed in a future release. In the case of 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.
+
+
+
+
+
Prerequisites Linux & Network
+
+
+
Minimal Install
+
You need to have a fresh install of Linux on all of your nodes. You can download the Minimal CD for Ubuntu 12.04 (only 27MB) 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:
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:
+
+
Gateway: 192.168.42.1
+
Physical nodes: 192.168.42.11-192.168.42.99
+
Floating IPs: 192.168.42.128-192.168.42.254
+
+
Configure each node with a static IP.
+ For Ubuntu edit /etc/network/interfaces:
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 priviledges below. Otherwise create the stack user:
This user will be making many changes to your system during installation and operation
+ so it needs to have sudo priviledges to root without a password:
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.
+
+
Configure Cluster Controller
+
The cluster controller runs all OpenStack services. Configure the cluster controller's DevStack in local.conf:
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.
+
+
Configure Compute Nodes
+
The compute nodes only run the OpenStack worker services. For additional machines, create a local.conf with:
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.
+
+
Cleaning Up After DevStack
+
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:
DevStack creates two OpenStack users (admin and demo) and two tenants (also admin and demo). admin is exactly what it sounds like, a priveleged 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
+
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 swift
+
+
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.
+
+
Volumes
+
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:
DevStack is capable of using rsyslog to agregate 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
+
+
Using Alternate Repositories/Branches
+
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:
PXE Boot Server Guide: Magic Dust for Network Boot
+
Boot DevStack from a PXE server to a RAM disk.
+
+
+
+
+
Prerequisites Hardware & OpenWRT
+
+
+
Hardware
+
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.
+
+
OpenWRT
+
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.
+
+
+
+
+
Installation bit blasting
+
+
+
Install the Image
+
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.
+
+
Get openwrt-ar71xx-wzr-hp-g300nh-squashfs-tftp.bin
+
Reset the DHCP address range. DevStack will claim the upper
+ /25 of the router's LAN address space for floating IPs so the
+ default DHCP address range needs to be moved:
+
uci set dhcp.lan.start=65
+uci set dhcp.lan.limit=60
+uci commit dhcp
+
+
Enable TFTP:
+
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
+
+
+
+
Set Up tftpboot
+
+
Create the /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.
+
+
Copy tftpboot to a USB drive:
+
mount /dev/sdb1 /mnt/tmp
+rsync -a /tmp/tftpboot/ /mnt/tmp/tftpboot/
+umount /mnt/tmp
+
+
Plug USB drive into router. It will be automounted and is ready to serve content.
+
+
+
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.
+
+
+
+
+
Prerequisites Hardware
+
+
+
USB Boot
+
This guide covers the creation of a bootable USB drive. Your
+ computer BIOS must support booting from USB.
+
+
PXE Boot
+
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.
+
Boot the computer into the RAM disk. The details will vary from
+ machine to machine but most BIOSes have a method to select the
+ boot device, often by pressing F12 during POST.
+
Select 'DevStack' from the Boot Menu.
+
Log in with the 'stack' user and 'pass' password.
+
Create 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:
+
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.
+
+
+
+
+
Prerequisites Linux & Network
+
+
+
Minimal Install
+
You need to have a system with a fresh install of Linux. You can download the Minimal CD for Ubuntu 12.04 (only 27MB) 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.
+
+
Network Configuration
+
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).
+
+
+
+
+
Installation shake and bake
+
+
+
Add your user
+
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 priviledges below)
+
adduser stack
+
Since this user will be making many changes to your system, it will need to have sudo priviledges:
Now to configure stack.sh. DevStack includes a sample in devstack/samples/local.conf. Create local.conf as shown below to do the following:
+
+
Set 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.
+
Set FIXED_RANGE and FIXED_NETWORK_SIZE to configure the internal address space used by the instances.
+
Set 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.
+
Set the administrative password. This password is used for the admin and demo accounts set up as OpenStack users.
+
Set the MySQL administrative password. The default here is a random hex string which is inconvenient if you need to look at the database directly for anything.
+
Set the RabbitMQ password.
+
Set the service password. This is used by the OpenStack services (Nova, Glance, etc) to authenticate with Keystone.
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.
+
+
Using 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 accessable 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.
+
+
+
+
+
Prerequisites Cloud & Image
+
+
+
Virtual Machine
+
DevStack should run in any virtual machine running a supported Linux release. It will perform best with 2Gb or more of RAM.
+
+
OpenStack Deployment & cloud-init
+
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.
+
+
+
+
+
Installation shake and bake
+
+
+
Launching With Cloud-Init
+
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.
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.
+
+
Launching By Hand
+
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.
+
+
Using OpenStack
+
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!
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.
+
+
Software
+
Ubuntu 11.10 (Oneiric Ocelot) is required on host to create images.
+
+
+
+
+
Installation bit blasting
+
+
+
Set Up USB Drive
+
+
Insert the USB drive into the computer. Make a note of the device name, such as
+ sdb. Do not mount the device.
+
Install the boot system:
+
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.
+
+
If desired, you may now mount the device:
+
mount /dev/sdb1 /mnt/tmp
+# foo
+umount /mnt/tmp
+
+
+
+
Now return to the RAM disk Guide to kick
+ off your DevStack experience.
Only Ubuntu 12.04 (Precise), 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.
+
+
+
Install Selected OS
+
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.
The devstack repo contains a script that installs OpenStack and templates for configuration files
+
+
+
Configure
+
While optional, we recommend a minimal configuration be set up as you may not want our default values for everything.
+
+
+
Start the install
+
cd devstack; ./stack.sh
+
It takes a few minutes, we recommend reading the script while it is building.
+
+
+
+
+
+
+
Guides Walk through various setups used by stackers
+
+
+
+
OpenStack on VMs
+
+
+
+
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.
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.
+
+
+
+
OpenStack on 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.
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.
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
+
The introduction of Keystone to the OpenStack ecosystem has standardized the
+ term tenant as the entity that owns resources. In some places references
+ still exist to the original Nova term project for this use. Also,
+ tenant_name is prefered to tenant_id.
+
OS_TENANT_NAME=demo
+
+
OS_USERNAME
+
In addition to the owning entity (tenant), Nova stores the entity performing
+ the action as the user.
+
OS_USERNAME=demo
+
+
OS_PASSWORD
+
With Keystone you pass the keystone password instead of an api key.
+ Recent versions of novaclient use OS_PASSWORD instead of NOVA_API_KEYs
+ or NOVA_PASSWORD.
+
OS_PASSWORD=secrete
+
+
HOST_IP, SERVICE_HOST
+
Set API endpoint host using 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
+
Authenticating against an OpenStack cloud using Keystone returns a Token
+ and Service Catalog. The catalog contains the endpoints for all services
+ the user/tenant has access to - including Nova, Glance, Keystone and Swift.
+
OS_AUTH_URL=http://$SERVICE_HOST:5000/v2.0
+
+
GLANCE_HOST
+
Some exercises call Glance directly. On a single-node installation, Glance
+ should be listening on HOST_IP. If its running elsewhere
+ it can be set here.
+
GLANCE_HOST=$HOST_IP
+
+
KEYSTONECLIENT_DEBUG, NOVACLIENT_DEBUG
+
Set command-line client log level to DEBUG. These are
+ commented out by default.
+
DevStack is not and has never been intended to be a general OpenStack installer. It has evolved to support a large number of configuration options and alternative platforms and support services. However, that evolution has grown well beyond what was originally intended and the majority of configuration combinations are rarely, if ever, tested. DevStack was never meant to be everything to everyone and can not continue in that direction.
+
Below is a list of what is specifically is supported (read that as "tested and assumed to work") going forward.
+
+
Supported Components
+
+
Base OS
+
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).
+
+
Ubuntu: current LTS release plus current development release
+
Fedora: current release plus previous release
+
RHEL: current major release
+
Other OS platforms may continue to be included but the maintenance of those platforms shall not be assumed simply due to their presence. Having a listed point-of-contact for each additional OS will greatly increase its chance of being well-maintained.
+
Patches for Ubuntu and/or Fedora will not be held up due to side-effects on other OS platforms.
+
+
+
Databases
+
As packaged by the host OS
+
+
MySQL
+
PostgreSQL
+
+
+
Queues
+
As packaged by the host OS
+
+
Rabbit
+
Qpid
+
+
+
+
Web Server
+
As packaged by the host OS
+
+
Apache
+
+
+
OpenStack Network
+
Default to Nova Network, optionally use Neutron
+
+
Nova Network: FlatDHCP
+
Neutron: A basic configuration approximating the original FlatDHCP mode using linuxbridge or OpenVSwitch.
+
+
+
Services
+
The default services configured by DevStack are Identity (Keystone), Object Storage (Swift), Image Storage (Glance), Block Storage (Cinder), Compute (Nova), Network (Nova), Dashboard (Horizon)
+
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.
+
+
Node Configurations
+
+
single node
+
multi-node is not tested regularly by the core team, and even then only minimal configurations are reviewed
+
+
+
Exercises
+
The DevStack exercise scripts have been replaced as integration and gating test with Tempest. They will continue to be maintained as they are valuable as 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.
+
+
Extras.d Hooks
+
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" == "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:
+
+
source - Called by each script that utilizes extras.d hooks; this replaces directly sourcing the lib/* script.
+
stack - Called by stack.sh three times for different phases of its run:
+
+
install - Called after the layer 1 and 2 projects source and their dependencies have been installed.
+
post-config - Called after the layer 1 and 2 services have been configured. All configuration files for enabled services should exist at this point.
+
extra - Called near the end after layer 1 and 2 services have been started. This is the existing hook and has not otherwise changed.
+
+
unstack - Called by unstack.sh before other services are shut down.
+
clean - Called by clean.sh before other services are cleaned, but after unstack.sh has been called.
+
+
+
+
Hypervisor
+
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 requirements
+
configure_nova_hypervisor - make configuration changes, including those to other services
+
start_nova_hypervisor - start any external services
+
stop_nova_hypervisor - stop any external services
+
cleanup_nova_hypervisor - remove transient data and cache
stackrc 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.
+
+
+
+
DATABASE_TYPE
+
Select the database backend to use. The default is mysql,
+ postgresql is also available.
+
+
ENABLED_SERVICES
+
Specify which services to launch. These generally correspond to
+ screen tabs.
+ The default includes: Glance (API and Registry), Keystone, Nova (API,
+ Certificate, Object Store, Compute, Network, Scheduler, VNC proxies,
+ Certificate Authentication), Cinder (Scheduler, API, Volume), Horizon, MySQL, RabbitMQ, Tempest.
+
+ Other services that are not enabled by default can be enabled in
+ localrc. For example, to add Swift:
+
enable_service swift
+ A service can similarly be disabled:
+
disable_service horizon
+
+
Service Repos
+
The Git repositories used to check out the source for each service
+ are controlled by a pair of variables set for each service.
+ *_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.
+
+
+
+
diff --git a/tools/build_docs.sh b/tools/build_docs.sh
index 384b1fabb6..77c2f4e02e 100755
--- a/tools/build_docs.sh
+++ b/tools/build_docs.sh
@@ -2,21 +2,22 @@
# **build_docs.sh** - Build the gh-pages docs for DevStack
#
-# - Install shocco if not found on PATH
+# - Install shocco if not found on PATH and INSTALL_SHOCCO is set
# - Clone MASTER_REPO branch MASTER_BRANCH
-# - Re-creates ``docs`` directory from existing repo + new generated script docs
+# - Re-creates ``docs/html`` directory from existing repo + new generated script docs
# Usage:
-## build_docs.sh [[-b branch] [-p] repo] | .
-## -b branch The DevStack branch to check out (default is master; ignored if
-## repo is not specified)
-## -p Push the resulting docs tree to the source repo; fatal error if
-## repo is not specified
-## repo The DevStack repository to clone (default is DevStack github repo)
+## build_docs.sh [-o ] [-g] [master| []]
+## The DevStack repository to clone (default is DevStack github repo)
## If a repo is not supplied use the current directory
## (assumed to be a DevStack checkout) as the source.
+## The DevStack branch to check out (default is master; ignored if
+## repo is not specified)
## . Use the current repo and branch (do not use with -p to
## prevent stray files in the workspace being added tot he docs)
+## -o Write the static HTML output to
+## (Note that will be deleted and re-created to ensure it is clean)
+## -g Update the old gh-pages repo (set PUSH=1 to actualy push up to RCB)
# Defaults
# --------
@@ -28,6 +29,9 @@ MASTER_BRANCH=${MASTER_BRANCH:-master}
# http://devstack.org is a GitHub gh-pages site in the https://github.com/cloudbuilders/devtack.git repo
GH_PAGES_REPO=git@github.com:cloudbuilders/devstack.git
+DOCS_SOURCE=docs/source
+HTML_BUILD=docs/html
+
# Keep track of the devstack directory
TOP_DIR=$(cd $(dirname "$0")/.. && pwd)
@@ -49,97 +53,110 @@ if ! which shocco; then
git clone -b rst_support https://github.com/dtroyer/shocco shocco
cd shocco
./configure
- make
+ make || exit
cd ..
fi
SHOCCO=$TOP_DIR/shocco/shocco
fi
# Process command-line args
-while getopts b:p c; do
+while getopts go: c; do
case $c in
- b) MASTER_BRANCH=$OPTARG
+ g) GH_UPDATE=1
;;
- p) PUSH_REPO=1
+ o) HTML_BUILD=$OPTARG
;;
esac
done
shift `expr $OPTIND - 1`
-# Sanity check the args
-if [[ "$1" == "." ]]; then
- REPO=""
- if [[ -n $PUSH_REPO ]]; then
- echo "Push not allowed from an active workspace"
- unset PUSH_REPO
- fi
-else
- if [[ -z "$1" ]]; then
+
+if [[ -n "$1" ]]; then
+ master="master"
+ if [[ "${master/#$1}" != "master" ]]; then
+ # Partial match on "master"
REPO=$MASTER_REPO
else
REPO=$1
fi
+ REPO_BRANCH=${2:-$MASTER_BRANCH}
fi
# Check out a specific DevStack branch
if [[ -n $REPO ]]; then
# Make a workspace
- TMP_ROOT=$(mktemp -d devstack-docs-XXXX)
+ TMP_ROOT=$(mktemp -d work-docs-XXXX)
echo "Building docs in $TMP_ROOT"
cd $TMP_ROOT
# Get the master branch
git clone $REPO devstack
cd devstack
- git checkout $MASTER_BRANCH
+ if [[ -n "$REPO_BRANCH" ]]; then
+ git checkout $REPO_BRANCH
+ fi
fi
+# Assumption is we are now in the DevStack workspace to be processed
+
# Processing
# ----------
-# Assumption is we are now in the DevStack repo workspace to be processed
+# Clean up build dir
+rm -rf $HTML_BUILD
+mkdir -p $HTML_BUILD
-# Pull the latest docs branch from devstack.org repo
-if ! [ -d docs ]; then
- git clone -b gh-pages $GH_PAGES_REPO docs
-fi
+# Get fully qualified dirs
+FQ_DOCS_SOURCE=$(cd $DOCS_SOURCE && pwd)
+FQ_HTML_BUILD=$(cd $HTML_BUILD && pwd)
+
+# Get repo static
+cp -pr $FQ_DOCS_SOURCE/* $FQ_HTML_BUILD
# Build list of scripts to process
FILES=""
for f in $(find . -name .git -prune -o \( -type f -name \*.sh -not -path \*shocco/\* -print \)); do
echo $f
FILES+="$f "
- mkdir -p docs/`dirname $f`;
- $SHOCCO $f > docs/$f.html
+ mkdir -p $FQ_HTML_BUILD/`dirname $f`;
+ $SHOCCO $f > $FQ_HTML_BUILD/$f.html
done
-for f in $(find functions lib samples -type f -name \*); do
+for f in $(find functions functions-common lib samples -type f -name \*); do
echo $f
FILES+="$f "
- mkdir -p docs/`dirname $f`;
- $SHOCCO $f > docs/$f.html
+ mkdir -p $FQ_HTML_BUILD/`dirname $f`;
+ $SHOCCO $f > $FQ_HTML_BUILD/$f.html
done
-echo "$FILES" >docs-files
+echo "$FILES" >docs/files
-# Switch to the gh_pages repo
-cd docs
+if [[ -n $GH_UPDATE ]]; then
+ GH_ROOT=$(mktemp -d work-gh-XXXX)
+ cd $GH_ROOT
-# Collect the new generated pages
-find . -name \*.html -print0 | xargs -0 git add
+ # Pull the latest docs branch from devstack.org repo
+ git clone -b gh-pages $GH_PAGES_REPO gh-docs
-# Push our changes back up to the docs branch
-if ! git diff-index HEAD --quiet; then
- git commit -a -m "Update script docs"
- if [[ -n $PUSH ]]; then
- git push
+ # Get the generated files
+ cp -pr $FQ_HTML_BUILD/* gh-docs
+
+ # Collect the new generated pages
+ (cd gh-docs; find . -name \*.html -print0 | xargs -0 git add)
+
+ # Push our changes back up to the docs branch
+ if ! git diff-index HEAD --quiet; then
+ git commit -a -m "Update script docs"
+ if [[ -n $PUSH ]]; then
+ git push
+ fi
fi
fi
# Clean up or report the temp workspace
if [[ -n REPO && -n $PUSH_REPO ]]; then
- rm -rf $TMP_ROOT
+ echo rm -rf $TMP_ROOT
else
if [[ -z "$TMP_ROOT" ]]; then
TMP_ROOT="$(pwd)"
fi
- echo "Built docs in $TMP_ROOT"
+ echo "Built docs in $HTML_BUILD"
fi