API: Store consoleauth tokens to the database

Registered by Xavier Queralt

Currently the consoleauth service is storing the tokens and the connection data only in memory. This behavior makes impossible to have multiple instances of this service in a cluster as there is no way for one of the isntances to know the tokens issued by the other.

The consoleauth service can use a memcached server to store those tokens, but again, if we want to share them among different instances of it we would be relying in one memcached server which makes this solution unsuitable for a highly available architecture where we should be able to replicate all of the the services in our cluster.

What this blueprint proposes is to change the consoleauth service to store the tokens in the database and, optionally, cache them in memory as it does now for fast access.

Blueprint information

Status:
Started
Approver:
Russell Bryant
Priority:
Medium
Drafter:
Xavier Queralt
Direction:
Needs approval
Assignee:
None
Definition:
Review
Series goal:
None
Implementation:
Needs Code Review
Milestone target:
milestone icon next
Started by
Xavier Queralt

Related branches

Sprints

Whiteboard

It seems OK to add this as a pluggable persistence approach. Please look at the DB objects and create objects, and look at having a DB and memory sub class to do what you need to do, it seems like a sensible approach. Also please review if you will have this done is icehouse-1 it is very soon. --johnthetubaguy

With Icehouse-1 just over two weeks away (December 5th), moving this to Icehouse-2 since it hasn't been started yet. If it does get into Icehouse-1, we can re-target the BP. --jogo

Deferred to icehouse-3 as the blueprint was not approved by the icehouse-2 blueprint approval deadline. --russellb

Gerrit topic: https://review.openstack.org/#q,topic:bp/consoleauth-tokens-in-db,n,z

Addressed by: https://review.openstack.org/68155
    Store consoleauth tokens into database

After having reviewed the patch, I am not completely against having this in the database *as one option*, but am wondering, since the motivation for this is HA, but not in terms of data but rather service availability. wouldn't rolling a simple consistent hashing story for our memcahced clients get us 99% there?
--ndipanov

Unapproved - please re-submit via nova-spec --johnthetubagy (20th March 2014)

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.