[snaps/deb] Cross dependencies / forward compatibility between debs & snaps?

[Loïc Minier]

Hi Samuel,

(And sorry for the delay in getting back to you)

On Mon, Oct 24, 2016 at 2:57 PM, Samuel Cozannet <
samuel.cozannet at canonical.com> wrote:

> Background: I am currently working with IBM on some GPU docker based
> images, so I have to use docker on ppc64le.
>
I came across nvidia-docker, which is the tool distributed by nVidia to
> abstract the management of GPUs when running docker images.
>

I had to learn about nvidia-docker before trying to formulate a reply,
here's an attempted summary (please correct!):
  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.
  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.


> 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.
> The nvidia-docker deb depends on docker-engine, which is not supported by
> Docker on ppc64le (and provides the same functionality as docker.io,
> which is in our repos). So it didn't build ootb, and I had to update the
> control file for the .deb to reference docker.io and I was able to build
> it.
>
> 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?
> 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.
>

I read a bit through the source of nvidia-docker
<https://github.com/NVIDIA/nvidia-docker>, 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, nvidia-docker
runs "docker"
<https://github.com/NVIDIA/nvidia-docker/blob/master/tools/src/docker/docker.go#L16>
).

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.

However, the nvidia-docker deb packaging will obviously rely on the deb –
as you mentioned.

What is our recommendation for maintainers of .deb / .snap to manage
> dependencies? Especially, for deb maintainers, what is the best practice
> going forward?
>

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.

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.


> (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)
>

I was about to answer "just make a snap" but I guess I could equally answer
"just make a deb".   :-)

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.

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?
  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!

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.

Cheers,
- Loïc Minier
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/snapcraft/attachments/20161105/929f6421/attachment.html>