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 2020-12-17 22:26:46 -08:00
parent 69c4d81773
commit 78c4ce8ac8
22 changed files with 67 additions and 67 deletions

View File

@ -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 vendors. It can be used by vendors in house to compare interoperability
data over time. data over time.
* API and UI install docs: http://github.com/openstack/refstack/blob/master/doc/source/refstack.rst * API and UI install docs: https://opendev.org/osf/refstack/src/master/doc/source/refstack.rst
* repository: http://git.openstack.org/cgit/openstack/refstack * repository: https://opendev.org/osf/refstack
* reviews: https://review.opendev.org/#/q/status:open+project:openstack/refstack * reviews: https://review.opendev.org/#/q/status:open+project:osf/refstack
* **refstack-client** * **refstack-client**
refstack-client contains the tools you will need to run the refstack-client contains the tools you will need to run the
Interop Working Group tests. Interop Working Group tests.
* repository: http://git.openstack.org/cgit/openstack/refstack-client * repository: https://opendev.org/osf/refstack-client
* reviews: https://review.opendev.org/#/q/status:open+project:openstack/refstack-client * reviews: https://review.opendev.org/#/q/status:open+project:osf/refstack-client
Get involved! Get involved!
############# #############
* Mailing List: openstack-discuss@lists.openstack.org * Mailing List: openstack-discuss@lists.openstack.org
* IRC: #refstack on Freenode * 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 * Web-site: https://refstack.openstack.org
* Wiki: https://wiki.OpenStack.org/wiki/RefStack * Wiki: https://wiki.openstack.org/wiki/RefStack

View File

@ -56,7 +56,7 @@ or using hash value for your password
Clone the repository Clone the repository
^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^
``git clone http://github.com/openstack/refstack`` ``git clone https://opendev.org/osf/refstack``
``cd 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, Instructions for setting this up are outside of the scope of this doc,
but you can get started at but you can get started at
`Openstackid project <https://github.com/openstack-infra/openstackid>`__ . `Openstackid project <https://opendev.org/osf/openstackid>`__ .
You would then need to modify the ``openstack_openid_endpoint`` field in You would then need to modify the ``openstack_openid_endpoint`` field in
the ``[osid]`` section in refstack.conf to match the local endpoint. the ``[osid]`` section in refstack.conf to match the local endpoint.
Database sync Database sync

View File

@ -53,7 +53,7 @@ Sign Key with RefStack Client
complete this step. complete this step.
Generate a signature for your public key using your private key with 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`` - ``./refstack-client sign /path-of-sshkey-folder/key-file-name``

View File

@ -2,7 +2,7 @@
<div class="modal-header"> <div class="modal-header">
<button type="button" class="close" aria-hidden="true" ng-click="modal.close()">&times;</button> <button type="button" class="close" aria-hidden="true" ng-click="modal.close()">&times;</button>
<h4>Test List ({{modal.testListCount}})</h4> <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&#8482; guideline from capabilities with the following statuses: to run only tests in the {{modal.version}} OpenStack Powered&#8482; guideline from capabilities with the following statuses:
</p> </p>
<ul class="list-inline"> <ul class="list-inline">

View File

@ -4,7 +4,7 @@
</div> </div>
<div class="pull-left left openstack-intro__content"> <div class="pull-left left openstack-intro__content">
<h1>OpenStack Interoperability</h1> <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> <a href="http://www.openstack.org/brand/interop/">OpenStack interoperability</a>
testing.</p> testing.</p>
</div> </div>

View File

@ -14,10 +14,10 @@
<div ng-if="ctrl.showNewVersionInput" class="row" style="margin-top: 5px;"> <div ng-if="ctrl.showNewVersionInput" class="row" style="margin-top: 5px;">
<div class="col-md-2"> <div class="col-md-2">
<div class="input-group"> <div class="input-group">
<input ng-model="ctrl.newProductVersion" <input ng-model="ctrl.newProductVersion"
type="text" class="form-control" placeholder="New Version"> type="text" class="form-control" placeholder="New Version">
<span class="input-group-btn"> <span class="input-group-btn">
<button <button
class="btn btn-default" class="btn btn-default"
type="button" type="button"
ng-click="ctrl.addProductVersion()"> ng-click="ctrl.addProductVersion()">

View File

@ -24,7 +24,7 @@
<div class="input-group"> <div class="input-group">
<input type="text" class="form-control" ng-model="modal.version.cpid" /> <input type="text" class="form-control" ng-model="modal.version.cpid" />
<span class="input-group-btn"> <span class="input-group-btn">
<button <button
class="btn btn-default" class="btn btn-default"
type="button" type="button"
ng-click="modal.saveChanges()"> ng-click="modal.saveChanges()">

View File

@ -1,7 +1,7 @@
<div class="modal-header"> <div class="modal-header">
<h4>Import Public Key</h4> <h4>Import Public Key</h4>
<p>Instructions for adding a public key and signature can be found <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" target="_blank"
title="How to generate and upload SSH key and signature with refstack-client">here. title="How to generate and upload SSH key and signature with refstack-client">here.
</a> </a>

View File

@ -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 REST APIs so that users can dynamically retrieve the test lists with the latest
updates in the Guideline files as needed. updates in the Guideline files as needed.
[1] https://github.com/openstack/defcore/tree/master/2016.01 [1] https://opendev.org/osf/interop/src/branch/master/2016.01/
[2] https://review.opendev.org/#/c/290689/ [2] https://review.opendev.org/290689/
[3] https://review.opendev.org/#/c/215263/ [3] https://review.opendev.org/215263/
Proposed change Proposed change
=============== ===============
@ -118,7 +118,7 @@ The following REST APIs will be added to RefStack.
* JSON schema definition for the response data: * JSON schema definition for the response data:
See DefCore Guideline JSON schema 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** **List tests**

View File

@ -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 **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 (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** **Show vendor details**

View File

@ -308,8 +308,8 @@ References
2017-06-28-16.00.log.html 2017-06-28-16.00.log.html
[3] http://eavesdrop.openstack.org/meetings/refstack/2017/refstack. [3] http://eavesdrop.openstack.org/meetings/refstack/2017/refstack.
2017-07-18-19.00.log.html 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 [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/ [7] https://docs.openstack.org/oslo.config/latest/configuration/
mutable.html mutable.html

View File

@ -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 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 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 * 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. as some logic that bypassed the internal config generation.
@ -60,7 +60,7 @@ N/A
**Documentation Impact** **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** **References**

View File

@ -5,10 +5,10 @@ Storyboard: https://storyboard.openstack.org/#!/story/109
Refstack data is used by the DefCore committee to identify capabilities and Refstack data is used by the DefCore committee to identify capabilities and
tests to include in the OpenStack core. To facilitate this process, refstack 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. 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, broader OpenStack community to select popular capabilities; consequently,
the results should not be focused strictly on DefCore as the consumer. 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 Data model impact
Likely none; however, depending on the complexity of the queries, 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. 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 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: 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 JSON response: GET /[refstack base]/defcore/[release].json
Security impact Security impact

View File

@ -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. * 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. * 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 Proposed change
=============== ===============
Generalized gearman flow. Generalized gearman flow.
(#) execute_test.py is already installed on gearman worker node. (#) 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 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. (#) 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`` (#) 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. (#) 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; This spec covers the following deliverables;
* gearman client side code. (https://review.opendev.org/#/c/84270/) * gearman client side code. (https://review.opendev.org/84270/)
* gearman worker code (wip) * gearman worker code (wip)
* Parts of this are already stubbed out in the code. specifically the "run_gearman" method. * Parts of this are already stubbed out in the code. specifically the "run_gearman" method.
* Test status reporting API call * Test status reporting API call
* This feature will overlap with the following blue print: https://blueprints.launchpad.net/refstack/+spec/update-test-status * 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. * 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 Alternatives
@ -68,11 +68,11 @@ REST API impact
**update-test-status** **update-test-status**
This is a basic method for remote testers to report status to the gui/api This is a basic method for remote testers to report status to the gui/api
* Method type: POST * Method type: POST
* if result is accepted responds with 202 * if result is accepted responds with 202
* Expected error http response code(s) * Expected error http response code(s)
* 400 bad request.. parameter was missing? * 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 * 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 * 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 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 Performance Impact
------------------ ------------------
@ -131,7 +131,7 @@ depending on demand. So there is no real need to worry about performance impacts
Other deployer impact 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". * 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 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 * starts/stops/handle the gearman job queue
* gearman worker code (wip) * gearman worker code (wip)
* report failure api call * report failure api call
@ -165,7 +165,7 @@ Dependencies
============ ============
extends openstack-infra/gear 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. will also require a running gearmand service someplace accessible to both worker and client.

View File

@ -75,7 +75,7 @@ An example rendering would lock like this:
:width: 700px :width: 700px
:alt: Comparison Mock Up :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 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 help quickly find outliers not perform detailed comparison. Drill downs will be used
to resolve specific differences. 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 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. 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 on tables.
Data model impact 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 At this time, we assume that the collection does not require an
intermediate model. 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: Compare against previous results:
HTML response: GET /[refstack base]/compare/[release]/[cloud id] HTML response: GET /[refstack base]/compare/[release]/[cloud id]
@ -156,7 +156,7 @@ Work Items
Dependencies Dependencies
Sparklines JS libraries: http://omnipotent.net/jquery.sparkline/#s-about Sparklines JS libraries: http://omnipotent.net/jquery.sparkline/#s-about
Documentation Impact Documentation Impact
@ -164,4 +164,4 @@ Need to document screen and drill down expectation.
References References
http://wiki.openstack.org/wiki/Governance/DefCoreCommittee http://wiki.openstack.org/wiki/Governance/DefCoreCommittee

View File

@ -38,7 +38,7 @@ str:data - a string input containing json as shown in lower example.
'duration_seconds': 23445234, 'duration_seconds': 23445234,
'results': [ 'results': [
{'name':'fully.qualified.test.path', {'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 */ {'name: 'another.test.path.without.uid'}] /* only passed tests */
} }

View File

@ -15,12 +15,12 @@ Problem description
=================== ===================
Refstack is designed to have minimal user security and configuration overhead; 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 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 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. 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 > 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. authoritative way.
To solve this problem, refstack needs a unique handle for each cloud tested To solve this problem, refstack needs a unique handle for each cloud tested

View File

@ -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 will result in an addition to behavior on the API with no changes
to the user-facing endpoint. 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. This function expects json formated pass results.
Update to the api described at: 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 **url:** post /v1/results

View File

@ -494,5 +494,4 @@ Documentation Impact
References References
========== ==========
[1] https://github.com/openstack/refstack/blob/master/specs/pike/approved [1] https://opendev.org/osf/refstack/src/branch/master/specs/pike/approved/upload-subunit-tests.rst
/upload-subunit-tests.rst

View File

@ -113,7 +113,7 @@ Each API method which is either added or changed should have the following
think about when defining their policy. think about when defining their policy.
Example JSON schema definitions can be found in the Nova tree 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 Note that the schema should be defined as restrictively as
possible. Parameters which are required should be marked as such and possible. Parameters which are required should be marked as such and

View File

@ -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 http://example.com:8000/v1 --tokenfile <token file path>". In order to
successfully update and verify results, you will need admin rights successfully update and verify results, you will need admin rights
for the refstack server in question. Instructions on how to get 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 This script updates RefStack tests as verified given a specific
spreadsheet. The columns in this spreadsheet are, in this order: spreadsheet. The columns in this spreadsheet are, in this order:
* Company Name * Company Name
* Product Name * Product Name
@ -42,7 +43,7 @@ spreadsheet. The columns in this spreadsheet are, in this order:
* License Date * License Date
* Update Product (yes/no) * Update Product (yes/no)
* Contacts * Contacts
* Notes * Notes

View File

@ -6,7 +6,7 @@ skipsdist = True
[testenv] [testenv]
basepython = python3 basepython = python3
usedevelop = True 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} setenv = VIRTUAL_ENV={envdir}
LANG=en_US.UTF-8 LANG=en_US.UTF-8
LANGUAGE=en_US:en LANGUAGE=en_US:en