Docker Images Meeting Minutes

[drdanz]

We had a small internal meeting discussing the future for docker images for yarp/robotology-superbuild, etc., and we defined a few action points.

• Remove yarp-gazebo e yarp-tdd
• Remove yarp/git, keeping yarp/bin only (bin subfolder should be removed)
• Move here YCM images (all supported cmake combination should be created)
• Update yarp:bin su ubuntu:focal
• Update icub:bin based in yarp:bin (should be ok)
• Update yarp image to use YCM from the image created
• Rename robotology-tdd to robotology-superbuild update dependencies and CMake options. Also compare with images developed by icub-tech
• Develop a docker-compose.yml file to build without makefile
• Update CI to use the docker-compose.yml file
• Update CI to push to GitHub registry instead of Dockerhub. Images for each repositories should be connected to the corresponding repository.
• Check if CI from this repo is able to push on other repositories
• Move this repo to robotology and rename to docker-images
• Understand how to handle the Nvidia/mesa drivers, and if we still need to do extra things to do
• Investigate rocker
• Investigate opencontainers and decide which labels should be used
• Investigate how to handle users and groups (for source files, DBus, runtime directory)

[traversaro]

cc @vtikha

[traversaro]

Rename robotology-tdd to robotology-superbuild update dependencies and CMake options. Also compare with images developed by icub-tech

Just to understand, do you think that is an advantage for maintaining this image outside of the robotology-superbuild? I was thinking that we could move it in the robotology-superbuild repo so we that when a new option is added in the robotology-superbuild, it is directly added also in the Docker image, but I do not know if I missing something.

[diegoferigo]

Just to understand, do you think that is an advantage for maintaining this image outside of the robotology-superbuild? I was thinking that we could move it in the robotology-superbuild repo so we that when a new option is added in the robotology-superbuild, it is directly added also in the Docker image, but I do not know if I missing something.

We discussed this point also regarding the yarp image, so I think we can extend the scope of your question to a more generic: where should we store the images officially supported?

The options are:

1. A centralized repo (e.g. this one)
2. Spread among repositories (yarp, robotology-superbuild, icub-main, ...)

Both options have pros and cons. One of the pros of the second option what you pointed out.

In my opinion, having a single repo helps finding and consuming the images from downstream users, and it centralizes knowledge, infrastructure (e.g. actions for CI/CD), and docker-related ticketing. Having some experience with osrf/docker_images, I think this a reasonable approach. Try to think how to deal with all the tooling of that repo if the images are spread in ROS / ROS2 / Gazebo / ... repos. It's just simpler for users to know a single place to look for if they need to find the Dockerfiles.

Another topic discussed with @drdanz is where to push the images. We thought that using the github registry would be a valid alternative to dockerhub, and we left a comment to verify how to push images from this repo to, e.g., the yarp repo. Another option, if we decide to go towards 1, is to deploy them all in the centralized repo as well. I fear that a too fragmented docker situation would complicate things and create confusions.