API: Store consoleauth tokens to the database
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:
- Complete
- Approver:
- Russell Bryant
- Priority:
- Medium
- Drafter:
- Xavier Queralt
- Direction:
- Needs approval
- Assignee:
- None
- Definition:
- Superseded
- Series goal:
- None
- Implementation:
-
Needs Code Review
- Milestone target:
-
next
- Started by
- Xavier Queralt
- Completed by
- melanie witt
Related branches
Related bugs
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:/
Addressed by: https:/
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)
