Present: GS (minutes), SB, FS, GC, OvdA, JC (chair), AF, ST, DC, PG Transfer Tests -------------- JC: Main problems. How to extend in January? RAL-PP: 1TB ok. GS needs to catch up with CB. Lancaster: Doing tests. Exact result not logged. GS will contact BD. Imperial: One slow door/pool. Will upgrade to 1.6.6 and repeat test. GC: Writing to local at dCache Edinburgh is a bottleneck. Probably nfs mounted pools cause write bottlenecks. RAID5 disk arrays also slower. Performace out to RAL is fine. GS: dCache to DPM still awful rates. Chasing with developers. GS: Glasgow will investigate DPM performace against different FS's and kernels. JC: Should we have learned this during SC3? Tests were not detailed enough. AF: Manchester dCache installed. Channel setup. LCG dCache release. Will test later today. JC: Any problems at RAL? GC: Some timeouts at RAL. ST investigated. ST: Data streams from pool node to fts server. Too many connections? Will tweak. Has talked to ME. JC: How to extend tests in January? Nominate sites? GS: Follow same model - It's working. OvdA: Do interDPM tests? Yes. JC: Targets were nominated as being "reasonable". Expect to achieve this, but no hard technical specs underlie targets. GS: Transfer rates need to be measured for lots of files - otherwise SRM overheads can skew rates down. GS: Inter T2 tests should have a channel setup at RAL. JC: Improving throughput achieved? Can we do something at the network level? ST: Not yet reached this stage of tuning. Grieg's model of recording info at the site level is good. ACTION: Advice page on tuning dCache. GC ACTION: Advice page on tuning DPM. GS ACTION: T2Cs to nominate sites for Jan tests. T2Cs Security Challenges ------------------- JC: Overall lessons learned? AF: Sites are responsive. Took longer when didn't know how to get information, espc. from res broker. Only LCG PBS writes enough information. Condor-G and SunGridEngine didn't have enough logging. Needs to be raised with developers to ensure that enough is logged. Only liverpool were unresponsive. Ticketing system was problematic. New version of footprints doesn't solve all problems. JC: Will stay with footprints for the moments. AF: Need to do security challenges more often. Need to test storage part. SB: Do tests against jobs run sometime before (months). AF: Issue with being able to uniquely identify test jobs when more than one job was run in the timeframe. Security contacts need to be taken from the GOC db. Urgent issue. ACTION: JC to follow up with Matt on getting security contact info from the GOC db. ROC Processes ------------- ENABLING VOS JC: How to enable VOs. Sites are slow/unwilling. How can this be done better? AF: It's hard. Need to pass information to sites. Can't expect sites to do everything. OvdA: Rerunning YAIM can break things. Want to do sets of VOs in one go. SB: VOs have information avaliable (e.g., PhenoGrid). Site managers have to look. Getting approval as an EGEE VO is hard. JC: Regional VOs need accelerated enabling. Aggregating updates is a good idea. AF: How to make process easier? Need to change fair shares, etc, etc. SB: Standard config VOs were easier to do so were enabled. ST: Written down as 30 steps to add a new VO. All turned out to be essential. It's _not_ simple! AF: Wiki page on suggested proceedure. VOMS server certificates need to be distributed. RPM? GridPP level? ST: Have this per-VO makes more sense than a GridPP certificate list. LOCAL/REGIONAL VOs OvdA: Have LT VO enabled in London. Setup LT VO for a course/lecture then extended. Is this the best way? JC: A generic VO? What's the AUP for the LT VO? OvdA: Simple AUP restricting use. Uses eScience certs. SB: Locally for a single course is just easier. Wider GridPP VO would serve a different purpose. JC: ROC page listing T2 specific VOs? OvdA: Single VOMS server with UK? Then a trust issue. VOMS at manchester? ST: MAGIC VO have not agreed to any AUP. Can't use RAl though the VO is "enabled". UK TPM JC: Having people in UK to help process tickets. Forward on to GGUS. 2-3 per shift, shifts 1 week in 6. So far a few tickets a week. Need to forward to correct part (VO, Infra, etc, etc). Need training - 1 day course. Only tickets where user did not know where to assign it. WEEKLY REPORTING JC: Is it working? Helping? 5-6 sites have been good. FS: Mark (dur) said timeframe is not suitable for his work cycle. FS is going to be added as a manager at Dur to help. As these reports used for 1/4 rep, inability to add comments beyond the deadline is an issue. JC: Question about versioning, then. PG: increases downtime hours enormously. often not sites' fault. JC: Downtime hours or just periods? Ability to mark up as "Not Relevant" is very useful. Could move report data to, say, Wednesday - would give 2 full working days to edit. ACTION: JC to report on these issues raised to ... ? TEST ZONE and LCG27 ------------------- JC: Pre release of 27 on Jan 16. 1 week to test. UK will be involved. https://uimon.cern.ch/twiki/bin/view/LCG/LCG-2_7_0 Test breakdown: GS: DPM, LFC servers, DPM, LFC and FTS clients GC: dCache server and clients AF: VOMS OvdA, DC: RB PG: RGMA People are using machines between tests (Glasgow DPM test boxen, PPS servers; Oxford x-submissions between clusters, etc.) AOCB ---- JC: Footprints will be upgraded, and kept in the medium term (just bought more licenses). JC: XOOPS web content Management (www.xoops.org) RAL people have attended course. Looking at XHelp part of this package. Next Meeting: 3rd Jan. Many will still be on Holiday. F2F dteam Meeting: Friday 13th after GridPP.