-
Notifications
You must be signed in to change notification settings - Fork 2k
Split cuda image into cuda-runtime and cuda-devel #14
Conversation
So, you'd want to make a separate repository for cuda-devel vs cuda-runtime?
Keep in mind where you'd want to attach the |
I don't want to commit to a particular layout or tag strategy for the Docker Hub just yet. If we had done so already we will be in even more trouble right now since we are changing everything. I expect this will happen again one or multiple times. |
Here is a potential layout
|
Well, either way @flx42 , the number of leaf folders made is the same: 2x3=3x2. I'm just thinking you may want to structure by os->v#->app. Its common to see most tag structures set version number as the prefix, and instance specifics as the postfix. You could play around with other tag conventions, but it could get a little verbose. Can't hurt to have the folder tree structure mimic the branching tag hierarchy. Playing devils advocate, @3XX0, what would be some cases for the opposite (for a cuDNN repo)? |
I was following our package convention (i.e cuda-X-version) but either way is fine. |
@3XX0 , what you've described looks great, I am in agreement. I like the flexibility offered to users by making both a runtime and devel version of cuDNN, and the pattern of tag aliases is very clear. It's ok it have a good amount of tags, as the build process is automated, maintenance is quite low once we get it down, and it lets users a pick what the need. Just looked through b45091a and it LGTM! One suggestion is that perhaps you'd want to create a simple Makefile to build, tag, pull, rm all the growing number of tags, like this Makefile. They are quite simple, and users can quickly mod it as needed. Oh, and @flx42 , as long as your touching every Dockerfile, you might want to reorder the packages in the |
@3XX0 , if you updated those links point to their respective Dockerfiles, I believe that bullet markdown list would be a useful addition to the beginning of this repo's README.md. |
Yes, we're going to update all the documentation fairly soon. |
I think if you make that repo automated, you could have it render documentation on the docker-repo page using the README.md from the git-repo. See Understand the build process. |
That's a great Makefile , I think I might mimic it :D |
Fixes: #12
Submitting this one for review by @3XX0 and @ruffsl since it touches almost every file in the repository.
Now we have two flavors of each CUDA toolkit: cuda-runtime and cuda-devel.
For convenience, this image should be tagged cuda by users. This image doesn't include documentation, samples and visual tools; thus the image is still significantly smaller than the previous cuda image.
Here are the size of the images right now: