Swich the base image to Ubuntu 22.04 LTS

[eitsupi]

Just as the release dates of R4.0.0 and Ubuntu 20.04 were only a few days apart, the release date of R4.2.0 could be right after Ubuntu 22.04.
Immediately after the release of jammy, there is a possibility that RSPM binary installation, RStudio, etc. are not compatible with jammy, so we may need to modify the build system.

https://discourse.ubuntu.com/t/jammy-jellyfish-release-schedule/23906

$ docker run --rm -it rocker/r-ver Rscript -e "read.csv('/usr/share/distro-info/ubuntu.csv') |> tail(1)"
     version        codename series    created    release        eol eol.server
36 22.04 LTS Jammy Jellyfish  jammy 2021-10-14 2022-04-21 2027-04-21 2027-04-21
      eol.esm
36 2032-04-21

[cboettig]

Yup. Usually binaries compiled on the older system ought to run on the newer ones (though maybe Dirk can correct me on that); e.g. I believe in python world they build their 'universal' binary wheels by compiling with an ancient versions of linux. So I'd think most packages would still work; though whether we want to ship any containers that install 20.04-based binaries on a 22.04 platform is another question. iirc last time RSPM had a few month lag (and then there's the question of NVIDIA libraries, which I think were some 6 mo behind the release of 20.04 or so; though maybe different this time).

Of course, 20.04 has a lot more life in it. I do think we want to stick with the rocker-versioned tradition of running with the latest stable release, but it does raise the issues of precisely when we switch, and if we continue to support 20.04-flavored images. With the new automation and new buildkit approach to tags, I imagine that is somewhat easier? Providing the same stack on multiple base distros seems pretty standard for docker projects these days. Thoughts?

[eddelbuettel]

Usually binaries compiled on the older system ought to run on the newer ones (though maybe Dirk can correct me on that)

Yes they do, almost always (more below). For example, over in PPA land Michael prepares the 5000+ r-cran-* packages in his repo on the LTS cadence, and I while I generally prefer CRAN-from-source I have one laptop where I use our lovely BSPM setup with the c2d4u PPA and it is awesome and generally works without fail. Ditto in "my" CI setup over at r-ci where a while back I flipped from bspm optional to bspm on: it also just works for every CI run as one wants it to.

There can be (rare) exceptions. When I packaged R 4.1.2 earlier in the week, the r-base-core binary from 20.04 LTS would not install on 21.04 or 21.10 because of one 'pinned' shared library it wanted in a version not around for what I was running. Sometimes you just install it from the older release; here I just punted and resubmitted the source package to be rebuilt in 21.04 and 21.10 as well as it is a) quick and b) of general interest.

Also consider how commerical apps ship. I run rstudio, slack, zoom, chrome, ... here and they all run. They tend to be 'sumo builds' with their dependencies statically linked in to avoid the above problem but it demonstrates that yes we can.

So I would suggest to be pragmatic and, dunno, maybe use the 20.04 binaries for a month or so until 22.04 will have caught up. The service you depend on here but do not pay for or have a SLA for simply is not obligated to serve you binaries on April 21 so maybe it is safer to assume (just on good engineering grounds) that you won't have them. You can always flip the switch early if they are... (I do the same for r-ci and wait til BSPM has caught up before I flip the default switch.)

[eitsupi]

Since the base image selection logic has been updated by #424, the switch to ubuntu:jammy has been postponed until the version of R that will appear in 2022-07-20 or later.

rocker-versioned2/build/make-stacks.R

Line 444 in a97bd9e

dplyr::filter(r_release_date >= ubuntu_release_date + 90) |>

[eitsupi]

Today, the base image of rocker/r-ver:devel has switched to ubuntu:jammy. (ubuntu:latest is now ubuntu:jammy)
So rocker/rstudio:devel is failing to build.

rocker-versioned2/dockerfiles/r-ver_devel.Dockerfile

Line 1 in a97bd9e

FROM ubuntu:latest

[devarops]

Hi 👋🏾

Did you decide when you are going to switch to ubuntu:latest (22.04)?
Are you going to wait 90 days or until R 4.3.0 is released?

Thanks,

[eitsupi]

@devarops Thanks for the good question.

Switch the base image to ubuntu:jammy for versions of R to be released on or after 2022-07-20 (i.e. 4.2.X).
Base images for R versions released before 2022-07-19 (i.e. 4.1.3, 4.2.0) will remain ubuntu:focal and will not switch.

The only one using ubuntu:latest for the base image is rocker/r-ver:devel, which is built daily and has already switched to Ubuntu 22.04 LTS.

[devarops]

@eitsupi Thank you for your answer.
And thank you all for your work. I really appreciate the project, and I now depend on it.

[eitsupi]

Note: RSPM seems to have started providing binaries for Ubuntu 22.04 a few days after jammy's release, and the images used in r-universe have already switched to ubuntu:jammy.
https://github.com/r-universe-org/base-image

As a side note, RSPM did not provide binaries for R4.2.0 as of the day of the R4.2.0 release, so the build in this repository was just under the 6-hour limit.

[cboettig]

yes, things seem to be moving a bit faster this time around, maybe 90 days is too conservative.

I'm watching https://gitlab.com/nvidia/container-images/cuda/-/issues/157 to see about the nvidia base images, though that branch of the stack could be dealt with as a separate case.

[eitsupi]

Thank you for checking on the cuda base image.

Note that for now the base image specify only has the ability to replace the current 20.04 with 22.04. (e.g. nvidia/cuda:11.1.1-cudnn8-devel-ubuntu22.04)
This means that if the jammy-based cuda11.1.1 image will not be published, the build will fail. (Of course, this does not affect the success or failure of other image builds.)

rocker-versioned2/build/make-stacks.R

Lines 114 to 123 in a3289e3

	.cuda_baseimage_tag <- function(ubuntu_series, other_variants = "11.1.1-cudnn8-devel") {
	ubuntu_version <- dplyr::case_when(
	ubuntu_series == "focal" ~ "20.04",
	ubuntu_series == "jammy" ~ "22.04"
	)
	image_tag <- glue::glue("nvidia/cuda:{other_variants}-ubuntu{ubuntu_version}", .na = NULL)
	return(image_tag)
	}

[eitsupi]

@cboettig It seems that cuda images only have cuda 11.7+ for ubuntu jammy.
https://hub.docker.com/r/nvidia/cuda/tags?page=1&name=22.04

Currently the version of cuda is fixed at 11.1.1 in this repository, but I am wondering if this version can be changed.

[cboettig]

Yup, I think we would want to bump up to 11.7 when we switch to Jammy.

We haven't outlined a precise policy on how we version CUDA. I don't think we want to become tied in to old toolkit versions. The situation is a bit nuanced, because generally the driver version on the host platform must be >= the version of the CUDA toolkit we pin in the docker image (see nvidia docs).

Since 20.04 release, Ubuntu packages CUDA drivers in the main repos, so host machines (cloud machines) running with the default Ubuntu repos only will have old CUDA drivers that might not run docker images with more recent cuda-toolkits. I'm not sure if that's a real concern though, I think most users tend to install more recent drivers from NVIDIA (or use derivative distros that continue to upgrade to the latest NVIDIA drivers, like PopOS!)

In a way, the limited selection in the base images makes this issue easier for us. It probably keeps things simpler if our focal-era images are cuda 11.1.1 and our jammy-era images bump to 11.7.

[cboettig]

🎉