Juju Charm - Keystone
Go to file
yolanda.robla@canonical.com bc1da09487 adding syslog functionality
2014-02-03 12:58:43 +01:00
hooks adding syslog functionality 2014-02-03 12:58:43 +01:00
scripts Sync scripts/. 2013-04-09 11:35:51 -07:00
templates Fixup haproxy template 2013-03-18 15:03:40 +00:00
charm-helpers.yaml Add preinstall hook and create charm-helpers.yaml to pull in additional charmhelpers module to support it 2013-11-12 16:28:10 +00:00
config.yaml adding syslog functionality 2014-02-03 12:58:43 +01:00
copyright Add copyright 2011-12-23 17:55:37 -08:00
icon.svg Fix icon.svg. 2013-11-04 00:56:57 -08:00
metadata.yaml Merge lp:charms/keystone 2013-05-20 11:35:56 +01:00
README.md Make VIP usage clearer. 2013-08-19 14:35:48 -04:00
revision adding syslog functionality 2014-02-03 12:58:43 +01:00

This charm provides Keystone, the Openstack identity service. It's target platform is Ubuntu Precise + Openstack Essex. This has not been tested using Oneiric + Diablo.

It provides two interfaces.

- identity-service:  Openstack API endpoints request an entry in the 
  Keystone service catalog + endpoint template catalog.  When a relation
  is established, Keystone receives: service name, region, public_url,
  admin_url and internal_url.  It first checks that the requested service
  is listed as a supported service.  This list should stay updated to
  support current Openstack core services.  If the services is supported,
  a entry in the service catalog is created, an endpoint template is
  created and a admin token is generated.   The other end of the relation
  recieves the token as well as info on which ports Keystone is listening.

- keystone-service:  This is currently only used by Horizon/dashboard
  as its interaction with Keystone is different from other Openstack API
  servicies.  That is, Horizon requests a Keystone role and token exists.
  During a relation, Horizon requests its configured default role and
  Keystone responds with a token and the auth + admin ports on which
  Keystone is listening.

Keystone requires a database. By default, a local sqlite database is used. The charm supports relations to a shared-db via mysql-shared interface. When a new data store is configured, the charm ensures the minimum administrator credentials exist (as configured via charm configuration)

VIP is only required if you plan on multi-unit clusterming. The VIP becomes a highly-available API endpoint.