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
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

View File

@ -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

View File

@ -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``

View File

@ -2,7 +2,7 @@
<div class="modal-header">
<button type="button" class="close" aria-hidden="true" ng-click="modal.close()">&times;</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&#8482; guideline from capabilities with the following statuses:
</p>
<ul class="list-inline">

View File

@ -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>

View File

@ -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()">

View File

@ -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()">

View File

@ -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>

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
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**

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
(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**

View File

@ -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

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
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**

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
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

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.
* 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.

View File

@ -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

View File

@ -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 */
}

View File

@ -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

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
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

View File

@ -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

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.
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

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
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

View File

@ -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