[ROS2] Replace r2b3 with ardent

[mikaelarguedas]

We should update the manifest and regenerate the docker files now that Ardent has been released.
We'll also need to update the source docker file and add the new dependencies (https://github.com/osrf/docker_images/compare/testing_ardent_binaries#diff-611c8dba035afebd27cbc82b2b788f49)

[ruffsl]

What tags would we like to provide? What arch are supported?
Does this manifest entry like so look good, similar to the previous r2b3, or perhaps something else?

release_names:
    ardent:
        eol:
        os_names:
            ubuntu:
                os_code_names:
                    xenial:
                        <<: *DEFAULT
                        archs:
                            - amd64
                            - arm32v7
                            - arm64v8
                        tag_names:
                            ros2-core:
                                aliases:
                                    - "$release_name-core"
                                    - "$release_name"
                                    - latest
                            ros2-ros1-bridge:
                                aliases:
                                    - "$release_name-ros1-bridge"

[mikaelarguedas]

Thanks @ruffsl ! I'm actually planning on opening a PR for this I just opened the issue as a self-reminder.

I'm considering a few other tags, as there have been several new packages since the last release so the current tagging may not be relevant anymore (e.g. with the current tagging rviz will not be installed in either of the images). I'll open a PR to update the manifest and the dependencies for the source image.

Regarding the architectures, we currently build packages only for amd64 and arm64

[mikaelarguedas]

@ruffsl I also saw that the r2b2 images are still hosted on Dockerhub, is it on purpose or is it safe to take them down ?

[ruffsl]

@ruffsl I also saw that the r2b2 images are still hosted on Dockerhub, is it on purpose or is it safe to take them down ?

I'm fine taking them down. Might want to wait on manually deleting them from the automated repo until Ardent is uploaded to replace it incase someone was using them prior. We'd then have something to redirect them to use.

On that note of distribution, when we do have a better idea of what tags we'd like to provide, we could start building a PR to push upstream to begin an official docker repo for ROS2, enabling multiarch images.

I'm considering a few other tags, as there have been several new packages since the last release so the current tagging may not be relevant anymore (e.g. with the current tagging rviz will not be installed in either of the images).

Was a concise reached around meta-packages for user install, or it that still review? If so would it make sense to repeat the tag/meta-package mirroring as with ROS1? For another template detail, is the ROS1 sources.list entry needed at all for ROS2 install and miscellaneous supporting tooling (omitting the ros1_bridge of course), or are some dependencies still distributed through it?

[mikaelarguedas]

I'm fine taking them down. Might want to wait on manually deleting them from the automated repo until Ardent is uploaded to replace it incase someone was using them prior. We'd then have something to redirect them to use.

👍 I was thinking or removing r2b2 and wait a bit to remove r2b3

On that note of distribution, when we do have a better idea of what tags we'd like to provide, we could start building a PR to push upstream to begin an official docker repo for ROS2, enabling multiarch images.

As this is still not something we officially support or is part of our release process I won't target this for now. We can revisit by B-turtle.
On that note, do you know how we can request rebuilds on the official repo for ROS? it looks like some images are several syncs behind (copied question from https://discourse.ros.org/t/announcing-ros-docker-images-for-arm-and-debian/2467/12)

Was a concise reached around meta-packages for user install, or it that still review? If so would it make sense to repeat the tag/meta-package mirroring as with ROS1?

right now we haven't defined what the ros2 meta-packages will be. So for now we only have an ament package for common_interfaces but it doesnt have the magic of meta-packages its just a regular ament package without code.

For another template detail, is the ROS1 sources.list entry needed at all for ROS2 install and miscellaneous supporting tooling (omitting the ros1_bridge of course), or are some dependencies still distributed through it?

I think the python package like python3-vcstool come from the ROS apt repo. I'll need to check in more details exactly what packages come from it before considering removing it (in the case of vcstool it could be install from elsewhere, e.g. pip). But yeah the ros1-bridge needs it

[ruffsl]

Thanks for the update.

On that note, do you know how we can request rebuilds on the official repo for ROS?

Like I've responded on discourse, I've mainly just contacted the library maintainers directly. They are rather quick on triggering a rebuild internally, as no PR audit is required, and the rest of the test and release backend is automated on their side. I've made a request here: docker-library/official-images#3890

[mikaelarguedas]

Thanks, and thanks for having waited for the sync of all distros to happen before requesting the rebuild 🥇 👍

[mikaelarguedas]

I see that there is still jade listed in the images targeted for rebuild. Can you remind me what are the steps to decommission EOL distros? I remember us settling on not rebuilding images as soon as a distro goes EOL

[ruffsl]

Can you remind me what are the steps to decommission EOL distros?

I think the simplest option would be to remove the tag_names entries such that they would no longer appear within docker library manifest, much like with the legacy distros currently.

docker_images/ros/manifest.yaml

Lines 136 to 152 in 4cfa1c7

	ros-core:
	aliases:
	- "$release_name-ros-core"
	- "$release_name-ros-core-$os_code_name"
	ros-base:
	aliases:
	- "$release_name-ros-base"
	- "$release_name-ros-base-$os_code_name"
	- "$release_name"
	robot:
	aliases:
	- "$release_name-robot"
	- "$release_name-robot-$os_code_name"
	perception:
	aliases:
	- "$release_name-perception"
	- "$release_name-perception-$os_code_name"

With their absence made in the manifest and PR'ed upstream, the Docker Hub library should stop provisioning any jobs that would update or test the deprecated tags. I think the Docker Hub Doc readme will also auto-updated to omit the deprecated tags to reflect this, but the images themselves should still persist in the registry as last modified.

[mikaelarguedas]

Thanks @ruffsl for the tip, #109 should address this