[Discussion] Docker images tags

[sgermanserrano]

New Feature

There is no alignment in the tags used for docker images in autoware/autoware and autoware/build.

PR autowarefoundation/autoware#1946 will allow to build images in autoware/autoware automatically with the following tag structure (#1938):

image name	purpose
XXX-kinetic-base	Environment without CUDA support for release XXX
XXX-kinetic-base-cuda	Environment with CUDA support for release XXX
XXX-kinetic-cuda	Autoware built with CUDA support for release XXX
latest-kinetic-base	Matches the newest XXX-kinetic-base
latest-kinetic-base-cuda	Matches the newest XXX-kinetic-base-cuda
latest-kinetic-cuda	Matches the newest XXX-kinetic-cuda
XXX-kinetic-base-rc	Environment without CUDA support for pre-release XXX
XXX-kinetic-base-cuda-rc	Environment with CUDA support for pre-release XXX
XXX-kinetic-cuda-rc	Autoware built with CUDA support for pre-release XXX

To be consistent, for new images built in autoware/build the following tag structure is proposed:

image name	purpose
XXX-driveworks-kinetic	driveworks image for release XXX
XXX-synquacer-kinetic	synquacer image for release XXX
XXX-generic-aarch64-kinetic	generic-aarch64 image for release XXX
latest-driveworks-kinetic	Matches the newest XXX-driveworks-kinetic
latest-synquacer-kinetic	Matches the newest XXX-synquacer-kinetic
latest-generic-aarch64-kinetic	Matches the newest XXX-generic-aarch64-kinetic
devel-generic-aarch64-kinetic	Used for CI to incorporate new dependencies

[amc-nu]

@sgermanserrano Thanks for creating the issue.
Also thanks for your hard work @filiperinaldi

Regarding the naming, what do you think about:

1. Adding repositories in docker hub for each architecture, (i.e. autoware/x64, autoware/arm64, etc.)
2. Use the names to describe the ros version and image type
3. Finally use the tags to refer the versions.

For instance, following the same tag naming from above:

repository	name	tag
autoware/x64	kinetic-cuda	latest
autoware/generic-aarch64	kinetic-base-cuda	v1.10
autoware/synquacer	kinetic-base	v1.11
autoware/px2	kinetic-driveworks	latest

to suggest a few.

[filiperinaldi]

Hi,

We don't need to add the CPU architecture to the name because Docker manifest already has a mechanism to deal with that. It is my understanding you can have a single image name, but actually multiple builds (one for each arch).

My suggestion is that we only create more images for very specific platforms that require extra support. Otherwise, this may be the minimal required to begin with:

Name	archs	Supports
autoware-base	amd64, arm64	Base image [1]
autoware-base-cuda	amd64, [2]	Base image with Cuda support
autoware	amd64, arm64	Autoware build [1]
autoware-cuda	amd64, [2]	Autoware build with Cuda

[1] I'm assuming the Synquacer would run a generic AArch64 docker image. @sgermanserrano, is that a correct assumption?

[2] If Driveworks SDK allows native build and is generic enough (and depending on the arrangement between Autoware and NVIDIA) perhaps we could simply include driverworks SDK on the autoware-base-cuda and autoware-cuda builds for arm64.

Note: When you want to explicitly fetch an image for a specific arch, you can prefix the image name, like this: armv8a/autoware:kinetic-base.

[sgermanserrano]

Putting everything together:
Image name and tags are combined in dockerhub so to pull:
docker pull autoware/amd64:latest-kinetic-cuda
docker pull autoware/arm64v8:1.10.0-kinetic-cuda

To keep in line with the naming in https://github.com/docker-library/official-images#multiple-architectures:

Owner	Dockerhub repository	Image tag
autoware	amd64	XXX-kinetic-base(-rc) / latest-kinetic-base XXX-kinetic-base-cuda(-rc) / latest-kinetic-base-cuda XXX-kinetic-cuda(-rc) / latest-kinetic-cuda
autoware	arm64v8	XXX-kinetic-base / latest-kinetic-base XXX-kinetic-base-cuda / latest-kinetic-base-cuda (for PX2) devel-kinetic-base (for CI purposes)