17
Essential DevStack Swapnil Kulkarni April 13, 2015

Essential DevStack

Embed Size (px)

Citation preview

Essential DevStack

Swapnil KulkarniApril 13, 2015

-1. Prelimnery

1. Python

2. Git

3. Linux Basic

4. Basic understanding of virtualization & cloud computing concepts

Agenda

1. Introduction to Devstack

2. DevStack to your project specific needs

3. Unit Testing your code

4. Using Tempest effectively for each project

5. Gerrit Workflow

6. 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)

Steps

1. 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.conf

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

historical localrc file

stackrc

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.

openrc

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.

exerciserc

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

eucarc

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.

1.3 DevStack Tools

tools/info.sh

Report on the devstack configuration

tools/build_docs.sh

Build the gh-pages docs for DevStack

tools/create_userrc.sh

Pre-create rc files and credentials for the default users.

tools/fixup_stuff.sh

All distro and package specific hacks go in here

tools/install_prereqs.sh

Install system package prerequisites

tools/install_pip.sh

Update pip and friends to a known common version

tools/upload_image.sh

Retrieve and upload an image into Glance

samples/local.sh

user-configurable tasks to run automatically at the successful conclusion of stack.sh

1.4 DevStack Scripts

stack.sh

Sets up OpenStack development environment utilizing the configuration parameters and supporting scripts

unstack.sh

Stops 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.sh

this runs a series of unit tests for devstack to ensure it's functioning

rejoin_stack.sh

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

1.5 Component Plugins

Hypervisor Plugins

VIRT_DRIVER=VIRT_DRIVER_NAME

Block Storage Plugins

CINDER_DRIVER=BLOCK_STORAGE_DRIVER_NAME

Block Storage Backend Plugins

CINDER_ENABLED_BACKENDS=DRIVER:VOLUME_TYPE_NAME

Network Plugins

Network Backend Plugins

Enabled as service. Specific parameters from vendors are required

Database Plugin

enable_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.sh

The default users are: admin and demo

The password: xxxxxxx

This 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 project

2. Don’t forget to enable tempest

3. Verify if you have all the plugins related to projects in devstack/lib and devstack/extras.d

4. 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 tempest

Tempest - 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 automatically

2. For manual configuration,

2.1 The sample configuration is located at ~/tempest/etc/tempest.conf.sample

2.2 The devstack generated configuration is located at ~/tempest/etc/tempest.conf

2.3 Edit the configuration for service you want to validate with tempest

4.4 Using tempest

1. Use in virtual or normal mode

2. Use run_tempest.sh

3. 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 Workflow

5. Gerrit Workflow

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

5.2 Create required IDs

1. GitHub - https://github.com/

2. LaunchPad - https://login.launchpad.net

3. 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_Lists

ohttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack - General Mailing List

ohttp://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 OS

Ubuntu: current LTS release plus current development release

Fedora: current release plus previous release

RHEL: current major release

Databases

MySQL

PostgreSQL

Queues

RabbitMQ

Qpid

Web Server

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), 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 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 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.

##Neutron

enable_service neutron

disable_service n-net

enable_service q-svc

enable_service q-agt

enable_service q-dhcp

enable_service q-l3

enable_service q-meta

enable_service q-lbaas

#Swift Requirements

enable_service s-proxy s-object s-container s-account

SWIFT_REPLICAS=1

SWIFT_HASH=66a3d6b56c1f479c8b4e70ab5c2000f5

##Enable Tempest

enable_service tempest

##Enable Cinder-Backup

enable_service c-bak

###Ironic

enable_service ir-api

enable_service ir-cond

###Trove

enable_service trove,tr-api,tr-tmgr,tr-cond

#Log Output

LOGFILE=/opt/stack/logs/stack.sh.log

VERBOSE=True

LOG_COLOR=False

SCREEN_LOGDIR=/opt/stack/logs

Appendix B: DevStack Customizations