Present: Mike, Aleksandr, Péter, Sergio, Grigory, Andrei I., Kalle, Atro, Olli, Juha K., Tomas, Andrei Z., Balázs, Arto, Mattias, Michael, Mikko, Jukka, Aleksei, Irina, Farid, Oxana (at the minutes)
Real close now. Documentation, packaging – esp of external s/w is missing. Release in few weeks. Wishlist: bring back gsincftp or uberftp. KnowARC will launch new developments, (new core & high level services, interfaces) nothing definite yet.
OS, GIN summary; find least common denominator for all the Grids in 4 areas: authentication/authorization, data movement, job submission, resource representation.
BK, glue2 is stopped, LCG and NAREGI starting new GGF WG for resource representation. ARC-glue mapping is done, AK suggests to package glue translation script into distribution.
AK, SRM compatibilities: all are different, ARC's server appears to be not compatible with dCache client, and ARC client is not quite compatible with dCache server – dCache misbehaves on high load. Problem: SRM does not define the order of processing requests and answers. SRM3 was meant to do it, but postponed by LCG in favor of SRM2.3 – which is still incomplete, though somewhat better, simpler.
MG, gLite interface: makes use of Condor's capability of submitting to ARC and new gLite WMS. The WMS is still broken (jobs are never in Done state), the gLite CE is also either broken, or incorrectly deployed. GLite is still a moving target, they've got a new build system which doesn't quite work, but with the help of LF there are some scripts which enable some job submission. The work will perhaps be moved to NDGF, at least partially. Submission from ARC to LCG: currently would need Condor on every client, CREAM is expected to offer a usable interface, but it might be only in gLite 3.1, if ever (?).
SM, have some RTEs, don't follow any naming scheme – rather, users were used for another naming convention. Therefore do not register to the repository, but are willing to converge to the same standard. Licensed software – a tricky issue how to deal with limited number of licenses, how to count nr. of instances.
Trust: who can guarantee that any given application software is good and not doing nasty things? Signing s/w distributions with VO certificates – a difficult issue, e.g., ATLAS will never certify a Debian distribution.
LCG had plans and basic implementations for a service to install s/w on user's demand and “cache” it for further jobs.
Input data from databases: not always are a part of the RTE, may change often. Question: how to run a job with the old data – shall it be considered a different RTE version, or different input data.
SM, very short jobs (1.5 min), embarrassingly parallel, scheduler's overhead is typically much bigger. Solution: a job takes 10-20 independent “subtasks”. P-grade portal will hopefully solve the issue of multijob management.
Need cache and brokering based on data availability in cache; input data is read frequently, thus prefer to be copied to the local node – cache can be configured to copy files into session directory.
Before: everybody wanted to be on the Grid, nobody wanted to contribute resources. When convinced to share resources, nobody wanted to install anything as invasive as EDG/gLite. ARC turned out to be the least invasive, though still not light enough. Now: hostile environment, nobody likes Grid, nobody wants to change policies or re-configure their sites, people are skeptical about Grid future and don't want to invest too much efforts into it. Grid services should be installed in demilitarized zones, connect to the sites via ssh.
Site functional test: users would like to know which sites are good for them. Sites should be able to run self-tests (alternatively, users provide application-specific jobs), a part of monitoring.
Data synchronization is needed: e.g., when a “head” database gets updated, it is propagated to its replicas. Nobody is working on it yet.
AK thinks that clients define authorisation framework, BK thinks it's the servers that do it. Currently, job doesn't get to the service if the client decides the user is not authorized. BK would prefer to (a) decouple authorization from job submission (let the GM to judge authorization?), (b) quit relying on grid-mapfile.
AZ, is authorization per queue or per site? A discussion tends towards defining a queue (or whatever a job management unit is) as a Compute Element, with a dedicated GM daemon, GridFTP jobplugin and infosystem – hence a dedicated contact string. Action item: AK, BK will see for ways to implement it in 0.7, possibly ported back to 0.6.
Some discussion on optimizing resource discovery – push vs pull, hierarchical models are the only ones that scale, inconclusive. Search pattern should be optimized.
Authorization information should not be public. Clients must not know who is authorized, they only must know whether this particular user is authorized or no, and get further details (nr. of CPUs etc) only if the user is authorized. A client could possibly keep a cache of good sites per user, saving on handshakes every time.
AK pushes for several levels of information cache, e.g., grouping sites by served VOs, memory, RTE.
OS, overview: currently VOs are mostly users, need per VO accounting – disk, processor time.
Storage for a VO: the only feasible solution is to have dedicated disk volumes per VO. For tapes, CASTOR relies on namespaces. GACL already attaches user info per file/dir, may well add VO information. Need to store not just ownership/provenance, but also billing information with the data. HIP is interested in looking into it wit NDGF.
For jobs, similar “billing” info is needed. Can be done by extending GACL.
User should somehow specify the billing address (VO name), which has to be validated. Proxy is one possible place to store it. VOMS can easily attach more than one VO to the proxy – hence an additional attribute “billing info” should be added. AK wants to put this information in xrsl too.
Question: how to bill CPU usage on one VO, and disk usage – on another; moreover, how to charge different files to different VOs. JSDL provides a reasonable framework, where per file one describes the way it is stored/transferred/billed. AK favors an XML document, should go along with the JSDL-based reorganization of input/output files. Should be extensible. Another simple backwards-compatible solution is to add a new xrsl attribute (billing=(cpu atlas)(outfile1 cms)(outfile2 alice)). If the billing info is not specified in xrsl, VO in the proxy is billed for everything. If no VO is presented, up to site to decide.
Examples of VO configurations to go into authorization document, as many are unaware of the functionality.
Issue: how to introduce VO-based quotas, info on how many resources are available per VO at a given time.
BK likes internal GM limits.
VOMS is a desperately bad implementation, spread around thanks to EU support. But we should be able to work with it, when necessary – that is, interpret VOMS extensions, get users lists etc.
AN, re-vamped logger, already available in 0.5.48. Needs to get timestamp format defined and stored in some ISO-compatible manner.