benedekh / WeLoveClouds

Repository for submissions on the CloudDB course.
0 stars 1 forks source link

External Configuration Service #69

Closed benedekh closed 7 years ago

benedekh commented 7 years ago
  1. Compute key-range partitioning for initial setup (initial meta-data)
  2. Assemble meta-data
  3. Launch nodes with initial meta-data

1.Compute key-range position of the server within the service

  1. Launch node at a given IP:Port with updated meta-data
  2. Inform neighbour to initiate key-value hand-off
  3. Update meta-data of affected storage nodes
  4. Read requests are always served
  1. Re-compute key-range position for affected storage nodes
  2. Inform neighbour to initiate key-value hand-off
  3. Update meta-data of affected storage nodes
  4. Shut down node at the given IP:Port
  5. Read requests are always served
ghost commented 7 years ago

Could I please have some clarification with regards to the structure of the ECS; There isn't supposed to be a distinct service apart from the client is there? It's going to consist of a CLI sitting on top of a library similar to the KVClient and the KVstore right? If this is the case; where and how does the server collection get stored?

benedekh commented 7 years ago

There will be some kind of ECS Service with that the ECSClient communicates (just for abstraction and separation of concerns).

Regarding the server collection: it is a tab separated file, whose path is a command-line argument of the ECSClient, see m3 docs page 10. First, the ECSClient parses that file, and passes the valid rows (which meet the syntax criteria) to the ECSService that stores a collection of the available machines.

ghost commented 7 years ago

I know about the ECSService storing the valid rows, I was asking about how it's going to store them in terms of a data structure or class. I was thinking of using a set or a map of ServerConnectionInfo objects or something similar.

benedekh commented 7 years ago

Yes, that would be a good idea.