Drivers discovery mechanism

[kuba--]

This is hypothetical issue related to driver discovery by bblfshd.
Because we want to get rid of container management part from bblfshd and make it just as a proxy we don't know exactly what discover/dns resolution mechanism we will use.
It can totally rely on k8s dns service or it can take static number of addresses or some config file with pool of addresses per driver.
It's up to us. The most important is to research mechanism which will work locally and in the cloud and allow scaling in both environments.

This task is part of the epic: #313

[dennwc]

Assuming the proposed change in #321 is implemented, we won't need any external scaling for the local use case, only the discovery mentioned in this issue.

Also, I think discovery and "bblfshd as a proxy" can be separate.

For example, we can completely remove bblfshd in K8S and talk to drivers directly (via Ingress/Service) if we figure out a way to use DNS for driver discovery. It may require a custom naming scheme for languages (e.g. pass *-driver.bblfshd.cluster as an address and client must replace * with a language), or maybe adding some metadata to DNS.

For local deployment we may still need bblfshd to return a list of driver addresses (container IPs, or localhost with different ports), but again, we can talk to them directly instead of proxying requests.

This can simplify the case when using a single language: just use a single address for the client, which is an Ingress/Service in K8S or a host:port in local deployment. No separate daemon/proxy needed.

[kuba--]

In my opinion, we can try implement 2 alternative solutions:

• A simple config file or any other static list of addresses
  or (if provided)
• Talk to etcd, where each driver can register.

We can easily make a docker-compose file with all drivers, etcd and bblfshd, or run bblfshd locally but drivers and etcd as docker-compose.

...or maybe even Consul can be a choice.