2011-11-07 14:13:35 -08:00
|
|
|
Keystone Light
|
|
|
|
==============
|
2011-06-20 17:56:20 -07:00
|
|
|
|
2011-11-02 16:39:54 -07:00
|
|
|
*Always Smooth*
|
2011-06-20 17:56:20 -07:00
|
|
|
|
2011-11-02 16:39:54 -07:00
|
|
|
Keystone Light is a re-interpretation of the Keystone project that provides
|
|
|
|
Identity, Token and Catalog services for use specifically by projects in the
|
|
|
|
OpenStack family.
|
2011-06-20 17:56:20 -07:00
|
|
|
|
|
|
|
|
2011-11-02 16:39:54 -07:00
|
|
|
----------
|
|
|
|
Data Model
|
|
|
|
----------
|
2011-06-20 17:56:20 -07:00
|
|
|
|
2011-11-02 16:39:54 -07:00
|
|
|
Keystone Light was designed from the ground up to be amenable to multiple
|
|
|
|
styles of backends and as such many of the methods and data types will happily
|
|
|
|
accept more data than they know what to do with and pass them on to a backend.
|
2011-06-20 17:56:20 -07:00
|
|
|
|
2011-11-02 16:39:54 -07:00
|
|
|
There are a few main data types:
|
2011-06-20 17:56:20 -07:00
|
|
|
|
2011-11-02 16:39:54 -07:00
|
|
|
* **User**: has account credentials, is associated with one or more tenants
|
|
|
|
* **Tenant**: unit of ownership in openstack, contains one or more users
|
|
|
|
* **Token**: identifying credential associated with a user or user and tenant
|
2011-11-02 16:41:01 -07:00
|
|
|
* **Extras**: bucket of key-values associated with a user-tenant pair, typically used to define roles.
|
2011-06-20 17:56:20 -07:00
|
|
|
|
2011-11-02 16:39:54 -07:00
|
|
|
While the general data model allows a many-to-many relationship between Users
|
|
|
|
and Tenants and a many-to-one relationship between Extras and User-Tenant pairs,
|
|
|
|
the actual backend implementations take varying levels of advantage of that
|
|
|
|
functionality.
|
2011-06-20 17:56:20 -07:00
|
|
|
|
|
|
|
|
2011-11-02 16:39:54 -07:00
|
|
|
KVS Backend
|
|
|
|
-----------
|
2011-06-20 17:56:20 -07:00
|
|
|
|
2011-11-02 16:39:54 -07:00
|
|
|
A simple backend interface meant to be further backended on anything that can
|
|
|
|
support primary key lookups, the most trivial implementation being an in-memory
|
|
|
|
dict.
|
2011-06-20 17:56:20 -07:00
|
|
|
|
2011-11-02 16:39:54 -07:00
|
|
|
Supports all features of the general data model.
|
2011-06-20 17:56:20 -07:00
|
|
|
|
2011-11-02 16:39:54 -07:00
|
|
|
|
|
|
|
PAM Backend
|
|
|
|
-----------
|
|
|
|
|
|
|
|
Extra simple backend that uses the current system's PAM service to authenticate,
|
|
|
|
providing a one-to-one relationship between Users and Tenants with the `root`
|
|
|
|
User also having the 'admin' role.
|
|
|
|
|
|
|
|
|
|
|
|
Templated Backend
|
|
|
|
-----------------
|
|
|
|
|
|
|
|
Largely designed for a common use case around service catalogs in the Keystone
|
|
|
|
project, a Catalog backend that simply expands pre-configured templates to
|
|
|
|
provide catalog data.
|
|
|
|
|
2011-11-02 16:43:47 -07:00
|
|
|
Example paste.deploy config (uses $ instead of % to avoid ConfigParser's
|
|
|
|
interpolation)::
|
|
|
|
|
|
|
|
[DEFAULT]
|
|
|
|
catalog.RegionOne.identity.publicURL = http://localhost:$(public_port)s/v2.0
|
|
|
|
catalog.RegionOne.identity.adminURL = http://localhost:$(public_port)s/v2.0
|
|
|
|
catalog.RegionOne.identity.internalURL = http://localhost:$(public_port)s/v2.0
|
|
|
|
catalog.RegionOne.identity.name = 'Identity Service'
|
|
|
|
|
2011-11-02 16:39:54 -07:00
|
|
|
|
|
|
|
---------------
|
|
|
|
Keystone Compat
|
|
|
|
---------------
|
|
|
|
|
|
|
|
While Keystone Light takes a fundamentally different approach to its services
|
|
|
|
from Keystone, a compatibility layer is included to make switching much easier
|
|
|
|
for projects already attempting to use Keystone.
|
|
|
|
|
|
|
|
The compatibility service is activated by defining an alternate application in
|
|
|
|
the paste.deploy config and adding it to your main pipeline::
|
|
|
|
|
|
|
|
[app:keystone]
|
|
|
|
paste.app_factory = keystonelight.keystone_compat:app_factory
|
|
|
|
|
2011-11-07 10:38:40 -08:00
|
|
|
Also relevant to Keystone compatibility are these sequence diagrams (openable
|
|
|
|
with sdedit_)
|
|
|
|
|
|
|
|
.. _sdedit: http://sourceforge.net/projects/sdedit/files/sdedit/4.0/
|
|
|
|
|
|
|
|
Diagram: keystone_compat_flows.sdx_
|
|
|
|
|
|
|
|
.. _: https://raw.github.com/termie/keystonelight/master/docs/keystone_compat_flows.sdx
|
2011-11-02 16:39:54 -07:00
|
|
|
|
|
|
|
-----------
|
|
|
|
Still To Do
|
|
|
|
-----------
|
|
|
|
|
2011-11-03 14:08:38 -07:00
|
|
|
* Dev and testing setups would do well with some user/tenant/etc CRUD, for the
|
|
|
|
KVS backends at least.
|
|
|
|
* Fixture loading functionality would also be killer tests and dev.
|
|
|
|
* LDAP backend.
|
|
|
|
* Keystone import.
|
|
|
|
* Admin-only interface
|
2011-11-07 14:11:27 -08:00
|
|
|
* Don't check git checkouts as often, to speed up tests
|