openinfra/refstack
Code Issues Proposed changes

[Trivialfix]Fix typos

Browse Source 
Fix the typos found in refstack.

Change-Id: I66724acaf6472df2a2d957b1c795d4dbcc06a68b
This commit is contained in:
shangxiaobj 2017-09-13 19:52:23 -07:00
parent fe2eca2ea6
commit fa7fb738ad
8 changed files with 15 additions and 15 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
specs/newton/implemented/product-version-datamodel-api.rst
View File

@ -96,7 +96,7 @@ different products?
* It could also be two products, since the 2 names are not the same.
Such kind of data integrity and consistency issues should be avoid whenever
possible with appropriate database design and/or bussiness layer code.
possible with appropriate database design and/or business layer code.
========== =================== =======
product_id Name Version

2
specs/pike/approved/add-refstack-docs.rst
View File

@ -7,7 +7,7 @@ Launchpad blueprint:
* https://blueprints.launchpad.net/refstack/+spec/user-documentation
This specification defines the changes to the "About" page of the RefStack
website in that are neccessary in order to allow RefStack documentation to be
website in that are necessary in order to allow RefStack documentation to be
displayed natively on the RefStack site.
Problem description

4
specs/pike/approved/upload-subunit-tests.rst
View File

@ -19,7 +19,7 @@ to the passed tests. This limitation dates back to the the start of the
RefStack project. At that time, Defcore (which is now known as interop-WG)
was very concerned about the possibility that private data may be included
in the subunit upload file. Defcore was concerned that vendors might, for
that reason, be hesistant to upload data into RefStack for fear of
that reason, be hesitant to upload data into RefStack for fear of
unintentionally revealing vendor-specific data such as reasons for test
failures. For this reason, Defcore agreed unanimously that RefStack should
care only about passing tests, and not failed or skipped ones.
@ -213,7 +213,7 @@ significant reversal in a past decision, that the community should be
properly notified. This decision also resulted in the following action plan:
1. write an email to distribute to the mailing list
2. send out the official decision after the email is distributed
3. change the offical interop docs to reflect this change
3. change the official interop docs to reflect this change
Another concern was that a database injection attack may be possible, if an
attacker were to use maliciously crafted subunit data. This threat, also,

4
specs/prior/approved/refstack-org-tcup-base.rst
View File

@ -62,7 +62,7 @@ Alternatives
It would be possible to create a single-use VM for this testing. That would require much more download time, build effort and maintenance.
An additional method is to package execute_test on its own allowing it to install on fedora and ubuntu. It already has tempest havana stable as a dependancy. It can be installed and the rc file can be sourced and it can be kicked off. No container would be needed and you can log into any cloud instance on any cloud provider that has network reach to the cloud you want to test. Start an ephemeral vm and log into it and run two commands.
An additional method is to package execute_test on its own allowing it to install on fedora and ubuntu. It already has tempest havana stable as a dependency. It can be installed and the rc file can be sourced and it can be kicked off. No container would be needed and you can log into any cloud instance on any cloud provider that has network reach to the cloud you want to test. Start an ephemeral vm and log into it and run two commands.
Yet another approach is to assume tempest havana is already installed. Users can invokes execute_test directly without using docker or any container. This omits the "minimal setup" TCUP approach.
@ -160,4 +160,4 @@ TCUP needs detailed community facing documentation and video tours.
References
==========
* http://docker.io
* http://docker.io

6
specs/prior/implemented/refstack-org-test-result-json-schema.rst
View File

@ -40,7 +40,7 @@ Alternatives
Another alternative is manually writing code to validate test results.
This schema does not preclue that alternative, but by creating and
validating against a schema we take advantage of existing libraries
and reduce the possiblity of introducing unintended parsing errors.
and reduce the possibility of introducing unintended parsing errors.
Data model impact
-----------------
@ -88,7 +88,7 @@ No invalid responses. No accepted parameters.
Security impact
---------------
This change is intented to improve the security of the application
This change is intended to improve the security of the application
by introducing data validation. No data-changing apis are
introduced.
@ -124,7 +124,7 @@ No additional developer impact.
Implementation
==============
This change will be implemented as a validation funtion in the API POST
This change will be implemented as a validation function in the API POST
pipeline. It will essentially be middleware that takes the input data,
validates the results, and sends back a positive or a negative result.
If the result is negative, the 400 response will be returned.

4
specs/prior/implemented/seperate_refstack_tester_from_refstack.rst
View File

@ -58,7 +58,7 @@ none/
**Developer impact**
When finished tcup would need to have the tester as a dependancy.
When finished tcup would need to have the tester as a dependency.
**Implementation:**
@ -82,7 +82,7 @@ none.
**Testing**
The new project will require a base set of tests so that ci works propperly.
The new project will require a base set of tests so that ci works properly.
**Documentation Impact**

6
specs/prior/implemented/simplify-uploads-by-only-sending-pass-results.rst
View File

@ -79,10 +79,10 @@ None
Developer impact
----------------
This could potentially be a maintance problem moving forward as we move the
This could potentially be a maintenance problem moving forward as we move the
subunit parsing utils into tempest then move the tester into its own repo.
It will require that someone stays on top of things durring those changes to avoid
It will require that someone stays on top of things during those changes to avoid
duplication of code.
@ -126,4 +126,4 @@ But outside of that I don't see the need for documentation.
References
==========
N/A
N/A

2
tools/update-rs-db.rst
View File

@ -2,7 +2,7 @@
# update-rs-db.py #
#######################################################################
This document contains some details that are neccessary to know to be
This document contains some details that are necessary to know to be
successful in the usage of the script update-rs-db.py.
The script can be run using the following formatting: