Minutes of the EMI data PT lead Meeting, July 1, 2010

Review of the EMI-data Harmonization and Evolution document for DNA 1.3.1

• Review of the harmonization and evolution input for DNA 1.3.1. We'll wait for the feedback from Morris and Balazs.
• Comment : In the meantime Balazc replied. We need to provide an explanation why we don't want to reduce the number of storage elements. I did that already.

Preparation of the DJRA 1.2.1 TOC

The TOC of the DJRA 1.2.1 has been sent around including the input from all components and middle-wares. The document already includes "State of the Art".

• Patrick will add "dCache state of the Art" later.
• All : Please have a look at the TOC if this is ok with all of you.

Creating common workarea and defining timelines for those

We have identified 5 common areas of work. A common area is a task which requires at least 2 PTs working together. We agreed to create working groups which might decide on their leader and how they collaborate. Groups may (or even have to) include non EMI groups members.

The areas and the proposed Group members and status of the Group :

Group Name	Status	Coordinator	Members
Catalogue Synchronization	To be created	N.A.	Jean Philippe, Paul, Riccardo
GLUE 2.0	To be created	Oliver	Oliver, Riccardo, Paul
NFS 4.1	Exists	Patrick	Oliver, Jean-Philippe, Ricardo, Tigran, Patrick, Maarten, Andrea(CERN), Yves, Martin(DESY)
SRM-GSI	To be created	N.A.	Jean-Philippe, Paul, Timur, Alex Sim(BESTMAN), Guiseppe(CASTOR)
SRM spec clean up	To be created	N.A.	Jean-Philippe, Timur, Alex Sim(BESTMAN), Guiseppe(CASTOR), Jens Jensen(gridpp)

We have to provide some reasonable goals and timelines for the first 12 months of the project for individual PT projects as well as for "Common Area" in the DJRA document. I already got the plans from all PT's, however timelines for the the individual PTs are not clear in all cases. I'll send my guess around and ask for input from the PTs. On the "Common Areas" we discussed the following timelines :

Catalogue Synchronization

Design must be ready in month 6. There has been a disagreement on whether prototypes are the right way to go. It was argued thay they tend to end up being the final production version. I personally prefer prototypes as they prove design flaws in an early stage. We leave it to the "Catalogue Sync" group and the involved PTs to have people working on prototypes to prove the design to be ok. We expect a running version within the first 12 months.

Glue 2.0

We are following a two step approach in Glue 2.0 area. We will start publishing the GLUE 1.3 information using the GLUE 2.0 schema and in the second step gradually adding all Glue 2.0 information. The first step is expected to be available month-6. The entire process should be finalized before month 12.

NFS 4.1

In month 6 we will have the following steps done :

• Test system setup with servers and clients at DESY and CERN.
• Collect information (tests setup) from experiments and ROOT people on realistic setup for ROOT testing with NFS4.1 build a matrix for further testing. We will ask experiments official for input at the WLCG workshop at Imperial. Furthermore we will contact Johannes Elmsheuser to help us with the Altas Hammerclouds. Oliver and Jean-Philippe will contact somebody from CMS for realistic analysis jobs.
• Run metrics on a) native NFS4 on Linux followed by the dCache NFS4.1 installation followed by DPM. For dCache we expect realistic performance data. For DPM only functional and stability results.

SRM GSI

1. Solving/Clearifing the issue of which openSSL version, supporting Proxies and Extended attributes, is available for which platform.
2. Prove of concept : We need a functional prototype with at least one client and one server running SRM via https. This doesn't include the SRMCP mechanism as it requires delegation which is not coming with https.
3. Agreement with EMI-security which delegation service would be preferred.
4. If customers insist in SRMCP, implementing the selected delegation service.
5. Migration preparation : making sure all relevant file location catalogues don't store too much detail about the endpoint, so that we can run httpg and https services concurrently on different ports (however on the same host).

We expect an working example with at least one client and one server being available month-10.

Futher ....

Preparation for a f2f workshop for common area working groups

-- PatrickFuhrmann - 27-Jul-2010