Choose timezone
Your profile timezone:
TCG 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.
TCG Minutes 20/02/08
Jeff (JT), Daniele (DC), Erwin (EL, chair), Oliver (OK), Simone (SC),
Andrea (AS), Massimo (ML), Markus (MS), Stefano (SB)
apologies from JRA1, NA4
* Minutes of last meeting and action list
EL encouraged everyone to look at the recommendations from Christoph
Witzig and comment by the end of the month.
MS - for a few people at CERN, end of month is difficult as there is a lot
to do (MARS). People are busy. We should not rush this. CW did good job,
valuable suggestions. Now we have some counter proposals.
EL - agreed, no rush, people should try to comment but the process doesn't
finish at the end of the month.
JT - what were the counterproposals, and where?
MS - people have started to discuss, eg Claudio on wildcards and
interpretations on FQANs. Comments are just on details, not whole doc.
JT - so just informal discussions. Serious comments should be forwarded to
TCG.
EW - Christoph Witzig is trying to capture all discussions and we will
continue with TCG discussions
* Release of JPWG configuration to production
OK - the GDB agreed that the prototypes currently in PPS are good enough
for production, could the TCG endorse this?
AS - we're missing instructions on batch sys config, and LSF support
SC - who is supposed to provide the deployment advice?
MS - setting up the scheduler is so site specific that we can only give
examples or templates.
SC - noone is taking LSF support
MS to JT - send the doc to Steve Traylen for an assessment. If ST says
it's good, then we release to prod just for PBS
AS - should be no difference, middleware part is the same, but you can
never be sure.
EL - is there an LSF site on PPS?
AS - yes, CERN
JT - LSF is a hole in EGEE.
MS - yes, but not so damaging because those who use it are big sites and
anyway modify what they receive. Ulrich has rewritten some bits here at
CERN to better integrate with LSF.
EL - sites are so different that it's difficult to do a generic job
ML - what's the default??
AS - one share per experiment, if an exp needs special config they have to
contact the site
EL - if you have something special you need, discuss at ops meeting.
ML - Atlas is putting together a pilot system, so there is another
dimension.
JT - for production, the yaim flag should be OFF. (do you want to publish
FQANs into IS).
MS - the rollout, for experiments,, should be rolled out from the EGEE
point of view as any piece of software. We don't have leverage to force
sites to be quick. If that's what you want, go via LCG.
ML - if it's progressive that's OK.
OK - what versions?
JT - should be the last patch I submitted.
MS - that's for EMT.
* TCG transition to EGEE-III
EL - I've sent a description of TMB for EGEE III. No big change in mandate
or composition. What changes is that TCG was advisory, but decisions were
with PEB. This is now rectified and executive decisions can be taken by
TMB.
Composition is same, few changes in names
Operations manager - Maite Barroso Lopez
will take over from Ian 1st march
site representation
jeff, daniele, alessandra - please ask ROCs if anything should
change. Let's reconfirm nominations
security rep
John White
middleware manager JRA1
Franceco Giacomini
SA3 manager
Oliver Keeble
NA4 manager
Cal Loomis
No more task forces, but strategic discipline clusters, so reps from
those.
EW proposes to keep with reps from the HEP experiments. Criticism that TCG
was too HEP heavy.
MS - one rep from each STC, that makes a lot of people!
ML - HEP dominates, but we've had three Biomed people on the list!
EW - if they don't show up,
MS - ...they give up their mandate
jEL - the 3 regular HEP contributors make a big contribution
EL - earth science, computational chemistry - I want to involve them.
MS - we'll rarely have face to face. What's the total number of people? If
you go down that road, you should have more site rep. The funding is spent
on NA4 and SA1 to first order, they should be represented in a balanced
way. The users want a lot, but ops can do only so much.
EL _ the point is we have 3 site reps to have a mixture of sites, tier 1,
2, multi discipline, for coverage. It's not like we do a vote in the TCG
MS - vote not always required, people mature. one problem with the project
is that dev was driven by the users, but operational requirements have
been largely ignored... lack of monitorability, robustness etc only
happened when the sites complained.
ML - (for Cal) - NA4 would not agree, some of the issues has been driven
by users, but not always the case. Cal's example of MPI support eg. Not
complete picture.
EL - site reps??? what do you think?
JT - yeah. Agree with MS, requirements driven by users. Was a big fight
during the first phase of the projects.
EL - will things change with more site reps?
MS - I'm not arguing to add more people. I'm arguing for a balance and I'm
saying that adding more people is not sustainable, we have to get the
balance right to begin with and people have to aggregate.
ML - we're in a new phase, different apps have higher or lower
representation. Cured in II by adding Biomed. Can understand if the others
feel out of the game. If they show up or not is a reality check for these
people. EL should take seriously that people are or are not contributing.
EL - Don't expect that everyone turns up to every meeting, just that they
have the right and will come sometimes.
MS - functional development in DM was driven by Biomed.
JT - other apps need to feel they are included. Need an app forum to
aggregate their views.
MS - this is NA4!
EL - want Biomed to be represented at the highest level
SB - this stuff can be revised if the board is not working
JT - comment on doc, what's the AMB?
EL - Admin Managemet Board. same level as TMB, activity managers dealing
with deliverables, reviews etc
MS - renamed PEB
DC - action on site managers is to confirm the nominations. Confirmed.
EL - another change in atlas. Now Massimo and Simone.
ML - we have a representative and an 'alternate'. I replace Stephen Gaudi
who moved to CMS.
EL - need to figure a way for minutes. NA1 doesn't have anyone to do that
and GD group has done it before on voluntary basis, not possible any more.
We will have to have rotating minute taking.
EL - meeting frequency and place. Continue every 2nd week, alternating
with AMB. Both meetings could be same time. Weds were problematic with
GDBs. Can we move to Thu at 3?
EL - thanks all outgoing members for their contributions.
EL - will send around a mail with three proposals - wed 10;30, Thu 10;30,
Thu afternoon
EL - during march and April we will move into this new structure, no big
change, just new faces.
EL - early may, transition meetings to discus pow, may 5/6 (to confirm)
EL - main work between now and April - clean up requirements, apps and
opps, to give starting point for egee iii. What has / hasn't been done.
Stefano had a first pass from CMS. Linked from agenda. Request all others
to do the same, can we get agreement. Let's go through items that CMS
thought were done to check agreements.
JT - this is what ms was saying - there's no column from sites.
EL _ this is a different wiki, the lists are separate! Maintained by
Daniele.
DC - yep, and will update in the next few days.
EL - jeff is still welcome to comment on app requirements.
SB - suggest: can the experiments discuss offline and come with an
agreements. question about VDT deployment. Seems we are a year behind on
VDT.
AS - what about srm-cp
OK - who maintains it?
AS - this would be good for CMS to have later srm-cp
SC - we decided for CCRC that dcache should be taken from dcache.org
* Requirements follow-up
CMS done items;
102 - this is generic attributes, done.
103 - this is not in FTS (although delegation is there) => not done
112 - done
121 - JT - SRM is not the same on all SEs. EL - this is req 122. OK 121
done. gridftp servers are not SEs.
123 - MS - some experiments are using SRM1 in CCRC as they know what they
get. EL but have GFAL and FTS hidden the diffs? yes. done, there's no
'SRM2.2 only client'. SC confirms. Done.
126 - SC - we wanted the SEs to expose the checksum, this is not done yet.
rl32 is desired. Not done.
212 - MS - to address this, state machine has been redesigned. EL -
requirement is therefore obsolete, but issue has been resolved.
214 - EL - FTS is doing that? MS - this is 'star channel'. done.
216 - not done
217 - this is SRM v2. ML - lifetime and pinning have not been done. MS -
this was drawn up before 2.2 subset was agreed. list was defined by the
agreement of what 2.2 was. EL; requirement is done, but it changed. SC -
SRM must support pinning and lifetime. do you want FTS to support this.
EL, so we split, storage type is done.
219 - done file placement stuff, ie plugins - obsolete or done. the FPS is
the FTS
261 - done
301 - SB - load balancing is there. Done.
304 - ML - felt that 10^6 was OK with 10 machines -> 10^5. MS - no, we
need one access point (req 302). EL - this is obsolete. MS - have to
re-discuss whether to use this complex and expensive job submission for
pilot jobs. there are much simpler ways. MS - for 1 or 2 million analysis
jobs this may not be the right answer. SB - cannot ask JRA1 for a WMS
which scales much further, better effort is to make it load balancable. EL
- done obsolete.
305 - done
306 - done, you can give a url.
309 - obsolete
402 - JT - SRM does not support this correctly. MS - access control is
currently ongoing. Split to a done part and an ongoing part.
407 - MS - everyone found tricks to get round this. even if the big VOs
have workarounds, smaller VOs may benefit. SC - there is a tool available.
MS - yes, i discussed with author, still a few problems. EL - need a fresh
look at this one.
409 - obsolete
410 - obsolete, what we have is not a 'package manager'. for small VOs,
NA4, what? MS - the generic VO, this is a big overhead/problem. EL - for
CMS it's obsolete, but for smaller VOs should remain an issue. EL - is the
LHCb useful in a generic way? Still no positive answer.
EL - invite others to put their comments in, we'll continue in the coming
meetings, in a couple of months we'll have cleaned up the list.
There are minutes attached to this event.
Show them.