openstack/barbican
Code Issues Proposed changes

Fix typos

Browse Source 
There are some wrong words, it should be updated.

Change-Id: Ib57e056ac43c0e1815ee135f402490f2cef0ad10
This commit is contained in:
Nam Nguyen Hoai 2017-01-20 11:47:36 +07:00
parent 78ae6fd072
commit a936b28c49
2 changed files with 2 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
doc/source/setup/noauth.rst
View File

@ -33,7 +33,7 @@ To enable this pipe line proceed as follows:
With every OpenStack service integrated with keystone, its API requires access
token to retireve certain information and validate user's information and
prviledges. If you are running barbican in no auth mode, you have to specify
privileges. If you are running barbican in no auth mode, you have to specify
project_id instead of an access token which was retrieved from the token
instead. In case of API, replace ``'X-Auth-Token: $TOKEN'`` with
``'X-Project-Id: {project_id}'`` for every API request in :doc:`../api/index`.

2
doc/source/setup/plugin_backends.rst
View File

@ -91,7 +91,7 @@ Multiple backend can be useful in following type of usage scenarios.
* HSM devices generally have limited storage capacity so a deployment will
have to watch its stored keys size proactively to remain under the limit
constraint. This is more applicable in KMIP backend than with PKCS11 backend
because of plugin's different storage apporach. This aspect can also result
because of plugin's different storage approach. This aspect can also result
from above use case scenario where deployment is storing non-sensitive (from
dev/test environment) encryption keys in HSM.
* Barbican running as IaaS service or platform component where some class of