Upload
swapnil-kulkarni
View
146
Download
2
Embed Size (px)
Citation preview
-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