Fix broken links and redirects
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
This commit is contained in:
Goutham Pacha Ravi
parent
69c4d81773
commit
78c4ce8ac8
14
README.rst
14
README.rst
@ -48,22 +48,22 @@ after their software has been incorporated into the distro or cloud.
|
||||
vendors. It can be used by vendors in house to compare interoperability
|
||||
data over time.
|
||||
|
||||
* API and UI install docs: http://github.com/openstack/refstack/blob/master/doc/source/refstack.rst
|
||||
* repository: http://git.openstack.org/cgit/openstack/refstack
|
||||
* reviews: https://review.opendev.org/#/q/status:open+project:openstack/refstack
|
||||
* API and UI install docs: https://opendev.org/osf/refstack/src/master/doc/source/refstack.rst
|
||||
* repository: https://opendev.org/osf/refstack
|
||||
* reviews: https://review.opendev.org/#/q/status:open+project:osf/refstack
|
||||
|
||||
* **refstack-client**
|
||||
refstack-client contains the tools you will need to run the
|
||||
Interop Working Group tests.
|
||||
|
||||
* repository: http://git.openstack.org/cgit/openstack/refstack-client
|
||||
* reviews: https://review.opendev.org/#/q/status:open+project:openstack/refstack-client
|
||||
* repository: https://opendev.org/osf/refstack-client
|
||||
* reviews: https://review.opendev.org/#/q/status:open+project:osf/refstack-client
|
||||
|
||||
Get involved!
|
||||
#############
|
||||
|
||||
* Mailing List: openstack-discuss@lists.openstack.org
|
||||
* IRC: #refstack on Freenode
|
||||
* Dev Meetings: Tuesdays @ 19:00 UTC in #openstack-meeting-alt on Freenode
|
||||
* Dev Meetings: Fridays @ 10 AM PST on https://meetpad.opendev.org/Interop-WG-weekly-meeting (Convert to your time zone: https://mytime.io/10am/PST)
|
||||
* Web-site: https://refstack.openstack.org
|
||||
* Wiki: https://wiki.OpenStack.org/wiki/RefStack
|
||||
* Wiki: https://wiki.openstack.org/wiki/RefStack
|
||||
|
||||
@ -56,7 +56,7 @@ or using hash value for your password
|
||||
Clone the repository
|
||||
^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
``git clone http://github.com/openstack/refstack``
|
||||
``git clone https://opendev.org/osf/refstack``
|
||||
|
||||
``cd refstack``
|
||||
|
||||
@ -181,8 +181,8 @@ above. RefStack, by default, points to this endpoint.
|
||||
|
||||
Instructions for setting this up are outside of the scope of this doc,
|
||||
but you can get started at
|
||||
`Openstackid project <https://github.com/openstack-infra/openstackid>`__ .
|
||||
You would then need to modify the ``openstack_openid_endpoint`` field in
|
||||
`Openstackid project <https://opendev.org/osf/openstackid>`__ .
|
||||
You would then need to modify the ``openstack_openid_endpoint`` field in
|
||||
the ``[osid]`` section in refstack.conf to match the local endpoint.
|
||||
|
||||
Database sync
|
||||
|
||||
@ -53,7 +53,7 @@ Sign Key with RefStack Client
|
||||
complete this step.
|
||||
|
||||
Generate a signature for your public key using your private key with
|
||||
`refstack-client <https://github.com/openstack/refstack-client>`__
|
||||
`refstack-client <https://opendev.org/osf/refstack-client>`__
|
||||
|
||||
- ``./refstack-client sign /path-of-sshkey-folder/key-file-name``
|
||||
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
<div class="modal-header">
|
||||
<button type="button" class="close" aria-hidden="true" ng-click="modal.close()">×</button>
|
||||
<h4>Test List ({{modal.testListCount}})</h4>
|
||||
<p>Use this test list with <a title="refstack-client" target="_blank"href="https://github.com/openstack/refstack-client">refstack-client</a>
|
||||
<p>Use this test list with <a title="refstack-client" target="_blank"href="https://opendev.org/osf/refstack-client">refstack-client</a>
|
||||
to run only tests in the {{modal.version}} OpenStack Powered™ guideline from capabilities with the following statuses:
|
||||
</p>
|
||||
<ul class="list-inline">
|
||||
|
||||
@ -4,7 +4,7 @@
|
||||
</div>
|
||||
<div class="pull-left left openstack-intro__content">
|
||||
<h1>OpenStack Interoperability</h1>
|
||||
<p>RefStack is a source of tools for
|
||||
<p>RefStack is a source of tools for
|
||||
<a href="http://www.openstack.org/brand/interop/">OpenStack interoperability</a>
|
||||
testing.</p>
|
||||
</div>
|
||||
|
||||
@ -14,10 +14,10 @@
|
||||
<div ng-if="ctrl.showNewVersionInput" class="row" style="margin-top: 5px;">
|
||||
<div class="col-md-2">
|
||||
<div class="input-group">
|
||||
<input ng-model="ctrl.newProductVersion"
|
||||
<input ng-model="ctrl.newProductVersion"
|
||||
type="text" class="form-control" placeholder="New Version">
|
||||
<span class="input-group-btn">
|
||||
<button
|
||||
<button
|
||||
class="btn btn-default"
|
||||
type="button"
|
||||
ng-click="ctrl.addProductVersion()">
|
||||
|
||||
@ -24,7 +24,7 @@
|
||||
<div class="input-group">
|
||||
<input type="text" class="form-control" ng-model="modal.version.cpid" />
|
||||
<span class="input-group-btn">
|
||||
<button
|
||||
<button
|
||||
class="btn btn-default"
|
||||
type="button"
|
||||
ng-click="modal.saveChanges()">
|
||||
|
||||
@ -1,7 +1,7 @@
|
||||
<div class="modal-header">
|
||||
<h4>Import Public Key</h4>
|
||||
<p>Instructions for adding a public key and signature can be found
|
||||
<a href="https://github.com/openstack/refstack/blob/master/doc/source/uploading_private_results.rst#generate-ssh-keys-locally"
|
||||
<a href="https://opendev.org/osf/refstack/src/branch/master/doc/source/uploading_private_results.rst#user-content-generate-ssh-keys-locally"
|
||||
target="_blank"
|
||||
title="How to generate and upload SSH key and signature with refstack-client">here.
|
||||
</a>
|
||||
|
||||
@ -19,9 +19,9 @@ or addition of flagged tests [3], it is useful for RefStack to provide
|
||||
REST APIs so that users can dynamically retrieve the test lists with the latest
|
||||
updates in the Guideline files as needed.
|
||||
|
||||
[1] https://github.com/openstack/defcore/tree/master/2016.01
|
||||
[2] https://review.opendev.org/#/c/290689/
|
||||
[3] https://review.opendev.org/#/c/215263/
|
||||
[1] https://opendev.org/osf/interop/src/branch/master/2016.01/
|
||||
[2] https://review.opendev.org/290689/
|
||||
[3] https://review.opendev.org/215263/
|
||||
|
||||
Proposed change
|
||||
===============
|
||||
@ -118,7 +118,7 @@ The following REST APIs will be added to RefStack.
|
||||
* JSON schema definition for the response data:
|
||||
|
||||
See DefCore Guideline JSON schema
|
||||
https://github.com/openstack/defcore/tree/master/doc/source/schema
|
||||
https://opendev.org/osf/interop/src/master/doc/source/schema
|
||||
|
||||
|
||||
**List tests**
|
||||
|
||||
@ -123,7 +123,7 @@ The following REST APIs will be added to RefStack.
|
||||
|
||||
**Note:** The values of the "type" filed are a set of pre-defined constants
|
||||
(enum) depicting the type of vendors. The constant definition can be found
|
||||
in https://github.com/openstack/refstack/blob/master/refstack/api/constants.py .
|
||||
in https://opendev.org/osf/refstack/src/master/refstack/api/constants.py .
|
||||
|
||||
**Show vendor details**
|
||||
|
||||
|
||||
@ -308,8 +308,8 @@ References
|
||||
2017-06-28-16.00.log.html
|
||||
[3] http://eavesdrop.openstack.org/meetings/refstack/2017/refstack.
|
||||
2017-07-18-19.00.log.html
|
||||
[4] https://git.openstack.org/cgit/openstack-infra/subunit2sql
|
||||
[4] https://opendev.org/opendev/subunit2sql
|
||||
[5] https://docs.openstack.org/subunit2sql/latest/data_model.html
|
||||
[6] https://review.opendev.org/#/c/265394/
|
||||
[6] https://review.opendev.org/265394/
|
||||
[7] https://docs.openstack.org/oslo.config/latest/configuration/
|
||||
mutable.html
|
||||
|
||||
@ -13,7 +13,7 @@ they should be able to use it with the refstack tester.
|
||||
|
||||
Allowing the user to use a custom tempest config would require changes to the
|
||||
tester cli as well as the web interface. We can safely break the code commits
|
||||
for this into two tasks.
|
||||
for this into two tasks.
|
||||
|
||||
* The CLI would require an extra argument for a path to a config file. As well
|
||||
as some logic that bypassed the internal config generation.
|
||||
@ -60,7 +60,7 @@ N/A
|
||||
|
||||
**Documentation Impact**
|
||||
|
||||
Cli changes should be noted in the --help output as well as written into any documentation for the tester.
|
||||
Cli changes should be noted in the --help output as well as written into any documentation for the tester.
|
||||
|
||||
**References**
|
||||
|
||||
|
||||
@ -5,10 +5,10 @@ Storyboard: https://storyboard.openstack.org/#!/story/109
|
||||
|
||||
Refstack data is used by the DefCore committee to identify capabilities and
|
||||
tests to include in the OpenStack core. To facilitate this process, refstack
|
||||
should produce and present / display this information to the committee
|
||||
should produce and present / display this information to the committee
|
||||
in a meaningful way.
|
||||
|
||||
We anticipate that these reports will also be interesting to the
|
||||
We anticipate that these reports will also be interesting to the
|
||||
broader OpenStack community to select popular capabilities; consequently,
|
||||
the results should not be focused strictly on DefCore as the consumer.
|
||||
|
||||
@ -59,7 +59,7 @@ help the community evaluate interoperability and is less desirable.
|
||||
Data model impact
|
||||
|
||||
Likely none; however, depending on the complexity of the queries,
|
||||
it may be necessary to create intermediate tables to collect the results.
|
||||
it may be necessary to create intermediate tables to collect the results.
|
||||
|
||||
If new models are needed, this spec should be updated with the design.
|
||||
At this time, we assume that the collection does not require an
|
||||
@ -71,7 +71,7 @@ These are read-only reports and should use GETs.
|
||||
|
||||
The URL path should match the other UI paths with then following pattern:
|
||||
|
||||
HTML response: GET /[refstack base]/defcore/[release]
|
||||
HTML response: GET /[refstack base]/defcore/[release]
|
||||
JSON response: GET /[refstack base]/defcore/[release].json
|
||||
|
||||
Security impact
|
||||
|
||||
@ -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.
|
||||
|
||||
|
||||
@ -75,7 +75,7 @@ An example rendering would lock like this:
|
||||
:width: 700px
|
||||
:alt: Comparison Mock Up
|
||||
|
||||
Important Design Note: All tristate graphs must use the same ordered capability/test list
|
||||
Important Design Note: All tristate graphs must use the same ordered capability/test list
|
||||
to ensure that results are easily to compare visually. The purpose of the tristate is
|
||||
to help quickly find outliers not perform detailed comparison. Drill downs will be used
|
||||
to resolve specific differences.
|
||||
@ -100,7 +100,7 @@ There are several other approaches to visualize this information including shade
|
||||
cells and spider charts. This would be acceptable alternatives; however, the tristate
|
||||
chart is compact, very simple to use and highly intuitive for comparing result sets.
|
||||
|
||||
It would be possible to use tristate shapes (circle, open circle, square) to reflect the same
|
||||
It would be possible to use tristate shapes (circle, open circle, square) to reflect the same
|
||||
data on tables.
|
||||
|
||||
Data model impact
|
||||
@ -113,11 +113,11 @@ If new models are needed, this spec should be updated with the design.
|
||||
At this time, we assume that the collection does not require an
|
||||
intermediate model.
|
||||
|
||||
Specification for the method
|
||||
Specification for the method
|
||||
|
||||
These are read-only reports and should use GETs.
|
||||
These are read-only reports and should use GETs.
|
||||
|
||||
The URL path should match the other UI paths with then following pattern:
|
||||
The URL path should match the other UI paths with then following pattern:
|
||||
|
||||
Compare against previous results:
|
||||
HTML response: GET /[refstack base]/compare/[release]/[cloud id]
|
||||
@ -156,7 +156,7 @@ Work Items
|
||||
|
||||
Dependencies
|
||||
|
||||
Sparklines JS libraries: http://omnipotent.net/jquery.sparkline/#s-about
|
||||
Sparklines JS libraries: http://omnipotent.net/jquery.sparkline/#s-about
|
||||
|
||||
Documentation Impact
|
||||
|
||||
@ -164,4 +164,4 @@ Need to document screen and drill down expectation.
|
||||
|
||||
References
|
||||
|
||||
http://wiki.openstack.org/wiki/Governance/DefCoreCommittee
|
||||
http://wiki.openstack.org/wiki/Governance/DefCoreCommittee
|
||||
@ -38,7 +38,7 @@ str:data - a string input containing json as shown in lower example.
|
||||
'duration_seconds': 23445234,
|
||||
'results': [
|
||||
{'name':'fully.qualified.test.path',
|
||||
'uid':'test uuid'}, /* if test has uid. uid has a priority */
|
||||
'uid':'test uuid'}, /* if test has uid. uid has a priority */
|
||||
{'name: 'another.test.path.without.uid'}] /* only passed tests */
|
||||
}
|
||||
|
||||
|
||||
@ -15,12 +15,12 @@ Problem description
|
||||
===================
|
||||
|
||||
Refstack is designed to have minimal user security and configuration overhead;
|
||||
consequently, there are no mechanisms in the short term to ensure that a user's
|
||||
test results are authorized (see note). To create valid results, refstack needs a way to
|
||||
consequently, there are no mechanisms in the short term to ensure that a user's
|
||||
test results are authorized (see note). To create valid results, refstack needs a way to
|
||||
know when multiple runs are against the same targets so that comparisons are valid.
|
||||
|
||||
> Note: In the future, Refstack will include user authentication. At that point
|
||||
it will be possible to associate uploaded data to users and vendors in an
|
||||
it will be possible to associate uploaded data to users and vendors in an
|
||||
authoritative way.
|
||||
|
||||
To solve this problem, refstack needs a unique handle for each cloud tested
|
||||
|
||||
@ -66,10 +66,10 @@ The v1 api must be modified to validate test results. The modification
|
||||
will result in an addition to behavior on the API with no changes
|
||||
to the user-facing endpoint.
|
||||
|
||||
**description:** Receive tempest test result from a remote test runner.
|
||||
**description:** Receive tempest test result from a remote test runner.
|
||||
This function expects json formated pass results.
|
||||
Update to the api described at:
|
||||
https://github.com/stackforge/refstack/blob/master/specs/approved/api-v1.md
|
||||
https://opendev.org/osf/refstack/src/branch/master/specs/prior/implemented/api-v1.md
|
||||
|
||||
**url:** post /v1/results
|
||||
|
||||
|
||||
@ -494,5 +494,4 @@ Documentation Impact
|
||||
|
||||
References
|
||||
==========
|
||||
[1] https://github.com/openstack/refstack/blob/master/specs/pike/approved
|
||||
/upload-subunit-tests.rst
|
||||
[1] https://opendev.org/osf/refstack/src/branch/master/specs/pike/approved/upload-subunit-tests.rst
|
||||
|
||||
@ -113,7 +113,7 @@ Each API method which is either added or changed should have the following
|
||||
think about when defining their policy.
|
||||
|
||||
Example JSON schema definitions can be found in the Nova tree
|
||||
http://git.openstack.org/cgit/openstack/nova/tree/nova/api/openstack/compute/schemas/v3
|
||||
https://opendev.org/openstack/nova/src/branch/master/nova/api/openstack/compute/schemas/
|
||||
|
||||
Note that the schema should be defined as restrictively as
|
||||
possible. Parameters which are required should be marked as such and
|
||||
|
||||
@ -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
|
||||
these for your local install can be found at
|
||||
https://opendev.org/osf/refstack/src/master/doc/source/refstack.rst#optional-configure-foundation-organization-and-group
|
||||
|
||||
This script updates RefStack tests as verified given a specific
|
||||
spreadsheet. The columns in this spreadsheet are, in this order:
|
||||
|
||||
|
||||
* Company Name
|
||||
|
||||
* Product Name
|
||||
@ -42,7 +43,7 @@ spreadsheet. The columns in this spreadsheet are, in this order:
|
||||
* License Date
|
||||
|
||||
* Update Product (yes/no)
|
||||
|
||||
|
||||
* Contacts
|
||||
|
||||
* Notes
|
||||
|
||||
2
tox.ini
2
tox.ini
@ -6,7 +6,7 @@ skipsdist = True
|
||||
[testenv]
|
||||
basepython = python3
|
||||
usedevelop = True
|
||||
install_command = pip install -c{env:UPPER_CONSTRAINTS_FILE:https://git.openstack.org/cgit/openstack/requirements/plain/upper-constraints.txt} -U {opts} {packages}
|
||||
install_command = pip install -c{env:UPPER_CONSTRAINTS_FILE:https://opendev.org/openstack/requirements/raw/branch/master/upper-constraints.txt} -U {opts} {packages}
|
||||
setenv = VIRTUAL_ENV={envdir}
|
||||
LANG=en_US.UTF-8
|
||||
LANGUAGE=en_US:en
|
||||
|
||||
Loading…
Reference in New Issue
Block a user