Extreme Testing SIG
Status: Proposed (Proposal: http://lists.openstack.org/pipermail/openstack-sigs/....) will fill in as we send out proposal for the first time
Description: Extreme Testing started as a development proposal which can bee seen at: http://specs.openstack.org/openstack/openstack-user-stories/user-stories/proposed/openstack_extreme_testing.html. At it's simplest and in it's initiial push this proposed SIG will create a framework for reliability testing of openstack instances and components focusing on ???
Much of the early scoping and consideration of scope and project impact considerations can bee seen in Extreme Testing-Vision+Arch. In a larger sense this SIG would focus on creating a community who would share in the building and running and reporting back to the core project teams of bugs realted to the Reliability of OpenStack.
Potential Goals
- Provide the forum in which interested Operators, Performance and Reliability Engineers and Developers can collaborate on ways of verifying openstack reliability.
- Sharing in the specification and development of the methods/scripts for both driving workloads and creating outages for which the cloud and it's workload should persist
- Sharing in the job of running and reporting some subset of the functionality as part of the regular upstream QA process
- Others: TBD!
Audience
- Operators of clouds and cloud based applications needing to prove out and address reliability
- Developers of QA/Tools (especially those interested in performance and reliability
SIG Leads
Community Infrastructure
- Wiki: Eris - Extreme Testing Framework for OpenStack
- Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs; [ExtremeTesting] for the tag
- IRC: #openstack-qa
- Meetings: Weekly: Agenda / details to be linked on wiki page
Alternative/Related efforts/Other notes
- This SIG will and it's output appear to be similar to a QA project. it's possible to just let it be so but then would seem to miss out on the promise of SIGs to bring in more collaborators from many directions.
- The initial scope is concentrting on Ansible driving functionality so seems to have some overlap to: https://wiki.openstack.org/wiki/Ansible_SIG
- Many have and want to use the project Rally for this general use case: https://wiki.openstack.org/wiki/Rally. It is a valid alternative to not start on a new method for Reliability and instead work to alter Ralyl to meet the needs, but it is debatable.