openinfra/refstack
Code Issues Proposed changes

Updates to gearman spec based on raymonds notes

Browse Source 
Change-Id: Ibd6aa216a759d8146fa240e79622827ed46a2369
This commit is contained in:
david 2014-04-03 07:50:01 -07:00
parent c77a201c99
commit d5802ff6fc
1 changed files with 33 additions and 15 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

48
specs/proposed/refstack-org-gearman-tester.rst
View File

@ -8,9 +8,9 @@ Set up gearman worker/client for triggering official test runs from refstack.org
* build gearman client / job monitor
* stand alone worker script that does not need refstack installed.
* stand alone worker script that does not require that refstack is installed.
* api methods
* Test status reporting API call
* package installer for test runner with dependency and version coverage.
@ -18,7 +18,7 @@ Set up gearman worker/client for triggering official test runs from refstack.org
Problem description
===================
In an effort to make this hostable long term scalable we need a way to manage a queue of tests that run on a distributed infrastructure. For that I like gearman.
In an effort to make this hostable long term and scalable, we need a way to manage a queue of tests that run on a distributed infrastructure. For that I like gearman.
This covers the Public cloud vendor official testing use case.
@ -30,12 +30,28 @@ This covers the Public cloud vendor official testing use case.
Proposed change
===============
Generalized gearman flow.
(#) execute_test.py is already installed on gearman worker node.
(#) The run_gearman method in tempest_tester.py will use gearman client to send over a payload.
(#) The payload will have the necessary information to construct the arguments to execute_test.py
(#) Gearman worker receives the payload.
(#) Validates the payload Sets up local virtual env and installs the correct version of tempest within it.
(#) The worker then kicks off execute_test with -callback ``refstack server`` ``test_id`` --conf_json ``from payload`` --tempest_home ``tempest install dir``
(#) With the current execute_test.py code, it will interact with the refstack server to get more information about the cloud being tested to construct the tempest.config, and get the testcases to be run (optional), then execute the tempest test from the tempest_home. At the end, it will automatically send back the results to Refstack server.
Note: with this design, gearman worker will have network access to the Refstack server and will need access to the cloud being tested.
This spec covers the following deliverables;
* gearman client side code. (https://review.openstack.org/#/c/84270/)
* gearman worker code (wip)
* api method for reporting failure
* installer with dependency coverage for the worker
* gearman worker code (wip)
* Parts of this are already stubbed out in the code. specifically the "run_gearman" method.
* Test status reporting API call
* This feature will overlap with the following blue print: https://blueprints.launchpad.net/refstack/+spec/update-test-status
* Installer with dependency coverage for the worker to improve speed of deployment of new workers.
* In this instance tempest would be installed in a virtual env before every test. So that the exact version of tempest that is needed for this specific test is installed in a way that is easy to clean up afterwards for the next test that will run on that worker node.
Alternatives
------------
@ -50,25 +66,27 @@ This uses the current models without any changes.
REST API impact
---------------
* new method.. report_failure
* this method will accept failure report form running remote tests
**update-test-status**
This is a basic method for remote testers to report status to the gui/api
* Method type: POST
* if result is accepted responds with 202
* Expected error http response code(s)
* 400 bad request.. payload was missing?
* 400 bad request.. parameter was missing?
* 405 not authorized, this method should only allow failure reports from known gearman hosts
* 405 not authorized, this method should only allow failure reports from known testing hosts
* URL: /response/failure
* URL: /update-test-status/
* Parameters
* payload - the payload object that was passed into the worker to begin with
* on docker tests I think we should still post back from data if we can..
* test_id - the test id
Security impact
@ -94,7 +112,7 @@ Security impact
Notifications impact
--------------------
The gearman client should be able to feed back its status updates to the webui through the 'TestStatus' model.
The gearman client should be able to feed back its status updates to the 'TestStatus' model through the update-test-status method.
Other end user impact
---------------------