Refactor scalability mechanism - make it _container agnostic_
kuba-- opened this issue · 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.
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.
@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).
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.
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:
- Separate scalability support from basic operation,
- Delegate scalability to other components (e.g., Kubernetes), but
- Support running locally for simple workloads without requiring users to install complex dependences (e.g., minikube),
- Not require privileged containers (per above, see also #153 for context), and
- (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.
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: