Corrects minor spelling mistakes
Change-Id: Ib603861ad19a525c112153ac3799f2cbe453d4f7
This commit is contained in:
parent
db0519dfa0
commit
f15471f5fd
|
@ -412,7 +412,7 @@ List the services:
|
|||
-H "X-Auth-Token: $OS_TOKEN" \
|
||||
http://localhost:5000/v3/services | python -mjson.tool
|
||||
|
||||
Example reponse:
|
||||
Example response:
|
||||
|
||||
.. code-block:: javascript
|
||||
|
||||
|
|
|
@ -75,7 +75,7 @@ following sections:
|
|||
* ``[sql]`` - optional storage backend configuration
|
||||
* ``[ec2]`` - Amazon EC2 authentication driver configuration
|
||||
* ``[s3]`` - Amazon S3 authentication driver configuration.
|
||||
* ``[oauth1]`` - Oauth 1.0a system driver configuration
|
||||
* ``[oauth1]`` - OAuth 1.0a system driver configuration
|
||||
* ``[identity]`` - identity system driver configuration
|
||||
* ``[catalog]`` - service catalog driver configuration
|
||||
* ``[token]`` - token driver & token provider configuration
|
||||
|
@ -402,10 +402,10 @@ When using signing certificate issued by an external CA, you do not need to
|
|||
specify ``key_size``, ``valid_days`` and ``ca_key`` as they
|
||||
will be ignored.
|
||||
|
||||
The basic workflow for using a signing certificate issed by an external CA involves:
|
||||
The basic workflow for using a signing certificate issued by an external CA involves:
|
||||
|
||||
1. `Request Signing Certificate from External CA`_
|
||||
2. convert certificate and private key to PEM if needed
|
||||
2. Convert certificate and private key to PEM if needed
|
||||
3. `Install External Signing Certificate`_
|
||||
|
||||
|
||||
|
@ -537,11 +537,11 @@ the ``[DEFAULT] use_syslog`` option.
|
|||
|
||||
A sample ``log_config`` file is included with the project at
|
||||
``etc/logging.conf.sample``. Like other OpenStack projects, Keystone uses the
|
||||
`python logging module`, which includes extensive configuration options for
|
||||
`Python logging module`, which includes extensive configuration options for
|
||||
choosing the output levels and formats.
|
||||
|
||||
.. _Paste: http://pythonpaste.org/
|
||||
.. _`python logging module`: http://docs.python.org/library/logging.html
|
||||
.. _`Python logging module`: http://docs.python.org/library/logging.html
|
||||
|
||||
Monitoring
|
||||
----------
|
||||
|
@ -672,14 +672,14 @@ Each user can then change their own password with a HTTP PATCH ::
|
|||
-H "X_Auth_Token: <authtokenid>" -d '{"user": {"password": "ABCD", "original_password": "DCBA"}}'
|
||||
|
||||
In addition to changing their password all of the users current tokens will be
|
||||
deleted (if the backend used is sql)
|
||||
deleted (if the backend used is SQL)
|
||||
|
||||
|
||||
Inherited Role Assignment Extension
|
||||
-----------------------------------
|
||||
|
||||
Keystone provides an optional extension that adds the capability to assign roles to a domain that, rather than
|
||||
affect the domain itself, are instead inherited to all projects owned by theat domain. This extension is disabled by
|
||||
affect the domain itself, are instead inherited to all projects owned by that domain. This extension is disabled by
|
||||
default, but can be enabled by including the following in ``keystone.conf``::
|
||||
|
||||
[os_inherit]
|
||||
|
@ -843,7 +843,7 @@ List of object attributes:
|
|||
The default policy.json file supplied provides a somewhat basic example of
|
||||
API protection, and does not assume any particular use of domains. For
|
||||
multi-domain configuration installations where, for example, a cloud
|
||||
provider wishes to allow adminsistration of the contents of a domain to
|
||||
provider wishes to allow administration of the contents of a domain to
|
||||
be delegated, it is recommended that the supplied policy.v3cloudsample.json
|
||||
is used as a basis for creating a suitable production policy file. This
|
||||
example policy file also shows the use of an admin_domain to allow a cloud
|
||||
|
@ -1296,7 +1296,7 @@ Configuring the LDAP Identity Provider
|
|||
|
||||
As an alternative to the SQL Database backing store, Keystone can use a
|
||||
directory server to provide the Identity service. An example Schema
|
||||
for openstack would look like this::
|
||||
for OpenStack would look like this::
|
||||
|
||||
dn: dc=openstack,dc=org
|
||||
dc: openstack
|
||||
|
|
|
@ -57,7 +57,7 @@ Interacting with Keystone
|
|||
You can interact with Keystone through the command line using
|
||||
:doc:`man/keystone-manage` which allows you to initialize keystone, etc.
|
||||
|
||||
You can also interact with Keystone through its REST API. There is a python
|
||||
You can also interact with Keystone through its REST API. There is a Python
|
||||
keystone client library `python-keystoneclient`_ which interacts exclusively
|
||||
through the REST API, and which keystone itself uses to provide its
|
||||
command-line interface.
|
||||
|
@ -72,7 +72,7 @@ place::
|
|||
|
||||
If the above commands result in a ``KeyError``, or they fail on a
|
||||
``.pyc`` file with the message, ``You can only have one Python script per
|
||||
version``, then it is possible that there are out-of-date compiled python
|
||||
version``, then it is possible that there are out-of-date compiled Python
|
||||
bytecode files in the Keystone directory tree that are causing problems. This
|
||||
can occur if you have previously installed and ran older versions of Keystone.
|
||||
These out-of-date files can be easily removed by running a command like the
|
||||
|
|
|
@ -95,7 +95,7 @@ In using Ubuntu's packages, the packages will set up a user account for
|
|||
the Keystone service (`keystone`), and place default configurations in
|
||||
``/etc/keystone``. The Debian installer will also ask you about configuration
|
||||
options for setting up and running Keystone. As of this writing, the defaults
|
||||
for Keystone backends are all SQL based, stored locally in a sqlite.
|
||||
for Keystone backends are all SQL based, stored locally in a SQLite.
|
||||
|
||||
Once installed, you still need to initialize data in Keystone, which you can
|
||||
find described in :doc:`configuringservices`.
|
||||
|
|
|
@ -71,7 +71,7 @@ Keystone maintains two lists of dependencies::
|
|||
|
||||
The first is the list of dependencies needed for running keystone, the second list includes dependencies used for active development and testing of keystone itself.
|
||||
|
||||
These dependencies can be installed from PyPi_ using the python tool pip_.
|
||||
These dependencies can be installed from PyPi_ using the Python tool pip_.
|
||||
|
||||
.. _PyPi: http://pypi.python.org/
|
||||
.. _pip: http://pypi.python.org/pypi/pip
|
||||
|
@ -99,8 +99,8 @@ Mac OS X 10.9 (requires Homebrew_)::
|
|||
PyPi Packages and VirtualEnv
|
||||
----------------------------
|
||||
|
||||
We recommend establishing a virtualenv to run keystone within. Virtualenv
|
||||
limits the python environment to just what you're installing as dependencies,
|
||||
We recommend establishing a virtualenv to run keystone within. virtualenv
|
||||
limits the Python environment to just what you're installing as dependencies,
|
||||
useful to keep a clean environment for working on Keystone. The tools directory
|
||||
in keystone has a script already created to make this very simple::
|
||||
|
||||
|
@ -130,7 +130,7 @@ dependencies directly into your system from the requires files::
|
|||
# Install the dependencies for developing, testing, and running keystone
|
||||
$ pip install -r test-requirements.txt
|
||||
|
||||
# Use python setup.py to link Keystone into python's site-packages
|
||||
# Use 'python setup.py' to link Keystone into Python's site-packages
|
||||
$ python setup.py develop
|
||||
|
||||
|
||||
|
@ -138,7 +138,7 @@ Verifying Keystone is set up
|
|||
============================
|
||||
|
||||
Once set up, either directly or within a virtualenv, you should be able to
|
||||
invoke python and import the libraries. If you're using a virtualenv, don't
|
||||
invoke Python and import the libraries. If you're using a virtualenv, don't
|
||||
forget to activate it::
|
||||
|
||||
$ source .venv/bin/activate
|
||||
|
|
|
@ -467,7 +467,7 @@ class CatalogTestCase(test_v3.RestfulTestCase):
|
|||
self.assertEqual(len(endpoints), 1)
|
||||
endpoint_v3 = endpoints.pop()
|
||||
|
||||
# these attributes are identical between both API's
|
||||
# these attributes are identical between both APIs
|
||||
self.assertEqual(endpoint_v3['region'], ref['region'])
|
||||
self.assertEqual(endpoint_v3['service_id'], ref['service_id'])
|
||||
self.assertEqual(endpoint_v3['description'], ref['description'])
|
||||
|
|
Loading…
Reference in New Issue