Open mikaelarguedas opened 4 years ago
Similarly to how we provide a osrf/ros2:devel image for ROS 2, we could consider providing a set of devel images for ROS 1.
Think similarly using a separate repo, e.g. osrf/ros1
to host more exotic tags would be best, as not to convolute the general osrf/ros
docker repo.
@mikaelarguedas have you seen the ros:noetic-ros-base
image? What does it contain that is too much in your opinion? There is also ros:noetic-ros-core
which is even smaller`.
Think similarly using a separate repo, e.g. osrf/ros1 to host more exotic tags would be best, as not to convolute the general osrf/ros docker repo.
Fair enough, although naming it ros1
may be misleading, it's already confusing that there are the ones on the official library and the ones in the osrf profile.
Maybe something like ros1-dev
or something like that ?
mikaelarguedas have you seen the ros:noetic-ros-base image? What does it contain that is too much in your opinion? There is also ros:noetic-ros-core which is even smaller`.
In general even ros_core
comes with a lot of stuff. It was trimmed a bit recently but there is still a significant set of dependencies that one does not need for building packages, e.g. the rosbash commandline tools, all language message generators, or all the common_msgs. Many people will need a subset, but they would(/should) define what they need in their package.xml.
You can think of this as an environment to build ROS packages but without any ROS package installed in it: you install and build what you need and nothing else
Fair enough, although naming it ros1 may be misleading, it's already confusing that there are the ones on the official library and the ones in the osrf profile. Maybe something like ros1-dev or something like that ?
I think keeping with the precedent we've started with osrf/ros2:devel
would make osrf/ros1:devel
more obvious. The library/ros
and osrf/ros
repos should be reserved for releases specific tags. Although, if there were to be library/ros:<distro>-devel
, that may placate the desire for CI/development images with only minimal packages installed. Although we then wouldn't be able to rebuild them every day like we do with osrf/ros2:devel
, so perhaps that would be a cause for keeping them under our the org, e.g osrf/ros:<distro>-devel
.
Would we want the devel
related tags to be rebuilt everyday, so they get patches to rosdep, colcon, catkin, vcs, etc quickly, or should they be thought as any other installed debian package.
Also, with no more ROS1 releases, would there still be a need for a generic osrf/ros1:devel
like we have with osrf/ros2:devel
and osrf/ros2:nightly
, rather than say just a osrf/ros:noedic-devel
?
I dont think we want them to be in the library because we'd want to modify or rebuild as we see fit.
osrf/ros2:devel
is on ros2 mostly because we had a ros2 profile already that was used for hosting the ros2 distro images before moving them to the official lib + the osrf/ros repo. So it was not much of a choice but more of a consequence of what was already there.
As the naming got confusing since ROS 2 images got moved to the ros repo. I'm thinking this can be a good opportunity to revisit where to store the existing developement images currently on osrf/ros2
and if having one single repo for all dev images (ros1 and ros2) that has dev
in the name could help disambiguate.
Would we want the devel related tags to be rebuilt everyday, so they get patches to rosdep, colcon, catkin, vcs, etc quickly, or should they be thought as any other installed debian package.
I was thinking the former although there is a lot less activity on the ROS1 tools so the impact would be smaller. Maybe we could use an approach similar to the one envisioned in https://github.com/osrf/docker_images/issues/376 and trigger rebuild if we detect that the hash of any of these installed packages has changed. Remotely related: I think these should setup the ros2-testing repo by default and not the ros2 (main) one.
Also, with no more ROS1 releases, would there still be a need for a generic osrf/ros1:devel like we have with osrf/ros2:devel and osrf/ros2:nightly, rather than say just a osrf/ros:noedic-devel?
I think there would still be a need to be able to run CI on an array of ROS Distro and OSes. Supporting melodic CI is also an important thing IMO, kinetic is getting close to EOL but ci is still a good thing to have and wouldnt cost much to support as well.. As active ROS distros dont have overlapping OSes anymore, we could afford to have less verbose names:
ros1:devel-bionic # same as ros:melodic-devel-bionic
ros1:devel-stretch # same as ros:melodic-devel-stretch
ros1:devel-focal # same as ros:noetic-devel-focal
ros1:devel-buster # same as ros:noetic-devel-buster
or something of the sort:
ros-dev:ros1-devel-focal # used for noetic testing
ros-dev:ros2-devel-focal # used for any ROS2 focal based distro (Foxy, G-turtle)
...
osrf/ros2:devel is on ros2 mostly because we had a ros2 profile already that was used for hosting the ros2 distro images before moving them to the official lib + the osrf/ros repo. So it was not much of a choice but more of a consequence of what was already there. As the naming got confusing since ROS 2 images got moved to the ros repo.
While some of that was the case, I've been hesitant to add anymore tags to the osrf/ros
repo that do not equate to respective Debian meta packages. For experimental and development images, I've always tried to keep this distinction by placing them in an explicit ros2 repo.
Remotely related: I think these should setup the ros2-testing repo by default and not the ros2 (main) one.
Is that something we should retrofit with the existing ros2 dev tags, and similarly do for ros1 dev tags? Are there any potential cons you can think of?
As active ROS distros dont have overlapping OSes anymore, we could afford to have less verbose names
I think keeping with the existing pattern would lend it to be more interchangeable with existing tags, e.g. if someone was using ARGs to programmatically switch between library/ros:melodic-ros-base-bionic
osrf/ros1:melodic-devel-bionic
.
...
FROM $REPO:$ROS_DISTRO-$META-$OS_DISTRO
I've been hesitant to add anymore tags to the osrf/ros repo that do not equate to respective Debian meta packages. For experimental and development images, I've always tried to keep this distinction by placing them in an explicit ros2 repo.
couldn't agree more, I'm just suggesting that, now that all the Debian metapackages matching images are all on the osrf/ros
repo, that we place all the experimental / dev images on a ros-version-agnostic osrf/ros-dev
repo and remove the now unnecessary distinction between 1 and 2.
Is that something we should retrofit with the existing ros2 dev tags, and similarly do for ros1 dev tags? Are there any potential cons you can think of?
I think we should. No cons off the top of my head. I'm actually surprised because I thought we were using that repo already... Apparently we use it in the nightly images but not the devel ones: https://github.com/osrf/docker_images/blob/9c602bcbeaebe2049dbb47e10e29f16d88466f02/ros2/nightly/nightly/Dockerfile#L27
think keeping with the existing pattern would lend it to be more interchangeable with existing tags, e.g. if someone was using ARGs to programmatically switch between library/ros:melodic-ros-base-bionic osrf/ros1:melodic-devel-bionic.
That makes sense to me :+1:
Would we do the same for ROS 2 ? If so we'll end up creating new duplicated/aliased images:
osrf/ros-dev:dashing-devel-bionic
and osrf/ros-dev:eloquent-devel-bionic
that would be identical under the hood?.
that we place all the experimental / dev images on a ros-version-agnostic osrf/ros-dev repo and remove the now unnecessary distinction between 1 and 2.
But we don't have ros1 equivalents to nightly
. It may be fine to move distro specific tags to a ros-devel
distro agnostic repo, but having a 1 vs 2 repo separation still has a place for distro agnostic tags like nightly
. I think making the distinction via the repo name rather than the tag name is fine for 1 vs 2 as the tags are not as interchangeable given the difference in development environments.
Would we do the same for ROS 2 ? If so we'll end up creating new duplicated/aliased images: osrf/ros-dev:dashing-devel-bionic and osrf/ros-dev:eloquent-devel-bionic that would be identical under the hood?.
Duplicate tags for one image are not hard to make or use, but they are a bit harder to manage in the registry, as it may necessitate fancy post build hooks for Dockerhub to tag/push an image more than once. Not sure how to best integrate that at present.
With the migration of ROS2 to Ubuntu jammy, we'll soon have a scenario where there will be no accompanying ROS1 distro targeting the same OS as the latest ROS2 distro. Would it be worth while to revisit this to provide a simple containerized method of source building ROS1 for say maintaining a ros1 bridge?
It's not uncommon to see people writing their own image from scratch because the ROS images bring in too many dependencies.
While the ROS docker images are thought of as "for deployment" there is a strong use case for CI systems or environments for building packages.
Similarly to how we provide a osrf/ros2:devel image for ROS 2, we could consider providing a set of devel images for ROS 1. These images would :