Locating the Coordinator
DNS?
Authentication
Users
See Security for the current proposal. Briefly, clients/users will provide a secret to the Coordinator which the Coordinator will verify and issue a token. Users must provide this token on RAMCloud requests which the Master will confirm with the Coordinator (and cache).
The Coordinator stores (persistent) a shared secret with the users. It also houses the tokens (soft state), we may want some persistence on this to keep from flooding a new Coordinator with authentication requests after a Coordinator recovery.
ACLs/Workspaces
For the moment access to a Workspace is all or nothing (or perhaps even conflated with the user) hence the Coordinator stores (persistent) a list of workspaces the user owns (or in the conflated case, the secret associated with each Workspace).
Servers
Master -> Coordinator
This step helps us with naming later as well. Since Masters must authenticate to the Coordinator and it assigns the Master roles it can then slot the Master into its naming tables (soft state).
Backup -> Coordinator
Master -> Backup
Problem: A Master may disclose data to a non-RAMCloud machine if a machine a machine address is reallocated for use as a non-RAMCloud machine. Possible solutions: ignore it or encrypt data.
Naming
A lookup table of logical hosts to (soft state) RPC addresses.
Aside: I don't really believe the Master -> RPC Addr mapping will need to be replicated, nor the Backup -> RPC Addr one.
Host Addressing
Tables/Tablets and Indexes
Placement
Location/Discovery
Reconfiguration
Recovery
Choosing Replacements
Crash Confirmation
Broadcast Notifications
Partition Detection
Statistics
Logging
Metrics
Configuration Information
Rack Placement
Machine Parameters
Summary of Coordinator State
- Workspace list
- Possibly users
- User or workspace secrets
- (soft) Issued security tokens
- (soft) Logical host naming