Move deploy to manager package

[NicolasMahe]

In PR https://github.com/mesg-foundation/core/pull/904, the package manager has been introduced to manage the logic between service and container.

Continuation of conversation: https://github.com/mesg-foundation/core/pull/904#discussion_r277136807

But, the package api has still the logic to deploy the service. It could very easily be moved to the package manager. The api will not even need a dependence to the container package.

Please check the conversation first, and then tell if you are agree to move deploy to manager or leave it like this.

[ilgooz]

this was intentional. Manager is only about managing the containers. not building the Docker images. you can build an image once and all Manager implementations can use the same one. so implementation will not change for Docker Service, Kubernetes or etc.

[NicolasMahe]

i don't understand the difference between managing container and building image for container. Both are dependant on the same system. So why one should be in API and another one in manager?

Actually, to answer to your example, Docker vs Kubernetes, both are using containerd. So if there is something to put in common, it should be docker and kubernetes package that delegate to another containerd package, like: docker.deploy calls containerd.deploy() kubernetes.deploy calls containerd.deploy()

otherwise, if we add a new deployment technology that is NOT using containerd, the api.deploy will need to manually manage all deployment. By moving deploy to the package, the deployment will be delegated to the right system just by implementing the same interface, over and over again.

[ilgooz]

to clarify things, by deploy, we mean about building the Docker image from given service context and Dockerfile. there are some quite tools around to do this. for example Docker daemon comes with one and we access it with docker build command. Kubernetes project also has one called Kaniko. and there are quite many others out there.

but it's too early to take the decision about whether if we only should stick with Docker's build or use/support other tools to build images. we may not need to have different implementations of deploy() if we only stick with one tool.

we should have a clear vision about which build tool fits best with us or do we need multiple of them?

[NicolasMahe]

We will stick with Docker build for a long time I think. We don't have any plan to change the build tool, except if we find one that is deterministic :)

Anyway, because of the new deployment system this code will change very soon and i don't want to lose anyone time on this anymore.

I'm closing this issue.