TMB 08/04/09
Vangelis, Cal, Massimo, Steven, Oliver, Nick, Jeff, Xavier,
Christoph, Horst Schwichtenberg
**
Minutes - nothing
Action on SA1 on how to go from cert to prod in the UMD world
still open
discussed at last SA1 coord meeting, no feedback.
will produce proposal
Maintenance of VOBOX
Steven spoke to Patricia (not keen)
Elisa now maintaining the proxy renewal
Jeff - problem is all VOBOX managers are mapped to the same user
this can be solved, but someone should do that work
Upcoming TMB will discuss general proxy store
storage semantics for EGEE beyond hep (6901)
Vangelis still following this up
JT - how do we align other app communities with what HEP is doing.
Concerned that HEP go somewhere with SRM and leave the others behind
CL - maybe consortium could take something already existing like irods
or SRB.
JT - don't want the 'alien' situation again where we do a lot of talking
with not much happening.
ML - I think HEP will be moving to more generic solutions, particularly
towards distributed filesystems.
** MPI
SN - first we need to demonstrate that MPI is supported by the project
CL - all VOs other than HEP need it, to first order
SN - in EGI era for harmonisation between HPC and HTC, this will be an
advantage
JT - sites are not enthusiastic about MPI if the LRMS doesn't know how
long jobs will run, as this results in empty batch systems.
ML - are there instructions how to do this efficiently
JT - not possible right now, as we cannot pass requirements and LRMS
always assumes that your job will last for the whole available wall
time.
OK - will jobs accurately predict their duration?
JT - there is a huge variation in wall time, doesn't have to be too
accurate.
SN - what about the parameter passing then?
OK - available in cream as a hook, SA3 looking into a template for this
SN - still, sites will see a dip in utilisation if they support MPI
OK - but attracting new VOs will not lead to a dip in utilisation. Maybe
the sites simply have no obligations to these VOs
SN - there will be support for MPI on SL5 in future
OK - we will process updates to MPI when they arrive.
**
yr 2 changes
discussion on product team list
only change was to find someone for AMGA
then there are MPI/LRMS style things, who is to look after these
components?
OK - please add yaim
JT - why should UI an WN be product teams? There are two kinds of
product
OK - almost all the 'products' are composed of different components, the
UI and WN are just more extreme examples. They will be product teams
without any developers.
JT - but, for example, DPM doesn't need BDII specifically, it needs
information system.
SN - ideally a product team would choose an implementation of the IS.
But, now all our interfaces are tied to implementations
JT - maybe change the name to node-teams.
discussion on proposed changed to EGEE-iii DoW for year 2.
SN - this is mostly for your information, discussed at AMB
SN - biggest changes are with SA1, will check these after with NIC
CL asks if his changes were incorporated
SN thinks so.
**
MATLAB
Vangelis produced a discussion paper to clarify issues.
VF - 4 licensing models, rc, vo, ngi, ssc (see paper attached to agenda)
OK - most natural solution is VOMS, we have a solution, but would this
require the VO to be the licensee?
JT - can the auth service contribute? It's a v good use case.
CW - yes
SN - how is access implemented? Mapping to a particular group? Flexlm?
VL - flexlm.
HS - no access control.
SN - flexlm controls how many licenses can run at once
CL - matlab sends a key with jobs. But do we want to be involved with
this? We should do matchmaking and then it's up to the product to decide
whether licensing is valid or not.
NT - agrees with cal. has been involved in licensing for distributed
software. let the app people decide.
SN - go back to matlab and find what separation they want, between
commercial and academic, and whether that can be supported by their
product or if they expect that to be in the middleware.
**
JT on rpm behaviour. Summarises. Agreement that rpm should not update
modified configuration files.
**
Auth service
CW : discussion of whether an atlas job can pull in a CMS pilot
will propose that this is not enabled (for v1 of auth service)
to GDB
cream and WMS will start on integration before summer break
SN - currently renegotiating JRA1 work. am happy to see cream, less
convinced that WMS is necessary.
CW - cream are happy to clean up their auth and go first. WMS are happy
to go second and learn from cream.
CW - development of auth service is finished with two items remaining.
Timescale a week to finish.
testing has happened at 4 partner institutions. performance numbers have
to be verified by an independent team (certification).
two tests done for long term stability. 3 day test, 5m requests from 6
clients. no reboots or errors, correct decision taken in all cases. no
memory increase.
have been testing for several weeks the distribution of remote policies.
no problems.
throughput hard to gauge. different hardware. n simul clients from n
hosts is difficult. how may policies do you have? using encryption? How
have you configured caching? (auth service has a caching algorithm over
N seconds).
performance figures given with PEPd on same machine, calling directly
(no glexec). Timing done using grinder, a profiler.
SN all this should be taken into account when comparing with SCAS.
CW - hopefully 2 weeks before certification.
**
AOB - none.
There are minutes attached to this event.
Show them.
