Date post: | 04-Dec-2014 |
Category: |
Technology |
Upload: | masayuki-igawa |
View: | 736 times |
Download: | 0 times |
Page 1
Ensuring OpenStackVersion up Compatibility
CloudOpen Japan 2013-05-31
Masayuki Igawa : [email protected]
Agenda
1. Overview of the OpenStack2. Overview of Compatibility Issues3. Overview of the OpenStack Tests
1. Unit Test2. Integration Test
4. Overview of Scenario Tests5. Proposal for the Implementation at Havana Summit6. Current Implementation of Scenario Tests 7. Current Status
1. Tempest2. My proposal
8. Wrap-up 9. Appendix
Page 2
Overview of the OpenStack
▌One of the most popular OSS IaaS infrastructure Software▌Consists of several loosely-coupled components▌Many features are being evolved with six month release cycle
Page 3
Version up compatibility is one of the greatest concerns for user’s viewpoint!
Release Cycle - Overview of the OpenStack
▌Many Features are being developed with 6 months release cycle.
Page 4
Now
Now
6months
6months
6months
6months
2013.2
6months
Overview of Compatibility issues
▌Databases There are many changes between Every Release Cycle
• ex) 35 DB schemas were changed, and 33 new DB Tables were added(*)
OpenStack components have database migration mechanisms. Nova, Glance and Cinder have a test framework for this issue.
• In Nova, this framework discovered a data loosing bug.
• Other components need volunteers.
Page 5
* between Essex and Folsom
Overview of Compatibility issues
▌Configurations OpenStack components have many configuration setting parameters. In the public document, the number is about over 600! in Nova only.
• However, I think there are many undocumented configuration parameters.
The number of Configuration changes is over 130!(*)
Page 6
* between Essex and Folsom
http://docs.openstack.org/trunk/openstack-compute/admin/content/list-of-compute-config-options.html
Overview of Compatibility issues
▌APIs APIs are versioning in the OpenStack. Same version APIs should have backward compatibility. However, most of APIs parameters are not validated.
• This can caused compatibility issues by the fluctuation of input values. The comprehensive and more strict input validation can avoid this
issue. There are some works in this area.
These works are very nice! And we need to test for ensuring the compatibility.
Page 7
for Nova
for Cinder
Overview of Compatibility issues
▌How can we ensure compatibility? - Source Code Review?
Yes! We are already doing on https://review.openstack.org. All commits are reviewed by core reviewers
Page 8
Overview of Compatibility issues
▌How can we ensure compatibility? – Testing? Yes! We are already doing it. Manually? No! Manual testing is painful!
• Jenkins does it: https://jenkins.openstack.org• All commits are tested with Jenkins CI.
Page 9
Overview of Compatibility issues (Development work flow)
▌Gerrit Workflow Quick Reference
Page 10
https://wiki.openstack.org/wiki/File:Contribution_path.png
OpenStack Community Environment
approve
merge
By Sdague
Page 11
Tests are very important!
http://www.flickr.com/photos/sidelong/246816211/By David Bleasdale:
Overview of the OpenStack Tests
▌Basically, test cases are always tested automatically by the community.
-> Developers need to write the test code for their feature implementation.
We have two types of the tests.
Page 12
Integration TestingUnit Testing
By David Goehring : http://www.flickr.com/photos/carbonnyc/6415460111/ By INTVGene :http://www.flickr.com/photos/intvgene/370973576/
Unit Test
▌All Developers must write Unit Test codes. The test code makes the implemented code behavior clear. And, ensures the feature code quality.
▌Tools testr/nose nose
• is nicer testing for Python• extends unittest to make testing easier.
testr• will run tests in parallel(so they go faster)• it keeps robust logs of the results.
Jenkins• Continuous Integration environment.• Jenkins runs unit tests every ‘git review’ing.
Page 13
Integration Test
▌Tempest Tempest is the OpenStack Integration Test Suite Runs and validates on the every ‘git review’(*) automatically
Page 14
(*) OpenStack Community uses the gerrit system.
Integration Test - Tempest
▌When the test is failed, you get ’-1’ from Jenkins.
▌Then, you need to fix your code, and do ‘git review’ again
Page 15
0
50
100
150
200
250
Hard to impl, 9.6%
Unnecessary, 25.4%
Implemented, 36.3%
We've implemented, 8.3%
Suspended, 7.1%
Ongoing, 13.3%
Test coverage of Nova APIs with Tempest
# o
f A
PIs
Status of Integration Testing
▌Test coverage of APIs(Nova)
Page 16
A little more! About 20% APIs are remained
Still not Tested
(Our research at 2013-05-24)
Overview of Scenario Tests
▌What are Scenario Tests? Testing across the components such as Nova, Keystone, Glance and
so on. Top-down testing from the user’s perspective.
Page 17
Overview of Scenario Tests(continued)
▌Tempest tests until Grizzly
Page 18
Network tests• create keypairs• create security
groups• create networks
:
Block Storage tests
• create a volume
• get the volume• delete the
volume:
Compute tests• create a
keypair• create a
security group• boot a instance
:
Identity tests:
Image tests:
Individual component based testing
Object Storage tests
:
Overview of Scenario Tests(continued)
▌What are Scenario Tests?
Page 19
Scenario 11. create a flavor2. create a image3. create a
network4. create &
configure a project, a quota, a role, a user
5. create a keypair
6. boot a instance
7. list & show the instance
8. create a volume
9. list & show the volume
10. attach the volume
:
Across the multiple components & sequential testing
Overview of Scenario Tests(continued)
▌Effects of Scenario Tests For developers: We’ll be able to check whether new code (bug-fixes
or features) will cause side effects on the other components with the top-down method.
For users: We’ll be able to increase the use case coverage which is important from the user’s perspective.
We’ll be able to cover the user’s use case by adding various scenarios according to the usage scene.
▌Points to Consider for the Scenario Category of the scenario: Private cloud, Public cloud, VPC and so on Scale: # of tenants, users, networks and so on Validation method : REST API, ping, ssh and so on
Page 20
Proposal for the Implementation at Havana Summit
▌The Test Scenario of the First Implementation Basic Minimum Across the multiple components
▌Access Client and Directory Options
Page 21
No Access Client Directory
1 CLI (cli.ClientTestBase) tempest/scenario
2 Client Library tempest/tempest/tests/scenario
3 RestClient tempest/tempest/tests/scenario
Current Implementation of Scenario Tests
▌The Test Scenario of the First Implementation Basic Minimum Across the multiple components
▌Access Client and Directory Options
Page 22
No Access Client Directory
1 CLI (cli.ClientTestBase) tempest/scenario
2 Client Library tempest/tempest/scenario
3 RestClient tempest/tempest/tests/scenario
<- The concepts are not changed.
Current Implementation of Scenario Tests - Detail
▌Basic – All OpenStack Administrators can understand▌Small – Main code is only 208 lines▌Besides, testing across the multiple components
Page 23
https://review.openstack.org/#/c/26403/
Current status of Tempest
▌Restructuring directory tree and well documented
Page 24
./ +-- bin/ +-- cli/ | +-- simple_read_only/ +-- etc/ +-- include/ +-- stress/ | +-- tests/ | +-- tools/ +-- tempest/ | +-- common/ | +-- openstack/ | +-- services/ | +-- tests/ +-- tools/
./ +-- bin/ +-- doc/ | +-- source/ +-- etc/ +-- include/ +-- tempest/ | +-- api/ | +-- cli/ | +-- common/ | +-- hacking/ | +-- openstack/ | +-- scenario/ | +-- services/ | +-- stress/ | +-- thirdparty/ | +-- whitebox/ +-- tools/
TrunkGrizzly
Restructuring and well
documented
Current status of my proposal
▌Blueprint Not approved yet..
▌Code Core reviewer reviewed and +1ed. Almost merged!
Page 25
Wrap up
▌The tests are very important for ensuring compatibility Especially, scenario tests are very important for user’s perspective.
▌The scenario test directory is ready now
▌Please share your scenario tests. -> That makes all of us happy.
Page 26
APPENDIX
Page 27
proposal for tempest directory restructure
Page 28
https://review.openstack.org/#/c/28453/
Appendix
▌Related Blueprints/Havana Summit Sessions/code Add Scenario Tests to Tempest (by me): https://blueprints.launchpad.net/tempest/+spec/add-scenario-tests https://review.openstack.org/#/c/26403/ Nova VM Lifecycle Test (by Nithya Ganesan): https://blueprints.launchpad.net/tempest/+spec/nova-vmlifecycle-test Strategies for Gating in a Growing Project(by David Kranz): http://summit.openstack.org/cfp/details/23 Tempest Scope (by Sean Dague): http://summit.openstack.org/cfp/details/165 Tempest - Gap Analysis - Identify new testsdevelop (by Ravikumar
Venkatesan): http://summit.openstack.org/cfp/details/32
Page 29