https://fnal.zoom.us/j/99831208930 standard pw
Wiki page with instructions: https://github.com/DUNE-DAQ/oksconfgen/wiki/Setting-up-a-dunedaq-v5.0.0-Development-Area
Have a test system running on one host, with trigger (RandomTriggerCandidateMaker), dfo, 3 df apps (1 writer each), 3 readout apps (2 links in first, 1 link in each of the others).
-> Might be good to run on more than one host (via boot.json)
-> Haven't tried running smaller system than is configured (good check for enabled/disabled status)
No ERS messages in dashboard because of older configuration style. appdal/test/boot.json
Gordon has an enable script in oksconfgen to try
Integrationtests will need new pytest plugin, since the current one is very daqconf/nanorc-focused; we will probably need a new oks/drunc one. Static configurations for starters, though it would be good to factorize as much as possible so that each integration test defines as little as possible to customize the config for the test.
Look into how the integrationtest plugins are structured so that it can coexist with other pytest environments?
Toggle on command-line? Diana also working on this kind of thing.
Alessandro: We should be selective about the packages used in our initial engineering release. If something gets in the way, we should not build it.
What is the minidaq? Do we go for full readout of things like hsi interface and hermesmodules/wibmod?
What is the target date for v5.0.0? Probably a good idea to wait for the v4.3.0 cycle to complete to not interfere with EHN1 operations. Hardware availability becomes important if we are aiming for real readout.
Pinning file? Baseline could be to just let NanoRC manage it, but it would be nice to have the run control reading configuration from OKS and applying pinning. We don't have a model yet for how to represent this in the config.
Review structure of schemas and database files. We want to make sure that we have configuration objects clearly identified and are applying configurations in a sensible way. (Maybe not a v5.0 deliverable)
-> Make sure that separation of schemas into files makes sense (e.g. no ND/FD combinations), but try to avoid duplication or convergent evolution of defined schema objects.
Drunc may also be a part of v5.0.0 if available.
v5.0.0 tentatively end of Feb./beginning of March (but it can be moved if necessary).
-> Will basically be a tag of a nightly, no real release integration is needed for initial release
Start initial discussion on pinning in parallel to other developments. Try to define the issue.
Alessandro reports on some issues with the current configuration system and how some tables may not be strictly necessary. Candidate changes on branches which could help show a way forward. Connection objects are not well-facortized so may be unexpected effects.