LCG Management Board |
|
Date/Time:
|
Tuesday 19 June 2007 16:00-17:00 -
Phone Meeting |
Agenda: |
http://indico.cern.ch/conferenceDisplay.py?confId=13800
|
Members: |
|
|
(Draft
Version 2 26.6.2007) |
Participants: |
D. Barberis, I. Bird, N. Brook, T. Cass,
Ph. Charpentier, L. Dell’Agnello,
C. Eck, M. Ernst, I. Fisk, S. Foffano (notes), J. Gordon, F. Hernandez, M.
Kasemann, J. Knobloch, M. Lamanna, H. Marten, P. Mato, P. McBride, G.
Merino, B. Panzer, R. Pordes, L. Robertson (Chair), Y. Schutz, J.
Shiers, O. Smirnova, R. Tafirout,
J. Templon. |
Action List |
|
Mailing List Archive: |
https://mmm.cern.ch/public/archive-list/w/worldwide-lcg-management-board/
|
Next Meeting: |
Tuesday 26 June 2007 16:00-17:00 - Phone Meeting |
1.
Minutes and Matters arising (Minutes)
|
|
L. Robertson noted the frequent absence
of RAL at the MB. J. Gordon to follow this up with T. Doyle. Minutes: Nick Brook requested the following 2
additions to the last minutes: Item 5: "LHCb raised the issue of
milestones associated with the gLite RB, as LHCb had been informed a usuable version of the RB cannot be deployed at CERN
until the proper certification procedures had been completed. The MB believed
that the gLite RB was in production. ACTION: Les would seek
clarification." Item 6: "LHCb still had concerns on
issues with regards how best to estimate disk cache in front of the
MSS." D. Barberis commented on the statement at
the end of point 3 that “ATLAS expect the MoU pledge to be honoured no matter
what is specified in Harry’s tables” pointing out that there should be no
contradiction, if the numbers are different between the MoU and Harry’s table
the MoU is the reference. The MB accepted the changes and comment
and the minutes were approved. J. Templon asked for the link to the
latest version of Harry’s table to be confirmed. It is available from the LCG project planning page Resources
section, Resource Planning Tables heading (an explanatory email was
sent by L. Robertson on 20/06/07 for clarification). Matters arising: I. Bird gave a brief status of the
resource broker – a packaged version of the new workload management system
was given to Imperial College for testing. There were issues with overloaded
BDII and machine configuration. A service has been set up at CERN to
duplicate and validate what is being tested with a plan to deploy as soon as
possible. M. Lamanna commented on the document made available to the MB in the
agenda showing trends and efficiency of Crab jobs (CMS), Pilot jobs (ALICE),
Job Agents (LHCb) and Ganga jobs (ATLAS). Only jobs submitted through a
Resource Broker are monitored. Comments and feedback should be sent to M.
Lamanna. |
|
|
|
2.
Conclusions on accounting
non-grid work – J. Gordon
|
|
A proposal was made at the F2F meeting on
05/06/07 however the discussion had been cut short. Conclusion from minutes of F2F meeting: The MB would like this issue
investigated further. It is necessary to distinguish between grid and non-grid
and non-grid work should be reported with as much information as possible
(including VO and the user identity) as needed by the experiments. A technical study has started and a new
proposal will be made at the next Face to Face meeting on 03/07/07. |
|
3.
GDB Main points – J. Gordon
|
|
J. Gordon invited members to read the
meeting summary document which covers all subjects
treated at the meeting, as only certain points would be raised in this MB
agenda item.
On the Generic Attributes issue several things are unclear: it is not clear that all the use cases are known, it is not clear what is expected to happen once they all exist and what middleware will be used. J. Gordon stressed the importance of getting a common idea of roles, groups, attributes and the need for a middleware group to discuss this. Comment received from C.Grandi. Just
one clarification on the VOMS Generic Attributes: the API call that retrieves
the R.Pordes
mentioned the Middleware Security Working Group and a paper that describes the current use of
certificates in the Open Science Grid, confirming that OSG is using the
Middleware Security Working Group for such discussions. J. Templon expressed
interest in the paper and J. Gordon added that the Middleware Security
Working Group seemed to be the right forum for the discussion. However I.
Bird commented that a wider and more technical discussion forum was needed.
Ph. Charpentier added that generic attributes do
not have a well defined usage. J. Gordon stated that the definition of how
middleware can use generic attributes still had to be defined and a focused
group needed to look into this issue. J. Templon suggested the reformed Job
Priorities group led by S. Campana. L. Robertson suggested that J. Gordon
makes a proposal to the GDB or MB.
|
|
1.
Megatable issues (slides)
- C. Eck
|
|
C. Eck informed the MB of a meeting of
the Megatable team which had taken place on 14/06/07 and at which three main
issues had been revealed:
Resources pledged have to
be installed and available on 1st April of the year of the pledge (with two
exceptions: 1. for 2007 resources pledged have to be installed and available
on 1st July, 2. Russian pledges are installed and available at the end of the
year therefore the Megatable for 2008 will use the 2007 pledges from Russia).
Each site has to plan acquisition and installation schedule accordingly with
these dates. Requirements published by experiments are gross capacities
including resources required for usage inefficiency and disk capacity
required for efficient tape access i.e. no hidden resources in addition to
the pledge. C. Eck recalled that this had already been discussed at length by
the MB.
C.Eck said that the Megatable is intended as a translation of the TDR
requirements of the experiments into requests for storage at the sites. D. Barberis corrected this saying that it was rather a
translation of the pledges of the sites into the bandwidth available at the
sites. ATLAS have converged between requirements and
pledges but it is nonetheless the pledges that have been used as input to the
Megatable. C. Eck remarked that the aim was to give a clearer view of what is
requested and what is expected to be available. It also provided a learning
exercise allowing T1<=>T2 relationships to be established and
optimization of the T2<=>T1 dependency network. Some discussions had
resulted in the move of T2’s to different T1’s. C. Eck reminded the MB that
the Megatable is not intended as a detailed recipe for implementing storage
and networking at the sites. By splitting storage and requesting the tape
cache size some sites got the impression that the Megatable was becoming a
blueprint of their system architecture. Creating now a last version of the
Megatable for 2008 should prepare sites and experiments for adaptation to
future years and to the changing LHC schedule.
Proposal to the MB: a last version of the
Megatable for 2008 should be published based on the requirements from October
2006 and the pledges resulting from this from April 2007. This version of the
Megatable will only contain summary information on tape and disk and should
be ready by beginning of July. L. Robertson asked for clarification on
the proposal as it seems to remove all detail of the allocation of storage to
different classes and leave the experiments to discuss this detail with the
sites. F. Hernandez commented that the estimated
network bandwidth requirements were needed beyond 2008. H. Marten expressed
surprise that the Megatable was being discussed again following the agreement
of the last version where it was understood that any new versions would be
minor corrections only in case of additional T2’s. C. Eck clarified the
difference between the last version (January 2007) and the proposed new final
version is the updated pledge level of the funding agencies for the April
Computing Resource Review Board allowing experiments and sites to update the
table based on more realistic resource planning. D. Barberis commented that the MB had
asked for a new set of requirements based on no run in 2007. ATLAS are currently working on this and an updated Megatable if
it was really a necessity could only follow as they are linked. He questioned
the usefulness as new pledges would be available in October so another new
version should be produced. L. Robertson stated that probably only one
version should be produced per year and asked the MB to comment on the
proposal to remove storage classes. J. Templon and J. Gordon asked for
clarification on where to get the information if not from the Megatable. L.
Robertson noted that such detail comes from discussions between the
experiments and the sites – the Megatable is only a central repository for
this information. M. Kasemann confirmed that CMS
prefers gross numbers in the Megatable with the details discussed between the
experiments and the sites. L. Robertson commented that as the Megatable only
contains information provided by the experiments, if the experiments are in
doubt about its usefulness it should not be maintained. D. Barberis commented that the main added
value is the calculation of network bandwidth. J. Templon added that the
T2-T1 matching process and the storage class information was
useful. Ph. Charpentier commented that the
information in the Megatable is useful, but not complete. G. Merino was of
the same opinion. D. Barberis suggested adding a T1-T1 matrix. N. Brook
commented that disk cache could not be included as he was not in a position
to provide this information. L. Robertson remarked that it is necessary to
allocate some of the disk storage for use as a disk cache for tape, even if
this is a minor fraction of the resources, and so there must be bilateral
discussions between the sites and experiments to decide on the size of the
cache. L. Robertson commented that we have two
proposals –
In both cases the data is provided by the
experiments after discussion with the sites. The usefulness is to have a
central repository for this data to allow people to cross-check commitments. L. Robertson summarised the discussion
stating that this favoured continuing with the second solution, but
underlined that the Megatable is just a centrally located repository for
information provided by the experiments from their model and discussion with
the sites. If storage classes are required then the experiment must agree
them with the sites. The experiment computing coordinators
should provide input towards a new version of the Megatable in July, based on
their new requirements, via the appointed Megatable team members of each
experiment. |
|
2.
AOB
|
|
L. Robertson informed the MB that the
meeting with the referees may be moved. L. Robertson to send current proposed
agenda for the meeting which may have to change depending on who is
available. |
|
3.
Summary of Actions
|
|
J. Gordon to follow up RAL participation at MB with T. Doyle. MB members to make comments on trends and efficiency document to
M. Lamanna J. Gordon to make a new proposal for non Grid accounting at the
F2F meeting on 03/07/07. I.Bird to follow the suggestion that S. Campana be asked to lead
the reformed Job Priorities Working Group and to define instructions to sites
via the operations meeting. J. Gordon to propose which group (Middleware Security Working
Group, Job Priorities Working Group or other) should look into the Generic
Attributes issue. J. Gordon to contact Dave Kesley
regarding follow-up of the AUP for the VO issue. Experiment Computing Coordinators to work on update of the
Megatable for July in collaboration with the appointed Megatable team members
of each experiment. L. Robertson to send the proposed LHCC referees meeting agenda. |