Choose timezone
Your profile timezone:
TMB Meeting
Description
A phone conference has been set up:
To dial in to the conference call:
Call: +41227676000 (Main)
Enter access code: 0170047.
To join the web conference, click here: https://audioconf.cern.ch/call/0170047.
To dial in to the conference call:
Call: +41227676000 (Main)
Enter access code: 0170047.
To join the web conference, click here: https://audioconf.cern.ch/call/0170047.
SA1: Nick, James, Steve
Sites: Jeff, Daniele
SA3: Oliver
JRA1: Francesco G., Francesco P., Massimo S. and CREAM group, Antony
Security: John
NA4: Vangelis, Johan
HEP: Patricia
CMS: Andrea
Atlas: Massimo L.
Minutes of last meeting
=======================
No comments.
Action List
===========
New tasks by NA4, extracted from their QR
#7945 (MPI jobs on multicore/SMP machines)
Francesco G: assign to me. Some work has been already done in Catania
and the plan is to integrate it in MPIStart. Discussion between
Roberto Barbera and the MPI WG is on-going.
Erwin: sites are still concerned about the configuration needed to
accomodate MPI jobs, because of the risk to waste resources
Action on Nick to follow how to configure sites to support MPI.
Jeff: the description of a job arriving at a CE should contain an
estimation of its wall clock execution time. The problem is less
important for a large site than for a small one.
#7943 (Hydra clients not available)
Oliver: about to be released, but no exact timeline
Erwin: push clients earlier than servers
#7942 (Insufficient Developers Guides)
A guide for application developers, not for gLite developers.
Erwin: the working group on data management in NA4 can point out also
deficiencies in APIs
Oliver: for YAIM please post bugs
Close task.
#7935 (LFC performance)
Requirement coming mainly from bioinformatics.
Massimo L.: HEP applications (mainly ATLAS and LHCb) are heavy users and
asked some modifications in the past, because of some performance
problems in certain conditions, in particular when doing bulk
operations. Now it seems ok.
Erwin: to Vangelis: please ask their usage scenario, to see if they
use LFC in a inefficient way or if there is a actual issue to be
addressed
Task assigned to Vangelis.
#7933 (Web Service interfaces for WMS and DMS)
Francesco G.: after a quick survey in JRA1, the main missing WS seems
to be LFC, which is not even planned.
Massimo L.: LFC has been built by Mattias Ellert on a number of platforms
other than SLC4. American sites are moving to use LFC, but they
require some http access; a prototype exists inside ATLAS, willing
to contribute it back.
Francesco G.: you should talk to the DM people.
#7932 (Lack of APIs for various middleware services/components)
Erwin: there has been some work in Catania; what about moving it into
RESPECT?
Francesco G.: there is also considerable work done in g-Eclipse, those
APIs could also be contributed to gLite or to respect. There was
some discussion at an EGEE'08 session. It's true that their gLite
APIs currently depend strongly on g-Eclipse libs, but they said they
are working to reduce/remove them.
Vangelis: they want to apply for RESPECT. To be discussed.
#7931 (Ability to specify machine architecture in job descriptions)
Steve: the operations should fill the corresponding GLUE fields. It
should be quite easy to do it, but we should agree on the values.
Assign the task to Steve.
Francesco G.: once the values are published, it's already possible to
match against them, although it's not possible yet to explicitly
select a subcluster when submitting to a CE.
#7841 (Review the dCache and DPM documentation regarding #6901)
Assign task to Vangelis.
#7826 (SA3 to provide a list of services and their versions)
Oliver: the information has been there for years; if it instead
refers to what is needed or supported, it should be provided by SA1
Erwin: in the roadmap we should say how long each service is supported
and how and when it will be retired. We will do it in the next months.
Close task.
#7678 (Follow up security implementation on xrootd and dCache)
John: we had an SCG meeting; Romain will contact dCache developers and
see how this progresses.
#7677 (Discuss with Francesco moving ahead with matchmaking)
Francesco G. describes how matchmakin should be in the general case based
on few parameters, encompassing all what is needed to run a certain
application, e.g. match a tag representing the software environment
certified by the corresponding VO.
Erwin: in general agree with Francesco. But a discussion on this is
outside the scope of the TMB. Probably we should recreate a design
team or similar group.
Close task. But Francesco G. to keep an eye on how matchmaking is used.
#7676 (Give an update on Dashboard expansion after the EGEE08 HEP session)
Patricia: during EGEE'08 Julia made a presentation on this. We are now
able to collect information from jobs coming from the WMS, but with
a delay of 30 minutes, which is not good enough for the
dashboard. Moreover this requires periodic queries to the LB, which
is not good either. The plan is to use LB notifications. Tests
are on-going on a small testbed. Once the mechanism is proven
reliable, the implementation in the dashboard would be easy.
Jeff: is this work done on a branch of LB?
Francesco G.: notifications have been there for a long time, just not
much used and tested.
Erwin: but is there interest from other communities?
Patricia: there is interest from the Fusion community.
Jeff: there is interest from the dutch VLEMed as well.
#7674 (JRA1 and SA1 to examine what happens if a site doesn't support
all approved CAs)
Close task.
Create another task with "how to cope with..."
Andrea: how is this different from banning a user?
CREAM: Status and Open Issues
=============================
#7675 (SA1 to develop method for transition to CREAM)
This will be provided next week.
Oliver: CREAM will be released not as a production service, since
there is no production WMS able to submit to it. CREAM will not be
for the moment a replacement for the LCG-CE.
Patricia: ALICE has been using CREAM in production since before
summer. Karlsruhe putting cream in production next week.
Focus on the proxy renewal strategy:
------------------------------------
John summarizes the problem, due to incoming connection on the WN.
Erwin: is there a proposal by developers?
Massimo: MyProxy, as suggested by Maarten, transparent to the user
Francesco P. summarizes the solution
John: this has been discussed at the conference; there are also other
proposals, e.g. by Chad.
Francesco G.: I have involved the SCG to have an opinion on the two
approaches, push vs pull.
Maarten: a short term possibility is to deploy CREAM with proxies via
GridFTP. It would be no worse than now, waiting for a proper
solution.
Erwin: JRA1 to provide a short document with the different approaches
and costs
R-GMA and Monitoring strategy
=============================
Followup discussion on the status of R-GMA.
There are two potential solutions for user-level monitoring, R-GMA and
ActiveMQ. The TMB should decide on the importance of this issue and
which solution to pursue.
Erwin: at the moment no application group uses RGMA for application
level monitoring; operations are moving to ActiveMQ; question: what
should be the tool to advertise to the users?
Oliver: can ActiveMQ be deployed to enable user-level monitoring
properly?
James explains the different options available for messaging, all of
them are easily deployable. On ActiveMQ: it is Java, it is enormous
and it still has bugs, but there is a big development community and
also company support. ActiveMQ easily fits in our environment. We
need to understand operational costs, for both operations and
applications.
Francesco G.: what is the security model?
James: ActiveMQ uses a JAAS plugin mechanism to allow for different
authentication and authorization providers, similar to the mechanism
used in Tomcat; messages are signed and can be encrypted; all is
done in the broker.
Antony: from our experience, network deployment issues need to be
taken in consideration. [Antony describes the new features of RGMA,
see document distributed to the list.]
Erwin: how many messaging systems are we going to support as a
project? of course applications are free to choose what they
want. As a project we tend to take what comes from outside if
possible; for messaging this can be the way as well.
Oliver: the project is not funding RGMA, there is some volunteer
effort in JRA1, but only for development.
Antony: RGMA is not only a messaging system.
Massimo L.: what happens in OSG?
James: they use GRATIA for transport; we have agreed to have a bridge
between the two infrastructure
Conclusion: the strategy is to support one messaging system,
identified by SA1, for infrastructure monitoring. This could then be
used also by applications. EGEE will continue to support the current
RGMA infrastructure until needed. The new RGMA will not be generally
deployed, but of course a partner is free to do it (e.g. Grid
Ireland). RGMA could eventually be part of the RESPECT programme. RGMA
development can continue in JRA1, but no effort for certification and
deployment would come from SA3 and SA1.
Antony opposes the conclusion, given the two-years work behind the
latest version of RGMA, ready for certification.
Task on SA1 to identify a pilot user community for application
monitoring (e.g. the dashboard)
James: the monitoring should also enter the gLite release process.
Comments on JRA1 Workplan
=========================
Closure of SDJ WG
=================
Database WG Update
==================
Postponed to next meeting
AOB
===
Nothing.
There are minutes attached to this event.
Show them.