DAQ Software Management Plans Pengfei Ding DUNE DAQ Meeting - - PowerPoint PPT Presentation

DAQ Software Management Plans

Pengfei Ding DUNE DAQ Meeting November 4th, 2019

Outline

• How are we doing it currently?
• Source code control
• Software build and deployment
• CI/CD
• What is coming toward us?
• Migration to GitHub and spack-dev.
• What is the goal of software management?
• How can we get there?
• Brief overview of available technologies.
• Phase-0: Near-term plan before transition;
• Phase-1: Plan during transition period;
• Phase-2: Longer-term plan.

2 11/04/2019 Pengfei Ding | DAQ Software Management Plans

How are we doing it now? (I)

3 11/04/2019 Pengfei Ding | DAQ Software Management Plans

• “dune_artdaq” bundles pieces together (protodune flavored artdaq plus protodune-specific

packages: timing, wibsoft, trigger etc);

• dune_artdaq and several closely coupled packages are built with MRB and Cmake;
• Other protodune-specific packages are using different build system, and packaged into UPS

products.

How are we doing it now? (II)

• Source code repositories
• Git repos:
• Redmine (artdaq, and dune_artdaq related packages)
• GitHub (trigger related packages)
• GitLab (firmware, timing, server maintenance)
• Other repos:
• svn repo@bu.edu (protodune_wibsoft)
• Third party packages:
• Most of them are packaged as UPS products (except some hardware

drivers);

• Recently standardized the process of making DUNE-specific UPS

products (individual package no long needs to have scripts and/or Makefiles to support making UPS products).

• (contact Pengfei if you want to package a new package into a UPS

product).

4 11/04/2019 Pengfei Ding | DAQ Software Management Plans

How are we doing it now? (III)

• Continuous Integration/Deployment
• No project wide CI/CD (build dune_artdaq manually on DAQ

servers; not a bad thing since it was what suit us best during DAQ sprint when we were making a lot of developments -- in other words

• - broke a lot of things.)
• Some packages use Travis CI (travis CI is free for public repo only)
• Gitlab provides nice CI/CD feature, but currently not used.
• Recently upgraded to art3, gcc 7.3, and c++17.
• Currently running under centOS 7 (mostly 7.5, a few 7.6 & 7.7).

5 11/04/2019 Pengfei Ding | DAQ Software Management Plans

What is coming towards us?

• Fermilab’s migration to GitHub:
• No definitive timeline from Fermilab yet;
• One or two pilot projects are ongoing to validate the whole process (e.g. LArSoft):
• Repo migration;
• Issue tracking;
• Pull request/review model;
• CI/CD with Fermilab Jenkins.
• Spack-dev:
• Trying to replace: cetbuildtools, MRB, ssibuildshims.
• In technology preview stage with a “Minimal Viable Product – LArSoft edition”
• No definitive timeline yet;
• New features are currently getting into spack-dev;
• Fermilab SciSoft team promised to be only improvements over the old systems;
• Expected full expert support during transition from SciSoft.
• Completely orthogonal to the migration to GitHub.
• Not mentioned: art replacement (?) root independent art (?). These are too early to be discussed, unclear to most of

us, and up to Fermilab’s management. Potential impact to us will is expected to be small, as the transition will be handled by upstream projects: art, artdaq etc. (Diverge from SCD’s framework is an option as a last resort: 2 FTEs in artdaq team are 100% on DUNE). 6 11/04/2019 Pengfei Ding | DAQ Software Management Plans

What is the goal of software management?

• Have Github repos for those currently in Redmine and Gitlab;
• Adopt pull request/review model.
• Package level CI/CD with travis CI, Jenkins, or Gitlab CI/CD;
• Project level CI/CD with Fermilab Jenkins.
• Upgrade to spack-dev, replace MRB and UPS products.
• Support centOS 8.

7 11/04/2019 Pengfei Ding | DAQ Software Management Plans

How can we get there? – Technology overview

• GitHub:
• Unlimited private repos;
• Issue tracking;
• pull request/review;
• CI/CD with Travis CI (public repos only, limit on building time) and

Jenkins

• GitLab provides similar features as Github, but provides in-house

CI/CD and better project-wide management.

• GitHub, GitLab and Redmine can co-exist with push/pull mirrors to

each other; we do not need to choose between them.

• Travis CI, GitLab CI/CD and Jenkins can all be used for different

packages; but project-wide CI/CD will only be at Fermilab Jenkins.

8 11/04/2019 Pengfei Ding | DAQ Software Management Plans

How can we get there? – Phase 0

• GitHub repos:
• Prepare GitHub repos for all dune specific packages which are not
• n GitHub;
• Mirror their original repos (Redmine or GitLab push mirrors to

GitHub);

• New commits happen the same way as before, to Redmine or

GitLab repos;

• Redmine or GitLab pushes new commits to GitHub repos.
• CI/CD:
• Implement CI/CD for UPS packages with GitHub repo:
• docker and Travis CI
• Fermilab Jenkins.

9 11/04/2019 Pengfei Ding | DAQ Software Management Plans

Phase-0: Near-term plan before transition.

No change to workflow at this stage. Hopefully we can all agree on this phase. J

How can we get there? – Phase 1

• Repos:
• Start to reverse the mirror direction to GitHub repos;
• New commits to GitHub repos first, and pushed to Redmine/GitLab;
• Start to exercise pull review/request model.
• CI/CD:
• This is independent of the mirror direction switch;
• Implement project-wide CI/CD on Jenkins;
• It is expected to use GitHub repos from Phase 0.
• Spack-dev:
• This is independent of the repos and CI/CD plan;
• It is likely to happen during this phase only because it might be the time it is finally

available to experiments.

10 11/04/2019 Pengfei Ding | DAQ Software Management Plans

Phase-1: Plan during transition period

Changes to workflow at this stage. Discussion/suggestion is open. J

How can we get there? – Phase 2

• Start from:
• all repos on GitHub;
• project-wide CI/CD with Fermilab Jenkins based on MRB,

cetbuildtools, and ssibuildshims.

• To fully integrate with spack-dev:
• UPS package replacement with spack modules (SciSoft will be

helping with writing the recipe files);

• MRB replacement:
• Guidance will be provided by SciSoft for changing CMake rules;
• Convert certain packages to use CMake; or keep them as ”external”

packages.

• Update CI/CD in Jenkins accordingly.

11 11/04/2019 Pengfei Ding | DAQ Software Management Plans

Phase-2: Longer-term plan

Changes to workflow at this stage. Should just naturally follow through after Phase 1.

Conclusion

• The following lines of work are independent from each other:
• Move to GitHub;
• CI/CD on Jenkins;
• Move to spack-dev.
• Phase 0 has no impact to current workflow, and should start

immediately.

• Only Phase 3 is dependent on external timeline (spack-dev’s

readiness from SciSoft).

• Phase 1 (having GitHub host repos primarily) is the place where most

changes happen;

• Discussion/suggestions are hugely welcomed!
• Committed to find the best solution for our developers and DAQ
• perations.

12 11/04/2019 Pengfei Ding | DAQ Software Management Plans