Table of Contents

Task List

Prioritize this task list Make a detailed status for each of the main software package (Summary table below)
Make a very simple list of use cases: L1Proc, End user, Developer...
Summarize pros and cons of Docker vs Singularity vs Shifter (considering use cases, and what computer centers like most...)
Summarize Virtualization and Containerization status at SLAC and CC-IN2P3
Can the Release Manager create and track the VM/Containers?
Test containers at SLAC and CC-IN2P3, using the pipeline
Scaling test running many containers at SLAC, and CC-IN2P3, using the pipeline
Build a GR container, with everything and/or with a minimal runtime environment
Run a small MC production with a GR container using the pipeline
Run a small reprocessing task with a GR container using the pipeline

...

Summary

Here is summary table with the main software packages

see data flow section of the Software Week Meeting notes

created by Johan on Tuesday 6^th 2017, limiting myself to RHEL5, RHEL6 and RHEL7/CentOS7

Name	Build platform	Running platform	Special dependencies	Upgradable?	Existing VM	Existing container	Links	Comments	Date
FastCopy	RHEL5	RHEL5 or RHEL6 ?	?				FASTCopy processing chain	to be reviewed by experts	06 Jun 2017
Halfpipe	RHEL6	RHEL6	Commercial Qt !?	unlikely			Halfpipe	to be reviewed by experts	06 Jun 2017
Isoc Monitoring	RHEL5	RHEL5, works on RHEL6						to be reviewed by Steve T.	06 Jun 2017
GlastRelease	RHEL6	RHEL6	ROOT v5.34	may be with a lot of work and clean up				huge work, including science verification	06 Jun 2017
DataMonitoring	RHEL6	RHEL6	python2, numpy, ROOT	probably if GR is upgraded				svac/monitor is similar to GR, then mostly python code in dataMonitoring	06 Jun 2017
ScienceTools	RHEL7	RHEL7	RHEL7	NA	Giacomo	Sam's / Matt's		there was also one VM for the Fermi Summer school	06 Jun 2017
ASP	RHEL7	RHEL7	RHEL7	NA				should be similar to ScienceTools, ask Jim	06 Jun 2017

...

a few technologies to consider Docker, Shifter (Nersk for HPC) and Singularity
advantages over a full VM usually are:
- light weight
- better performance
- container has to be carefully built
Docker: the container
Shifter: NERSC container optimized for HPC
Singularity: containers for scientist, compatible with Docker

What is different for developers/users?
Same image for all the GR uses.
Don't want to pull a 3GB image to pull FT1, GR is 3x bigger. Just have 1 image at the moment.
One giant image - good command line interface installed in that image.
Images built such that the top looks the same between GR and ST. Keep same image.
Separate builds for debugging purposes?
GlastRelease is frozen, ST is constantly evolving. Debugging GR is not a problem, debugging ST is important
Giacomo
- Mount code at runtime, container doesn't have debugging tools.
- Container provides environment.
- Compile inside the container.
- run debugger inside container.
- User image has everything - compiled.
Lightweight container for developers then they can compile. Users have full compiled.
Debugging in GR and ST is very different
The computing center will have a cache of docker.
Every project will say what docker images do you want on the batch nodes?
Plan for managing cashed images. Work out allocations for collaborations.
Cost of using docker?

...

...

Release manager doesn't talk to Oracle - but it does talk to a database. Not user friendly.
Can our Release Manager build containers? (Richard)
What is different for developers/users?
Same image for all the GR uses.
Don't want to pull a 3GB image to pull FT1, GR is 3x bigger. Just have 1 image at the moment.
One giant image - good command line interface installed in that image.
Images built such that the top looks the same between GR and ST. Keep same image.
Separate builds for debugging purposes?
GlastRelease is frozen, ST is constantly evolving. Debugging GR is not a problem, debugging ST is important
Giacomo
- Mount code at runtime, container doesn't have debugging tools.
- Container provides environment.
- Compile inside the container.
- run debugger inside container.
- User image has everything - compiled.
Lightweight container for developers then they can compile. Users have full compiled.
Debugging in GR and ST is very different
The computing center will have a cache of docker.
Every project will say what docker images do you want on the batch nodes?
Plan for managing cashed images. Work out allocations for collaborations.
Cost of using docker?
- our Release Manager based on Jenkins (here)
- Jenkins has plenty of plugins to facilitate building and testing of Docker containers
  - One plugin
  - Tutorial on how to build container with Jenkins (itself running from a container...)
- Johan: May be just crosscheck with Joanne B. and Max T. , but it should be straightforward

Needs someone that he could show the pipeline code and train to do heavy lifting when it comes to kicking the pipeline
Docker containers for something like the batch system may cause some problems, since
For something like the L1 pipeline, a number of images would need to be launched simultaneously
Would size of the software cause problems with deployment?
We would need a system where you restrict loading images to the batch farm to prevent collisions/problems
There is probably a precedent for this, however, Matt has no experience deploying on this scale
File size of ~1 GB is best, a few is manageable for production.
IT dept supportive of docker@SLAC. There is 1 machine with RHEL7
Lyon is a much larger computing center - likely they will upgrade to Docker first
- Now full support for Docker at Lyon (Fred)
  Joris : Lyon wants to use Singularity because they have security issues with UGE + Docker.

...