LCG Management Board


Tuesday 2 May 2006 at 16:00




(Version 1 - 4.5.2006)


A.Aimar (notes), S.Belforte, I.Bird, N.Brook, F.Carminati, T.Cass, M.Delfino, J.Gordon, B.Gibbard, C.Grandi, F.Hernandez, M.Lamanna, E.Laure, M.Litmaath, H.Marten, M.Mazzucato, B.Panzer, G.Poulard, Di Qing, L.Robertson (chair), Y.Schutz, J.Templon

Action List 

Next Meeting:

Tuesday 9 May 2006 at 16:00

1.      Minutes and Matters arising (minutes) - A.Aimar


1.1         Minutes of the Previous Meeting

Comments received from ATLAS and PIC (highlighted in blue in the minutes).


See on the MB Minutes wiki page.


2.      Action List Review (list of actions)


No outstanding due actions.


New actions added, see the MB Action List.


3.      Update on gLite 3.0 Status (more information ) - I.Bird

3.1         Release Candidate 4

During the previous week gLite RC4 was prepared but failed some of the tests. It was mostly due to packaging issues and to the fact that some known workaround to GridFtp had not been packaged in the release.

3.2         Release Candidate 5

Once this workaround was applied RC4 was passing those tests. But meanwhile important issues were found and fixed on the FTS discovery client and on DPM Therefore one more RC will be released on the 2nd of May: RC5.


RC5 will be tested and the installed on the PPS and on the Tier-1 sites in the next two weeks (in two groups over the two weeks). There is still an open issue, on bulk submissions, that is being investigated and that will not be part of the release.


Update (5 May 06)

GLite-3.0.0 announced on the 4th of May.

Tier-1 sites that will upgrade on week 1:


And on week 2:



4.      Update on Exploitation of roles and groups in the VOMS implementations (more information ) - I.Bird



The status of Roles and Groups is summarized in these transparencies.


VOMS: The service is in production and ready for gLite 3.0.

4.1         Data Management

LFC and DPM: In gLite-3.0 it will map VOMS roles and groups to (internal) virtual uid/gid values. POSIX ACLs are implemented.


DCache: They reported at the meeting in Rome that exploitation of roles/ groups is under development and that an implementation using the “gplazma” database will be available. Also this implementation does internal mapping and provides POSIX ACLs implementation.


Castor: Intends to use the implementation of DPM in order avoid duplications. The time scale is still being discussed.


FTS: Defines already roles for "Submitters", "VO admins", "Channel admins" since some time, but were never used in production and thoroughly tested.



The consistency between file catalogue and SE is still the responsibility of the user. In the future there will be a Replica Registration Service available, currently only early prototypes of this service are available.


4.2         Workload Management

CE: The main issue is how to manage job priorities on the batch systems. This is already being discussed by a dedicate TCG working group, led by D.Liko. The status of the work of this group is described in the other attached document (PDF file), provided by J.Templon.


For SC4, it is agreed that job priority will be provided with a work around: provide a few separate queues, at each site, for different kind of jobs (e.g. prod, short, long). This solution will require the installation of 2 or 3 queues at each site. Several solutions are possible and the different experiments scenarios are being tested and performance measured.


The standard LCAS/LCMAPS libraries for managing local credentials are available in the distribution (from LCG-2.7.0 onward) but are not used by the middleware, because there is not yet an agreed schema for mapping user roles and groups to local users. This issue is also being discussed in the TCG working group on groups/roles (see the PDF document by J.Templon).


The TCG working group on roles/groups is expected to produce a first version of their proposal by the end of the May.


Action: (not directly related to the VOMS roles discussion)

09 May 06 - L.Robertson will discuss with E.Laure and C.Grandi the status of the development of the features needed by the LHC (in Flavia’s list).


5.      SRM 2.1 working group (transparencies ) - M.Litmaath

-          Progress, features and plans of the SRM implementations



Postponed to next MB meeting.


6.      Deciding on how to proceed with Accounting (document, transparencies ) - J.Gordon

-          follow-up to the GDB session in Rome and subsequent email discussions


6.1         Feedback from GDB

At the GDB in Rome it was agreed to report CPU in kSI2K-days, but in the discussion that followed it was agreed that also “wall clock” values should be reported.

Therefore, in summary, each month all sites should report for each VO:

-          CPU and wall clock values in KSI2K-days

-          Grid and local non-grid usage

-          Disk capacity allocated and used in TBytes

-          Tape capacity used in TBytes.

6.2         Reporting by Tier1s

The MoU only requires presenting to the RRB the values for CPU, disk and tape.

The next OB meeting is on12 June and these values should be available.



The values to report, each month and for each VO, starting end April 2006: 

-          CPU via grid, CPU local, wall clock via grid, wall clock local should be inserted in the APEL database at the GOC.

-          Disk allocated, disk used, tape used should be reported to the LCG Office at CERN. (L.Robertson to define the procedure)..

6.3         User Level Accounting

VOs need to know the resources allocated to them by each site and, if needed, to have the possibility of finding the “individual users” of their resources.


Use cases and correspondent applied policies need to be defined, independently of the tools and technology that will used to implement them.



30 Jun 06 - J.Gordon reports on the use cases and policies defined for user-level accounting, in agreement with the security policy working group (.Kelsey).


The technical solutions presented propose to protect the detailed user accounting data by encrypting the DN. The access policy should establish who can decrypt and see such protected user-level information (e.g. site managers, VO managers, etc.). One technical solution discussed advocates the use of DGAS sensors to collect the data and pass it to APEL that will aggregate it and distribute it as needed. An alternative proposal is to use directly the DGAS encrypted databases on the servers to keep the DN user level information locally and retrieve it from there when needed.


The discussion continued but no conclusions were reached on the topic. Therefore it was agreed that L.Robertson would distribute a proposal for the next steps on user-level accounting.


05 May 06 – L.Robertson will distribute a proposal on how to conclude the discussions on User Level Accounting.


Done. Clarification on User-Level Accounting



7.      AOB





8.      Summary of New Actions



09 May 06 - L.Robertson will discuss with E.Laure and C.Grandi the status of the development of the features needed by the LHC (in Flavia’s list).



05 May 06 – L.Robertson will distribute a proposal on how to conclude the discussions on User Level Accounting.



30 Jun 06 - J.Gordon reports on the defined use cases and policies for user-level accounting in agreement with the security policy working group, independently on the tools and technology used to implement it.


The full Action List, current and past items, will be in this wiki page before next MB meeting.