DevelopmentStackOpen

Swapnil Kulkarni

-1. Prelimnery

1. Python2. Git3. Linux Basic4. Basic understanding of virtualization & cloud computing concepts

Agenda

1. Introduction to Devstack2. DevStack to your project specific needs3. Unit Testing your code4. Using Tempest effectively for each project5. Gerrit Workflow6. Make your contribution more effective

1. Introduction to Devstack

What is DevStack?A documented shell script to build complete OpenStack development environments.The development environment can be one of the following- Default/master- Stable branch (Icehouse, Havana,...etc)- Custom

1.1 Setting up devstack

Prerequisites:- DevStack setup requires to have 1 VM/ BM machine with internet connectivity.- Setup a fresh supported Linux installation. (Ubuntu/Fedora/CentOs)

Steps1. Clone devstack from devstack.

2. Deploy your OpenStack Cloud

$git clone https://github.com/openstack-dev/devstack.git

$cd devstack && ./stack.sh

1.2 DevStack Configuration Helpers

local.conflocal.conf is a user-maintained setings file that is sourced in stackrc. It contains a section that replaces the

historical localrc file

stackrcstackrc 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.

openrcopenrc 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.

exercisercexerciserc is used to configure settings for the exercise scripts. The values shown below are the default

values. These can all be overridden by setting them in the localrc section.

eucarceucarc 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.

1.3 DevStack Tools

tools/info.shReport on the devstack configuration

tools/build_docs.shBuild the gh-pages docs for DevStack

tools/create_userrc.shPre-create rc files and credentials for the default users.

tools/fixup_stuff.shAll distro and package specific hacks go in here

tools/install_prereqs.shInstall system package prerequisites

tools/install_pip.shUpdate pip and friends to a known common version

tools/upload_image.shRetrieve and upload an image into Glance

samples/local.shuser-configurable tasks to run automatically at the successful conclusion of stack.sh

1.4 DevStack Scripts

stack.shSets up OpenStack development environment utilizing the configuration parameters and supporting scripts

unstack.shStops that which is started by stack.sh (mostly) mysql and rabbit are left running as OpenStack code refreshes do not require them to be restarted.

run_tests.shthis runs a series of unit tests for devstack to ensure it's functioning

rejoin_stack.shrestart the devstack environment and attach to screen for logging. Please ensure you have done necessary changes for your storage backends.

functions and commont-functions

lib/*Functions to control configuration and operation of different components

Extras.d HooksThese 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.

1.5 Component Plugins

Hypervisor PluginsVIRT_DRIVER=VIRT_DRIVER_NAME

Block Storage PluginsCINDER_DRIVER=BLOCK_STORAGE_DRIVER_NAME

Block Storage Backend PluginsCINDER_ENABLED_BACKENDS=DRIVER:VOLUME_TYPE_NAME

Network Plugins

Network Backend PluginsEnabled as service. Specific parameters from vendors are required

Database Pluginenable_service mysql/postgresql

1.6 Using DevStack

Source credentials required for executing commands

Use Devstak :)

Horizon is now available at http://X.X.X.X/Keystone is serving at http://X.X.X.X:5000/v2.0/Examples on using novaclient command line is in exercise.shThe default users are: admin and demoThe password: xxxxxxxThis is your host ip: X.X.X.X

$source accr/admin/admin$source accr/demo/demo

2. DevStack to your project specific needs

1. Update localrc to suit specific project2. Don’t forget to enable tempest3. Verify if you have all the plugins related to projects in devstack/lib and devstack/extras.d4. Unstack your devstack environment and Run stack.sh again

3.2 Using tox

1. Install tox with pip install tox or easy_install tox

Run tox

# content of: tox.ini , put in same dir as setup.py[tox]envlist = py26,py27[testenv]deps=pytest # install pytest in the venvscommands=py.test # or 'nosetests' or ...

Tox as is a generic virtualenv management and test command line tool you can use for● checking your package installs correctly with different Python versions and interpreters● running your tests in each of the environments, configuring your test tool of choice● acting as a frontend to Continuous Integration servers, greatly reducing boilerplate and merging CI

and shell-based testing.

3.1 Understanding tox

3. Unit Testing your code

4. Using Tempest effectively for each project

4.1 What is tempestTempest - The OpenStack Integration Test Suite

This is a set of integration tests to be run against a live OpenStack cluster. Tempest has batteries of tests for OpenStack API validation, Scenarios, and other specific tests useful in validating an OpenStack deployment.

- API Tests- Scenario Tests- Negative Tests- Parallel Test Execution

4.3 Tempest Auto and Manual Configuration

1. Devstack configures tempest automatically2. For manual configuration,2.1 The sample configuration is located at ~/tempest/etc/tempest.conf.sample2.2 The devstack generated configuration is located at ~/tempest/etc/tempest.conf2.3 Edit the configuration for service you want to validate with tempest

4.4 Using tempest1. Use in virtual or normal mode2. Use run_tempest.sh3. Use nosetests for specific tests in virtual mode

E.g. Validating Cinder API(Volume) using tempest,

$./run_tempest.sh --V -- tempest.api.volume

5.1 Understanding Gerrit Workflow5. Gerrit Workflow

https://wiki.openstack.org/wiki/Gerrit_Workflow

5.2 Create required IDs

1. GitHub - https://github.com/2. LaunchPad - https://login.launchpad.net3. OpenStack Gerrit Review System - https://review.openstack.org

6. Make your contribution more effective

Follow https://wiki.openstack.org/wiki/How_To_Contribute

Some of the highlights to get started are

● Subscribe to our mailing lists - https://wiki.openstack.org/wiki/Mailing_Listso http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack - General Mailing Listo http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev - Development Mailing List

● Join us on IRC: You can talk to us directly in one of the #openstack channels● Answer and ask questions on https://ask.openstack.org

Share :)

Appendix A: Supported Components

Base OSUbuntu: current LTS release plus current development releaseFedora: current release plus previous releaseRHEL: current major release

DatabasesMySQLPostgreSQL

QueuesRabbitMQQpid

Web ServerApache

OpenStack NetworkDefault to Nova Network, optionally use NeutronNova Network: FlatDHCPNeutron: A basic configuration approximating the original FlatDHCP mode using linuxbridge or OpenVSwitch.

ServicesThe 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.

Node ConfigurationsSingle nodeMulti-node is not tested regularly by the core team, and even then only minimal configurations are reviewed

ExercisesThe 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.

##Neutronenable_service neutrondisable_service n-netenable_service q-svcenable_service q-agtenable_service q-dhcpenable_service q-l3enable_service q-metaenable_service q-lbaas #Swift Requirementsenable_service s-proxy s-object s-container s-accountSWIFT_REPLICAS=1SWIFT_HASH=66a3d6b56c1f479c8b4e70ab5c2000f5 ##Enable Tempestenable_service tempest ##Enable Cinder-Backupenable_service c-bak ###Ironicenable_service ir-apienable_service ir-cond ###Troveenable_service trove,tr-api,tr-tmgr,tr-cond #Log OutputLOGFILE=/opt/stack/logs/stack.sh.logVERBOSE=TrueLOG_COLOR=FalseSCREEN_LOGDIR=/opt/stack/logs

Appendix B: DevStack Customizations