Delete deployed service in command service dev

[NicolasMahe]

Problem

When developing a service using the service dev command a lot, the service get deployed every time this command is ran and it results in a useless pollution of the same service deployed multiple time.

Make sure to only delete the service when it's deployed (some flag prevent the service deployment)

Solution

Service test command should delete the service it has deployed.

[ahonegger]

hi @NicolasMahe

i hope you don't mind me adding in a few comments here and hope you will be able to fill in the blanks. in general the way i see things is that unless required by maybe an additional flag --force-rebuild, we should be be reusing the docker image and service created/deployed when the command is first used.

after digging a little deeper, here is what i found. basically every time someone issues the command service test the docker client is instructed to build an image by calling ImageBuild, which is basically equivalent of calling docker build. the only thing that currently avoids a full blown rebuild is docker's caching. I believe that maybe a more elegant approach would be to just use the already built image via ContainerCreate and then ContainerStart equivalent to docker run as long as the service developer didn't make any changes. I am aware that this approach would be a little more invasive as it might have an architectural impact.

one thing i don't completely understand yet is, why does the service need to be redeployed every time service test is called?

Sorry for the great wall of text here, but i wanted to understand more why things work the way the work now.

[antho1404]

The workflow is the following:

• build the docker image (with the latest version of code and the latest mesg definitions)
• deploy the service (this generate an unique ID for this exact version of the service)
• start the deployed service

In the current implementation, we need to deploy the service in order to have an ID that is used in different places, the communication between the core and the service and also the pub/sub system associated to this service. The service need to be integrated in the core (with the deploy) otherwise some features might not be accessible.

Also if we re-use the built image we are not sure that the developer didn't update the code of the service. By relying to the docker cache system we make sure that the version we test is always the good one and if there is no modification the cache of docker is smart enough to see it and the build will be almost instant so we can build every-time it's not a problem.

Maybe we can find a way to test a service without deploying it but I actually like the fact that we can have access to all the different versions of the service even during the development.

Actually we could have a flag to auto-delete the service when the command test is finished like that we can keep the history if we want to.

Also this issue #275 will make sure that all the different versions of a same service are grouped together so it might not be a problem to have all the versions of every tests

[ahonegger]

thanks for the explanation and good that you mention issues #275, in fact that is where i drew my inspiration from and thought maybe we can kill 2 birds with one stone.

the workflow i was having in mind is, if the service developer leaves the service id unchanged we will just reuse the existing docker image, and start the already deployed service. if the service id changed we would use the current way and ask docker to check the cache and rebuild the image if needed, deploy the service and start it.

of course the above assumes that we do have a elegant way to address issue #275