• Daniela
  • Brian
  • Dirk
  • Andrea
  • Gerard
  • Graeme
  • Maarten
  • Wahid
  • Philippe
  • Giacinto
  • Pepe
  • Gergely
  • Elisa
  • Markus


  • From Philippe - Inputs/experiences from earlier working groups. Felt like time wasn't well-spent, as the middleware providers sometimes ignored the WLCG reports. What will be produced, who will it be presented to, and will it be listened to? Past experience with SRMv2 especially resulted in little progress with the providers.
    • Cannot be "requirements on the market" with no follow-up.
  • From Graeme: Shares Philippe's concerns. Would help if, from the experiment point of view, what we intend to do and what interfaces we demand. If mwre doesn't comply, we won't use it.
  • Dirk: This is a WLCG working group which can clearly document the experiment strategy. This way external projects can judge the impact of a mismatch.
  • PC: It must be clear that the WLCG will do the recommendation of the TEG, regardless of what the middleware does. If the middleware is helpful, great; if not, we must not just "forget it". We can't just do "whatever the middleware workplan is".
    • ML: be careful with "requirements" - they may not materialize, you need a plan B.
    • We must also make sure the requirements materialize.
    • PC: We must make sure the WLCG drives, not an abstract community.
  • BB: Will try to find commonalities and highlight
  • PC: POOL/ROOT/PROOF - this is more about data persistency than data management. AV agrees. AV - thinks we should just have a short, clear statement and be done with it. The idea of having ROOT independence has been successful, but has been driven from the experiment requirements.
    • wrt to the previous conversation, POOL is an example where it's external to the experiments but internal to the community, and this model has been very successful.
    • Expecting to get a short statement about POOL from ATLAS/LHCb and put it in the TEG's report.

  • DD: Suggest do use bi-weekly meetings mainly for core/controversial topics, which need interactive discussion. We will need to do the bulk work via email and should structure input requests (to experiments, sites, s/w providers) with concrete questions.
  • About F2F: maybe we target for January to document the "status quo". Concerns about actually being able to provide a coherent strategy document by that time.
    • Document the status quo, document known commonalities, and "known upcoming changes".
    • Other TEGs will go definitely go beyond the February deadlines.
    • Noted that there's a massive overlap with storage management. Maybe overlap the F2F with them?
    • It is thought that security TEG will hit data security issues; how to do overlap? ML: Don't want one TEG to come up with ideas that are fairly incompatible with another TEG.
    • DD: The split between storage and data management could be used to collect the experiment data management (user side data access) and the storage service operation (sites) respectively. Suggest to meet (virtually) with storage TEG chairs to prepare split/overlap topics.
    • Will pick exact date in Jan. No interest in Dec. Amsterdam or CERN is acceptable.


  • Pick out F2F meeting times. Shooting for January and co-located with Storage.
  • Can people identify what other TEGs they sit on? Would like to make sure there are "ambassadors" to other TEGs to watch for overlaps.
  • Identify some concrete questions to ask experiments to prevent "generic needs" presentations.
  • Try and get at least CMS, and maybe ALICE, to answer questions at the next meeting.
Edit | Attach | Watch | Print version | History: r5 < r4 < r3 < r2 < r1 | Backlinks | Raw View | Raw edit | More topic actions...
Topic revision: r3 - 2011-11-04 - DirkDuellmann
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    LCG All webs login

This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2020 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback