@ -24,12 +24,14 @@ Configuring Services to work with Keystone
nova-api-paste
middleware_architecture
Once Keystone is installed and running (see :doc:`configuration`), services need to be configured to work
with it. To do this, we primarily install and configure middleware for the OpenStack service to handle authentication tasks or otherwise interact with Keystone.
Once Keystone is installed and running (see :doc:`configuration`), services
need to be configured to work with it. To do this, we primarily install and
configure middleware for the OpenStack service to handle authentication tasks
or otherwise interact with Keystone.
In general:
* Clients making calls to the service will pass in an authentication token.
* The Keystone middleware will look for and validate that token, taking the appropriate action.
* Clients making calls to the service will pass in an authentication token.
* The Keystone middleware will look for and validate that token, taking the appropriate action.
* It will also retrive additional information from the token such as user name, id, tenant name, id, roles, etc...
The middleware will pass those data down to the service as headers. More details on the architecture of
@ -42,13 +44,16 @@ Admin Token
-----------
For a default installation of Keystone, before you can use the REST API, you
need to define an authorization token. This is configured in the keystone.conf file under the section ``[DEFAULT]``. In the sample file provided with the keystone project, the line defining this token is
need to define an authorization token. This is configured in ``keystone.conf``
file under the section ``[DEFAULT]``. In the sample file provided with the keystone project, the line defining this token is
[DEFAULT]
admin_token = ADMIN
This is a "shared secret" between keystone and other openstack services, and will need to be set the
same between those services in order for keystone services to function correctly.
This configured token is a "shared secret" between keystone and other
openstack services (for example: nova, swift, glance, or horizon), and will
need to be set the same between those services in order for keystone services
to function correctly.
Setting up tenants, users, and roles
------------------------------------
@ -58,7 +63,7 @@ You need to minimally define a tenant, user, and role to link the tenant and use
Setting up services
===================
Defining Services
Defining Services
-----------------
Keystone also acts as a service catalog to let other OpenStack systems know
@ -146,7 +151,7 @@ rather than it's built in 'tempauth'.
Note that the optional "cache" property in the keystone filter allows any
service (not just Swift) to register its memcache client in the WSGI
environment. If such a cache exists, Keystone middleware will utilize it
environment. If such a cache exists, Keystone middleware will utilize it
to store validated token information, which could result in better overall
To contribute code, sign up for a Launchpad account and sign a contributor license agreement,
available on the `<http://wiki.openstack.org/CLA>`_. Once the CLA is signed you
available on the `<http://wiki.openstack.org/CLA>`_. Once the CLA is signed you
can contribute code through the Gerrit version control system which is related to your Launchpad account.
To contribute tests, docs, code, etc, refer to our `Gerrit-Jenkins-Github Workflow`_.
@ -40,8 +40,8 @@ Running Keystone
To run the keystone Admin and API server instances, use::
$ tools/with_venv.sh bin/keystone
$ tools/with_venv.sh bin/keystone-all
this runs keystone with the configuration the etc/ directory of the project. See :doc:`configuration` for details on how Keystone is configured.
Interacting with Keystone
@ -76,20 +76,32 @@ light integration testing to verify the keystone API against other projects.
Test Structure
--------------
``./run_test.sh`` uses it's python cohort (``run_tests.py``) to iterate through the ``tests`` directory, using Nosetest to collect the tests and invoke them using an
OpenStack custom test running that displays the tests as well as the time taken to
``./run_test.sh`` uses its python cohort (``run_tests.py``) to iterate
through the ``tests`` directory, using Nosetest to collect the tests and
invoke them using an OpenStack custom test running that displays the tests
as well as the time taken to
run those tests.
Within the tests directory, the general structure of the tests is a basic set of tests represented under a test class, and then subclasses of those tests under other classes with different configurations to drive different backends through the APIs.
Within the tests directory, the general structure of the tests is a basic
set of tests represented under a test class, and then subclasses of those
tests under other classes with different configurations to drive different
backends through the APIs.
For example, ``test_backend.py`` has a sequence of tests under the class ``IdentityTests`` that will work with the default drivers as configured in this projects etc/ directory. ``test_backend_sql.py`` subclasses those tests, changing the configuration by overriding with configuration files stored in the tests directory aimed at enabling the SQL backend for the Identity module.
For example, ``test_backend.py`` has a sequence of tests under the class
``IdentityTests`` that will work with the default drivers as configured in
this projects etc/ directory. ``test_backend_sql.py`` subclasses those tests,
changing the configuration by overriding with configuration files stored in
the tests directory aimed at enabling the SQL backend for the Identity module.
Likewise, ``test_cli.py`` takes advantage of the tests written aainst ``test_keystoneclient`` to verify the same tests function through different drivers.
Likewise, ``test_cli.py`` takes advantage of the tests written aainst
``test_keystoneclient`` to verify the same tests function through different
drivers.
Testing Schema Migrations
-------------------------
The application of schema migrations can be tested using SQLAlchemy Migrate’s built-in test runner, one migration at a time.
The application of schema migrations can be tested using SQLAlchemy Migrate’s
@ -62,10 +62,10 @@ When that is complete, you can::
Installing dependencies
=======================
Keystone maintains two lists of dependencies:
Keystone maintains two lists of dependencies::
tools/pip-requires
tools/pip-requires-test
tools/pip-requires-test
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.
@ -97,7 +97,7 @@ 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 depdendencies, useful to keep a clean environment for working on
to just what you're installing as depdendencies, 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::
$ python tools/install_venv.py
@ -125,10 +125,10 @@ into your system from the requires files::
# Install the dependencies for developing, testing, and running keystone
$ pip install -r tools/pip-requires-test
# Fake-install the project by symlinking Keystone into your Python site-packages
$ python setup.py develop
Verifying Keystone is set up
============================
@ -142,14 +142,9 @@ the libraries. If you're using a virtualenv, don't forget to activate it::
You should then be able to `import keystone` from your Python shell
without issue::
>>> import keystone.version
>>> import keystone
>>>
If you want to check the version of Keystone you are running:
>>> print keystone.version.version()
2012.1-dev
If you can import keystone successfully, you should be ready to move on to :doc:`developing`
Joe Heck
11 years ago