Hi all,
CERNVM4 which is the latest version on the download page, comes with HTCondor 8.8.13 which can’t be updated in a running VM due to cernvm-system depending on the installed version.
On the other hand, version 8.8.13 of HTCondor does not support tokens which are already needed for some experiments now.
Would it be possible to release a new CERNVM version using HTCondor in version 10?
Cheers,
Marcus
Hi Marcus,
there is indeed a new version of CernVM in development and should available in production soon (= during the summer). CernVM 5 focuses more on containers though, and will no longer pin the package versions the same way as CernVM 4 does - see this presentation for more details.
It might be possible to update HTCondor in CernVM 4 though. Let me discuss this internally and get back to you.
Thanks Valentin!
Do you have by chance already an update on the possibility to have an alternative CENRVM4 version with a V10 HTcondor installed?
DUNE already stopped the use of X509 for job submission and uses scitokens only. This stopped us from running DUNE jobs for now. It would be greatly appreciated to have a CERNVM version (4) with an updated HTCondor instead of creating and providing own images for the clouds we run jobs on.
Cheers,
Marcus
Hi Marcus,
yes, we will be able to update CernVM 4 and should be able to release this week. If there are any other packages you would like to see updated, let us know.
Hi Valentin,
Great! The only other packages that could be updated is the shoal-client. We will put a new version by Thursday (PDT) out.
One more technical question: The updated CERNVM version will have a new version number and a new image to be downloaded, right? Or in other words, continuing with the current image will still allow to use the HTCondor 8.8 in the future?
It’s a transition time now, some experiments already switched to use only scitokens (DUNE) while for others we still need to support X509 (Belle-II, ATLAS).
Cheers,
Marcus
Hi Marcus,
yes exactly, the update of existing CernVM instances needs the custom
sudo cernvm-update -a
command followed by a reboot. Otherwise existing instances will not be affected.
For shoal-client this would be v1.04 (Release shoal-client-1.0.4 · hep-gc/shoal · GitHub)?
We still need to fix some packaging conflicts for htcondor, but will release as soon as that is resolved.
Cheers,
Valentin
Hi Valentin,
Sorry for the misunderstanding. What I mean is that we need to boot for some experiments also in the future new VMs that still use the old HTCondor 8.8. That’s mainly for Belle-II and ATLAS. Only DUNE has X509 deactivated and switched to use only scitokens.
So we would need to boot up in the future some VMs using the old system and some using the new updated one, in parallel until all experiments switched to use tokens.
So if we boot a new VM in the future using the current cernvm4-micro-2021.05-1.hdd, will we always get an HTCondor 8.8 then? The new version will be something like cernvm4-micro-2023.06-1.hdd and gives only HTCondor 10.x ?
Cheers,
Marcus
Hi Marcus,
oh I see - yes, that is indeed the case, you can still get older versions by using the corresponding older images, those are not going to change.
Cheers,
Valentin
Perfect! 
Cheers,
Marcus
Hi Marcus,
there is an updated CernVM version v4.6.2.0 available in our testing repositories. The update includes new versions of system packages, the latest shoal-client, java-11-openjdk and htcondor 10.
The testing images can be downloaded at Directory Tree , selecting the “ucernvm-v4testing.*” ones, like https://cernvm.cern.ch/releases/ucernvm-v4testing.2021.05-1.cernvm.x86_64.iso
Booting a new one will automatically use the latest CernVM version v4.6.2.0 unless you change the boot parameters.
If you have the chance, please try out one of the testing images and let us know if this works for you, we’ll then proceed to publish this into production.
Cheers,
Valentin
Small correction here; this image will actually stay the same, as this only refers to the kernel and bootloader, which will stay unchanged. The version of CernVM (the pinned system packages) can be selected in the boot options (in virtualbox hit tab on the “Welcome to uCernVM” boot screen), changing
cvmfs_repository_tag=HEAD4
to
cvmfs_repository_tag=cernvm-system-4.5.6.0
EDIT: this parameter can also be overridden during contextualization with the cernvm-launch command
Hi Valentin,
So this would give the old system while
would give the new system and can already be used with the old image?
Cheers,
Marcus
It seems
is no longer available? Also, to test could you please provide a raw image instead of an iso?
Thanks,
Marcus
Hi Marcus,
hmmm, apologies, that link was still working at the time, looks like a server error, I’ll look into it! The older version https://cernvm.cern.ch/releases/ucernvm-images.2021.03-1.cernvm.x86_64/ucernvm-v4testing.2021.03-1.cernvm.x86_64.hdd seems to be still available, I think that should be ok for testing too.
Yes, you can browse the directory tree to find all the different formats:
https://cernvm.cern.ch/releases/ucernvm-images.2021.03-1.cernvm.x86_64/
Yes, it seem there were temporary server issues for the download. After a few tries, I could get
ucernvm-v4testing.2021.05-1.cernvm.x86_64.hdd
This seems to work fine so far! ( I still have to figure out how the security between worker node and server works for the new HTCondor, but the system itself seems to run okay.)
When using the old image
cernvm4-micro-2021.05-1.hdd,
do we already need to specify
cvmfs_repository_tag=cernvm-system-4.5.6.0
to get the system with the old HTCondor version?
Cheers,
Marcus
OK, good to hear. No, cernvm-system-4.6.2.0 with the updated HTCondor is currently only in our testing repositories, so the production images will still have the old version. We can push this to the production repositories whenever you want, just give me the confirmation.