bblfshd icon indicating copy to clipboard operation
bblfshd copied to clipboard

Refactor scalability mechanism - make it _container agnostic_

Open kuba-- opened this issue 6 years ago • 6 comments

Based on Q&A session, the current driver container management approach in Babelfish has some potential problems with compatibility across different OS.

We agreed to switch to docker API as a standard runtime for drivers.

kuba-- avatar Oct 04 '19 10:10 kuba--

It's also partly related to https://github.com/bblfsh/bblfshd/issues/293

kuba-- avatar Oct 04 '19 12:10 kuba--

Also note that one of the considered options is containerd, which is used by Docker under the hood. It's not as low-level as libcontainer and is more similar to Docker itself in this regard.

But running in Docker first makes a lot of sense.

dennwc avatar Oct 08 '19 08:10 dennwc

@bblfsh/maintainers I moved this design to the doc: https://docs.google.com/document/d/1671ApmxFCOmerVKloVC6Q6j8BsJr8xZHbhuE40ZK-as/edit?usp=sharing

So far, there is nothing more (just copied the current proposal), but we can continue discussion in the doc (like @creachadair suggested).

kuba-- avatar Oct 09 '19 18:10 kuba--

Please, consider how this will run in a Kubernetes pod and a docker-compose service. If we use Docker backend, we might effectively need a Docker in Docker setup. In any case, creating a runtime interface sounds great and I hope it might help with rootless containers at some point.

smola avatar Oct 15 '19 10:10 smola

We discussed this a bit more in https://github.com/src-d/minutes/pull/778. While there are important design elements we still need to investigate, we broadly agreed that our target state should:

  1. Separate scalability support from basic operation,
  2. Delegate scalability to other components (e.g., Kubernetes), but
  3. Support running locally for simple workloads without requiring users to install complex dependences (e.g., minikube),
  4. Not require privileged containers (per above, see also #153 for context), and
  5. (Nice to have, if practical) Be runnable locally even without containerization.

Some of the issues we'll need to cover are in the minutes and the associated doc.

creachadair avatar Oct 22 '19 21:10 creachadair

I made this task as epic/umbrella task. Following sub-tasks may also be tracking tasks, so if it's needed we can split them as well, as needed:

  • [ ] "Design/Prototype scalability and deployment support": https://github.com/bblfsh/bblfshd/issues/319
  • [ ] "Design/Prototype local scalable environment": https://github.com/bblfsh/bblfshd/issues/320
  • [ ] "Prototype native parser scaling mechanism": https://github.com/bblfsh/bblfshd/issues/321
  • [ ] "Test scalability layers": https://github.com/bblfsh/bblfshd/issues/322
  • [ ] "Discovery mechanism": https://github.com/bblfsh/bblfshd/issues/323

kuba-- avatar Oct 24 '19 11:10 kuba--