Open JonathanMace opened 9 months ago
Some thoughts / comments on design for the Kubernetes plugin:
New pieces:
localhost:5000
and thus images will be named things like localhost:5000/user_service
. We can add a wiring spec function to allow overriding this (or alternatively use a command line flag)If we do the above then the only difference between running with minikube vs. real kube is the image repo url (since we can assume that you wouldn't host the images on localhost if you're using real kube, instead there would be an actual image repo running somewhere in your cluster).
After some experimentation, the golang docker API is a bit of a pain and doesn't seem to be doing the same thing as equivalent command-line commands. Probably for now it's best to just execute command line commands.
We probably also want to make sure the image builds are done in parallel since it can be slow.
We thank the authors for making their contributions open-sourced and for their continued efforts. We are interested in using Blueprint as part of the authorship of a paper and were interested in learning about the progress on this issue and/or on the Kubernetes branch. Thank you very much once again.
Hi @canteversleep, we are in the process of adding the Kubernetes plugin (#162 ). I have been busy with some other projects so we haven't gotten around to fully implementing it. If you need this urgently, then we can prioritize this and have it implemented + merged in the next couple of weeks.
Hey @vaastav, thank you very much for your response and for considering prioritization of this branch. Our clusters are most compatible with Kubernetes deployments and we would therefore be aided by priority implementation of the plugin for our paper. I understand how working on multiple projects gets and really appreciate any time you can put into this. Thank you again for making this work open-sourced and sharing it with the community!
Blueprint v1 used a docker-to-kubernetes tool to translate docker-compose files into Kubernetes. We don't want to do this, because subsequent plugins will want to use kubernetes features that require modifying the kubernetes deployment files.
This issue needs to implement Kubernetes. Fortunately the docker-compose plugin already has the same end-to-end workflow as Kubernetes would have (collecting and combining container images, generating ports, etc.).