This repository is hosted on opendev.org's
gitea server, and doesn't get mirrored to
github currently (we may add mirroring in
the future). We can swap a bunch of URLs
that assume the content is on github and
older infra cgit servers with correct URLs.
Meetings have moved from IRC to MeetPad,
fix the corresponding details in the README.
Also use this commit to strip trailing
whitespaces across the repository.
Change-Id: Ica0a7ba08d9c437f94fbc9ab282bd929f01df8ff
@ -10,7 +10,7 @@ Set up gearman worker/client for triggering official test runs from refstack.org
* stand alone worker script that does not require that refstack is installed.
* Test status reporting API call
* Test status reporting API call
* package installer for test runner with dependency and version coverage.
@ -30,13 +30,13 @@ This covers the Public cloud vendor official testing use case.
Proposed change
===============
Generalized gearman flow.
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
(#) 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.
(#) 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.
@ -44,13 +44,13 @@ Note: with this design, gearman worker will have network access to the Refstack
This spec covers the following deliverables;
* gearman client side code. (https://review.opendev.org/#/c/84270/)
* gearman worker code (wip)
* Parts of this are already stubbed out in the code. specifically the "run_gearman" method.
* gearman client side code. (https://review.opendev.org/84270/)
* 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.
* 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
@ -68,11 +68,11 @@ REST API impact
**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.. parameter was missing?
@ -85,7 +85,7 @@ REST API impact
* 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..
* on docker tests I think we should still post back from data if we can..
* test_id - the test id
@ -117,9 +117,9 @@ The gearman client should be able to feed back its status updates to the 'TestSt
Other end user impact
---------------------
Aside from the API, are there other ways a user will interact with this feature?
Aside from the API, are there other ways a user will interact with this feature?
Users will be able to trigger, cancel, and, receive status updates.
Users will be able to trigger, cancel, and, receive status updates.
Performance Impact
------------------
@ -131,7 +131,7 @@ depending on demand. So there is no real need to worry about performance impacts
Other deployer impact
---------------------
* using the gearman testing option will require two settings in `refstack.cfg` GEARMAN_SERVER and GEARMAN_PORT will need to be set with the location and port of the gearmand server.
* using the gearman testing option will require two settings in `refstack.cfg` GEARMAN_SERVER and GEARMAN_PORT will need to be set with the location and port of the gearmand server.
* This change will require being enabled in the same file with the TEST_METHOD value set to "gearman".
@ -155,7 +155,7 @@ Other contributors:
Work Items
----------
* gearman client side code. (https://review.opendev.org/#/c/84270/)
* gearman client side code. (https://review.opendev.org/84270/)
* starts/stops/handle the gearman job queue
* gearman worker code (wip)
* report failure api call
@ -165,7 +165,7 @@ Dependencies
============
extends openstack-infra/gear
https://github.com/openstack-infra/gear
https://opendev.org/opendev/gear
will also require a running gearmand service someplace accessible to both worker and client.
@ -10,11 +10,12 @@ The script can be run using the following formatting:
http://example.com:8000/v1 --tokenfile <token file path>". In order to
successfully update and verify results, you will need admin rights
for the refstack server in question. Instructions on how to get
these for your local install can be found at https://github.com/openstack/refstack/blob/master/doc/source/refstack.rst#optional-configure-foundation-organization-and-group
Goutham Pacha Ravi
6 months ago