The login issue has been resolved; logging in in possible again.

Middleware Readiness Working Group kick-off meeting

513/R-068 (CERN)



Show room on map

Dial-in numbers: +41227676000 (English-US, Main)
Access codes: 0177882 (Leader)
0143968 (Participant)
Leader site:
Participant site:

Middleware Readiness Working Group twiki HERE.

The meeting date/time is a result of this doodle.

The meeting purpose is to:
 - Evaluate successful methods of Middleware Readiness practices by selected middleware products.
 - Discuss how to better involve the experiments in this effort.
 - Find ways to reward the WLCG sites willing to participate in the testing of new middleware versions.

  1. Repository: Every Product Team (PT) uses the repository of their preference (EPEL, Maven, etc). Products should stay for sometime in a 'testing' partition before making it to the 'prod' one. If, after April 2014, the EMI repository is no longer maintained, an alternative should be discussed and a transition plan should be decided.
  2. Process: Examine the workflow used by DPM, dCache, StoRM and, if they can serve as examples, document their reasons of success.
  3. Communication: Communicate conclusions from this experience to the WLCG Ops Coord meeting.
  4. Experiments: Maximise experiment involvement in testing new versions of these products of choice. Talking to our peers, in SDC/OL, linked to the experiments, is the first step to this direction. One representative per experiment is needed, as a member, in this WG.
  5. Sites: Assist PTs to find sites willing to test new versions of their products. After establishing the first links, via a few dedicated meetings within the WG, we should smoothly agree on a 'formal' procedure. We should discuss, first within the WG, then with the experiments and the sites, how site involvement can be recognised and rewarded. Would sites be willing to:
    • have a testing infrastructure AND would the experiments agree to adjust their workflow to use it?
    • agree to upgrade their production infrastructure early? If yes, WLCG should be more tolerant to site unavailability, in case of problem, acknowledging the site's willingness to take the risk.
  6. EGI: Keep the dialog open with EGI, maybe bridge the processes used in the two communities, i.e. by making available the testing versions for sites which are both WLCG and participate in the EGI Staged Rollout. With experiments' agreement to participated in such tests, we can help to make the UMD production versions available sooner.
  7. A.O.B.


The agenda of this meeting is empty