Fluid Server Discovery

[tianzhu007]

We currently have a one-to-one mapping between the tenant and the fluid server’s cluster i.e. All the sessions for a given tenant will be served by the same orderer, storage pair. With this feature, we will add the ability to dynamically discover the orderer and storage endpoints that will serve the session. Based on the discovery result, the same document in a tenant could be served by different clusters for different collab sessions. The tenant and the fluid server will have the one-to-many map. The discovery endpoint would be used to return the appropriate cluster to serve the session (For eg. It can be optimized for latency based on the client location or be compliance based).

Changes proposed:
1. The create flow: This is the process by which the first client in an FRS session spins up a new session. The clients will be given the discovery URL and discovery will route it to the optimal fluid cluster and return the fluid cluster’s information to the client. Then the client would create the container and session based on the discovery result. The session information including URLs and session status would be stored or updated in the database. Post discovery, the client will continue to talk to the same cluster during the lifetime of the session.
2. The join flow: This is the process by which the subsequent clients join an active session. The client will be given the discovery URL, and the discovery URL will route the tenant to the optimal fluid cluster. The fluid cluster would get the session information for that document from the database and return it to the client. The client then joins the cluster returned by the server.
3. We will also add support to store the tenant and document information to a global database, which can be used during the discovery process.

Test plan:
Even after the proposed changes, users will be able to join clusters directly without going through the discovery process. This will be controlled by the parameters passed to the driver. If we pass the discovery endpoint parameter, the driver will attempt the discovery process. If not, it will fall back to the cluster specific endpoints passed using the fluidHost parameter.
To ensure complete backwards compatibility, we will ensure that the following driver/server combinations are supported:

	Server without Discovery Feature	Server with Discovery Feature
Driver without Discovery Feature	Supported parameter:fluid endpoint	Supported parameter: fluid endpoint
Driver with Discovery Feature	Supported parameter: fluid endpoint	Supported parameters: fluid endpoint or discovery endpoint