This doesn't (yet) answer the question of why eos
was missing but we at least have working containers in my registry...
If I build the standalone CMSSW_10_6_30 from this new base image (the result is gitlab-registry.cern.ch/mccauley/cmssw-docker/cmssw_10_6_30-slc7_amd64_gcc700:2024-03-26-3de95a5
) and then build a standalone for cmssw-docker-opendata
from this image the result is here: gitlab-registry.cern.ch/mccauley/cmssw-docker-opendata/cmssw_10_6_30-slc7_amd64_gcc700:2024-03-26-d0a227a
This works in the sense that eos
is available:
$ docker run --rm -it gitlab-registry.cern.ch/mccauley/cmssw-docker-opendata/cmssw_10_6_30-slc7_amd64_gcc700:2024-03-26-d0a227a /bin/bash
Setting up CMSSW_10_6_30
CMSSW should now be available.
This is a standalone image for CMSSW_10_6_30 slc7_amd64_gcc700.
(/code/CMSSW_10_6_30/src) eos
# ---------------------------------------------------------------------------
# EOS Copyright (C) 2011-2020 CERN/Switzerland
# This program comes with ABSOLUTELY NO WARRANTY; for details type `license'.
# This is free software, and you are welcome to redistribute it
# under certain conditions; type `license' for details.
# ---------------------------------------------------------------------------
If build a new version of the cc7-cms container and run (with cvmsfs mounted) then it works. The new cc7-cms is gitlab-registry.cern.ch/mccauley/cmssw-docker/cc7-cms:2024-03-26-3de95a5
$ docker run --rm -it -v /cvmfs:/cvmfs gitlab-registry.cern.ch/mccauley/cmssw-docker/cc7-cms:2024-03-26-3de95a5 /bin/zsh
::: Setting up CMS environment (works only if /cvmfs is mounted on host) ...
::: Setting up CMS environment... [done]
[17:15:14] cmsusr@304bea85c044 /code $ eos
# ---------------------------------------------------------------------------
# EOS Copyright (C) 2011-2020 CERN/Switzerland
# This program comes with ABSOLUTELY NO WARRANTY; for details type `license'.
# This is free software, and you are welcome to redistribute it
# under certain conditions; type `license' for details.
# ---------------------------------------------------------------------------
$ docker run --rm -it -v /cvmfs:/cvmfs gitlab-registry.cern.ch/cms-cloud/cmssw-docker/slc6-cms /bin/zsh
::: Setting up CMS environment (works only if /cvmfs is mounted on host) ...
::: Setting up CMS environment... [done]
[11:21:25] cmsusr@0eafdbe7c5c5 /code $ eos
---------------------------------------------------------------------------
EOS Copyright (C) 2011 CERN/Switzerland
This program comes with ABSOLUTELY NO WARRANTY; for details type \`license'.
This is free software, and you are welcome to redistribute it
under certain conditions; type \`license' for details.
---------------------------------------------------------------------------
$ docker run --rm -it -v /cvmfs:/cvmfs gitlab-registry.cern.ch/cms-cloud/cmssw-docker/cc7-cms /bin/zsh
::: Setting up CMS environment (works only if /cvmfs is mounted on host) ...
::: Setting up CMS environment... [done]
[11:21:43] cmsusr@c88c9ad8f31f ~ $ eos zsh: command not found: eos
In CMSSW_7_6_7
where eos
works it is in /usr/bin
. It is not there for other builds.
I have built new versions of the CMSSW_10_6_30 and CMSSW_7_6_7 standalones and placed test images in my registry:
https://gitlab.cern.ch/mccauley/cmssw-docker/container_registry/
If one then builds upon these for equivalent standalones in https://gitlab.cern.ch/cms-cloud/cmssw-docker-opendata the builds fail with eos: command not found
error.
This seems to be a problem with the images in cms-cloud (which is from an older build):
$ docker run -it --rm gitlab-registry.cern.ch/cms-cloud/cmssw-docker/cmssw_10_6_30-slc7_amd64_gcc700 /bin/bash
Setting up CMSSW_10_6_30
CMSSW should now be available.
This is a standalone image for CMSSW_10_6_30 slc7_amd64_gcc700.
[11:34:12] cmsusr@c8868704491d /code/CMSSW_10_6_30/src $ eos
bash: eos: command not found
and in my registry, which has the latest changes:
$ docker run -it --rm gitlab-registry.cern.ch/mccauley/cmssw-docker/cmssw_10_6_30-slc7_amd64_gcc700 /bin/bash
Setting up CMSSW_10_6_30
CMSSW should now be available.
This is a standalone image for CMSSW_10_6_30 slc7_amd64_gcc700.
[11:40:57] cmsusr@1026473e0771 /code/CMSSW_10_6_30/src $ eos
bash: eos: command not found
For CMSSW_7_6_7 it works for the older container images in cms-cloud:
$ docker run -it --rm gitlab-registry.cern.ch/cms-cloud/cmssw-docker/cmssw_7_6_7-slc6_amd64_gcc493 /bin/bash
Setting up CMSSW_7_6_7
CMSSW should now be available.
This is a standalone image for CMSSW_7_6_7 slc6_amd64_gcc493.
(/code/CMSSW_7_6_7/src) eos
# ---------------------------------------------------------------------------
# EOS Copyright (C) 2011 CERN/Switzerland
# This program comes with ABSOLUTELY NO WARRANTY; for details type `license'.
# This is free software, and you are welcome to redistribute it
# under certain conditions; type `license' for details.
# ---------------------------------------------------------------------------
But for the latest build which is in my registry it does not:
$ docker run -it --rm gitlab-registry.cern.ch/mccauley/cmssw-docker/cmssw_7_6_7-slc6_amd64_gcc493 /bin/bash
Setting up CMSSW_7_6_7
CMSSW should now be available.
This is a standalone image for CMSSW_7_6_7 slc6_amd64_gcc493.
[11:42:58] cmsusr@7a434d69591c /code/CMSSW_7_6_7/src $ eos
bash: eos: command not found
We seem to have lost something in our new builds.
Attempting to get the slc5 releases building opened up a portal to python dependency hell
More seriously, this sounds reasonable to me. More and more things will become hard if not impossible to build. We should "lock in" our gains.
Does running CMSSW jobs rely on things that we would need to update?
I don't think so. If at some point XrootD protocols breaks, people have to work with local files.
This makes sense to me. With the increased awareness of the containers and the possibility of sharing/binding volumes, we can work around many issues (e.g. if other things appear that make git/curl etc break again) and use host instead of container for most things that could get out of sync.
Also, building new images with another CMSSW remains possible (and easier) with what you suggest.
Storing the base images with the rest in the eospublic area adds to the security.
What are the remaining risks? Does running CMSSW jobs rely on things that we would need to update? And those updates would be doable (with more and more difficulty) now, but become impossible if the number of needed fixes accumulates.
The fact is that the usability of any EDM data at the AOD and MiniAOD levels relies entirely on these containers.
Building a base image for SLC5 broke quite some time ago and SLC6 is getting more and more difficult. I would suggest we do the following:
This refers to the images that do not have a CMSSW release installed. In the future, install a minimal set of updated packages if needed, but start from those images.
I don't think there's a point trying to exercise the building of those really old distributions, it only adds to our maintenance load.
Clemens Lange (f6a86413) at 28 Feb 11:43
Unfortunately, they always delete older versions...
Clemens Lange (3de95a51) at 28 Feb 11:43
Merge branch 'zlib_1_3_1' into 'master'
... and 2 more commits
Also had to remove docker
tag from CI config.
Clemens Lange (f6a86413) at 28 Feb 11:42
Remove deprecated docker tag
Unfortunately, they always delete older versions...
Clemens Lange (afe2e1a5) at 28 Feb 11:30
Update zlib to v1.3.1
Kati Lassila-Perini (babc5b16) at 28 Feb 11:23
Thomas Mc Cauley (fdde529e) at 28 Feb 11:23
Merge branch 'standalone-entrypoint-update' into 'master'
... and 2 more commits
The sudo
commands in entrypoint-standalone.sh make the container exit when using them with apptainer/singularity (set -e
and sudo: not found
)
Those commands are needed only to make mkedanlzr
work, not otherwise. They could be made optional so that this part is skipped for rootless envs.