Denys Smirnov

Hi @dustinmichels! It is indeed Docker-related, but we should clarify it in the documentation anyway. You achieve similar results in a few different ways, please pick one that suits your...

> do we want to expose pure container's metrics or mainly driver's metrics? We don't have container metrics since we use `libcontainer`. We'll need to implement them on our own,...

It would be ideal, I guess, but we may create/kill drivers at a very high rate, so updating a set of Prometheus data sources may end up being harder than...

> I think adding a new drivers does not happen very often @kuba-- It happens regularly because of the scaling policy in bblfshd. Each second it may kill or run...

Agree on switching to docker. The main reason why I insisted on aggregating metrics from drivers in the daemon is because it's the only way to expose metrics without additional...

Babelfish does not require Docker to run, but it requires namespaces and cgroups provided by Linux kernel. We use [libcontainer](https://github.com/opencontainers/runc/tree/master/libcontainer) under the hood to isolate language drivers and it might...

Thanks for a very detailed report! This is a known issue - the request cancellation can only be propagated to the Go part of the driver, but the native part...

Assuming the proposed change in https://github.com/bblfsh/bblfshd/issues/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...

I think it may be because all other drivers are now too old and don't support current SDK, so they are ignored by current version of `bblfshd`.

I think it may be easier to go from a different angle: keep native drivers single-threaded, but allow running multiple native processes, which are controlled/scaled by Go driver server (the...