<div dir="ltr">Hi Samuel,<div><br></div><div>(And sorry for the delay in getting back to you)</div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Oct 24, 2016 at 2:57 PM, Samuel Cozannet <span dir="ltr"><<a href="mailto:samuel.cozannet@canonical.com" target="_blank">samuel.cozannet@canonical.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Background: I am currently working with IBM on some GPU docker based images, so I have to use docker on ppc64le.  </div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>I came across nvidia-docker, which is the tool distributed by nVidia to abstract the management of GPUs when running docker images.</div></div></blockquote><div><br></div><div>I had to learn about nvidia-docker before trying to formulate a reply, here's an attempted summary (please correct!):</div><div>  Nvidia wants to empower people distributing docker images leveraging their CUDA stack; this requires userspace SDK tools & libs and access to the hardware. In the past, they suggested people should hardcode the required device sharing when calling docker, but they realized this would break over time.</div><div>  nvidia-docker provides a wrapper around docker that will automatically attach the relevant dev nodes to access CUDA compute resources, and it will also filter docker images based on tags to use the ones from the proper SDK versions.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>nVidia does support ppc64le, and provide code to package nvidia-docker as a deb on this arch, but do not maintain repos so you have to package it yourself. </div><div>The nvidia-docker deb depends on docker-engine, which is not supported by Docker on ppc64le (and provides the same functionality as <a href="http://docker.io" target="_blank">docker.io</a>, which is in our repos). So it didn't build ootb, and I had to update the control file for the .deb to reference <a href="http://docker.io" target="_blank">docker.io</a> and I was able to build it. </div><div><br></div><div>With the recent flow of emails about the docker snap, I wondered how would the system have reacted if would I have installed the docker engine via snap? </div><div>I guess it wouldn't have liked it. As the docker snap and docker deb conflict, this would mean I could not use the snap in this context.</div></div></blockquote><div><br></div><div>I read a bit through the <a href="https://github.com/NVIDIA/nvidia-docker">source of nvidia-docker</a>, and it seems to query the docker version to make informed choices about how to invoke docker client / daemon commands. It seems everything is done via command calls (that is, <a href="https://github.com/NVIDIA/nvidia-docker/blob/master/tools/src/docker/docker.go#L16">nvidia-docker runs "docker"</a>).</div><div><br></div><div>So it seems to me nvidia-docker source doesn't really care where docker commands were provided from and it should be possible to make it work with the snap just fine.</div><div><br></div><div>However, the nvidia-docker deb packaging will obviously rely on the deb – as you mentioned.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>What is our recommendation for maintainers of .deb / .snap to manage dependencies? Especially, for deb maintainers, what is the best practice going forward? </div></div></blockquote><div><br></div><div><div>IIUC, the question is how could we make sure the docker snap is there when installing the nvidia-docker deb, and I don't think we have a way to do this short of providing documentation and CLI feedback ("docker not found, please install docker snap by following these instructions").  Personally, as a .deb user, I would expect strong consistency between software components when installing a deb package, so I would expect apt-get install nvidia-docker to pull all the dependencies as .debs and not a mix of debs and snaps.</div><div><br></div><div>And for snaps, I would actually everything to come with the snap (batteries included); snap install nvidia-docker just gives me the nvidia flavor of docker with the special extensions but also the pain that comes with a fork.</div><div> </div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>(needless to say the answer "just make a snap" doesn't really work her as the focus is more on managing the transition, but also cover the cases where the .deb is required for some customers / production workload which will not necessarily move from the traditional packages over night)</div></div></blockquote><div><br></div><div>I was about to answer "just make a snap" but I guess I could equally answer "just make a deb".   :-)</div><div><br></div><div>If you want to leverage the snap, then I'd suggest forking it and creating a nvidia-docker snap. If you'd rather derive from the deb, the current approach seems to be fine, but you might end up having to carry the burden of maintaining the debs if the maintenance efforts are concentrated on the snap.</div><div><br></div><div>Now this might also be something that Docker cares to solve: how does one extend docker command-line and behavior? This seems very similar to when I install a web browser extension to change the behavior of my web browser for specific pages or actions, does docker provide an extension mechanism? If not, would they?</div><div>  I find it ironic that the exact issue that pushed for docker deb and snap to be incompatible was lack of abstraction for this kind of things in docker: docker doesn't provide a standard way to expose the docker daemon to the running container, one is expected to "docker run -v /var/run/docker.sock:/var/run/docker.sock"; if they had something like a --share-daemon-socket option, you could use 20 different docker versions and socket locations without conflicts. It's exactly this kind of issues that NVidia is trying to solve with their fork!</div><div><br></div><div>Obviously these are all long shots and I didn't provide any practical answer on improving deb to snap or snap to deb transition; this is a larger question not specific to the docker snap that we need to keep working on.</div></div><div class="gmail_extra"><br></div>Cheers,<br><div class="gmail_signature"><div dir="ltr">- Loïc Minier</div></div>
</div></div>