On 04/03/13 17:05, Stephen Burke wrote:
> Testbed Support for GridPP member institutes [mailto:TB-
>> [log in to unmask]] On Behalf Of Matt Doidge said:
>> OXFORD https://ggus.eu/ws/ticket_info.php?ticket=91996 (In Progress) - Is
>> the deadline to upgrade the end of April, or do we need to be sorted before
>> then?
> 
> https://operations-portal.egi.eu/broadcast/archive/id/880
> 
> "IMPORTANT. According to the EGI decommissioning policy [2], 
> the decommissioning deadline expires one month after the end
> of security updates and support of the software. 
> For EMI 1 products this is: 31-05-2013"

Any possibility of extending security support by however late EMI-2 is?

Chris

> 
> Stephen
> 
> 
> 
> 
> 
>>
>> BRISTOL https://ggus.eu/ws/ticket_info.php?ticket=91995 (In progress) -
>> Winnie has asked for clarification for what's going on.
>>
>> BIRMINGHAM https://ggus.eu/ws/ticket_info.php?ticket=91994 (In
>> progress)
>> - Mark will get onto this as soon as Birmingham's AC starts behaving.
>>
>> GLASGOW https://ggus.eu/ws/ticket_info.php?ticket=91992 (In progress) -
>> There are some red herrings at Glasgow due to hanging CE bdiis. Just the
>> WMSes and LB to go, these are being handled.
>>
>> SHEFFIELD https://ggus.eu/ws/ticket_info.php?ticket=91990 (In progress)
>> - Elena plans to upgrade this month.
>>
>> RHUL https://ggus.eu/ws/ticket_info.php?ticket=91987 (Assigned)
>> https://ggus.eu/ws/ticket_info.php?ticket=91982 (Assigned)
>> https://ggus.eu/ws/ticket_info.php?ticket=91981 (Assigned) (Poor RHUL
>> getting 3 tickets - I assume this is the ROD dashboard being silly as Daniela
>> mentioned)
>>
>> LIVERPOOL https://ggus.eu/ws/ticket_info.php?ticket=91984 (In progress)
>> - The Liver lads are working on it.
>>
>> QMUL https://ggus.eu/ws/ticket_info.php?ticket=91980 (In Progress) - Chris
>> has updated his BDII, so hopefully things will be sorted.
>>
>> IC https://ggus.eu/ws/ticket_info.php?ticket=91978 (In Progress) - wms
>> updated, last CE has a scheduled downtime, um, scheduled.
>>
>> BRUNEL https://ggus.eu/ws/ticket_info.php?ticket=91975 (In Progress) -
>> Raul plans to upgrade things at the end of the month. He asks about dangers
>> upgrading the CE from EMI1 to 2 - Daniela replies that the DB change means
>> that it's recommended to drain your CE first.
>>
>> TIER 1 https://ggus.eu/ws/ticket_info.php?ticket=91974 (In Progress) - The
>> team plan to have all services updated by the end of March.
>>
>>
>> Atlas data moving tickets:
>> https://ggus.eu/ws/ticket_info.php?ticket=90242 (Lancaster)
>> https://ggus.eu/ws/ticket_info.php?ticket=90243 (Liverpool)
>> https://ggus.eu/ws/ticket_info.php?ticket=90244 (RALPP)
>> https://ggus.eu/ws/ticket_info.php?ticket=90245 (Oxford)
>> https://ggus.eu/ws/ticket_info.php?ticket=89804 (Glasgow)
>>
>> Nearing the end of these. Lancaster and Oxford are down to their last
>> few files (which might need to be manually fixed at the site end- the
>> one left at Lancaster is lost for good). RALPP similarly have dark data
>> files that might need to be cleaned up locally. Liverpool are waiting on
>> atlas after giving them a new list of files. Glasgow have been asked for
>> a fresh file dump.
>>
>>
>> The Rest:
>> TIER 1
>> https://ggus.eu/ws/ticket_info.php?ticket=91687 (21/2)
>> Support for the epic VO on the RAL WMS. Request for pool accounts went
>> out but no word since. In progress (21/2)
>>
>> https://ggus.eu/ws/ticket_info.php?ticket=91658 (20/2)
>> Request from Chris W for webdav redirection support on the RAL LFC. As
>> reported last week waiting on the next release which has better,
>> stronger, faster webdav support in it. In Progress (22/2)
>>
>> https://ggus.eu/ws/ticket_info.php?ticket=91146 (4/2)
>> atlas tracking RAL bandwidth issues. The ticket was waiting on last
>> week's downtime to hopefully sort things out. Did the picture improve?
>> In progress (12/2)
>>
>> https://ggus.eu/ws/ticket_info.php?ticket=91029 (30/1)
>> Again from atlas, this is the FTS queries failing for some jobs
>> involving users with odd characters in the name ticket. A fix either
>> needs to be implemented by the srm developers or atlas need to
>> workaround by changing their robot DNs. On hold (27/2)
>>
>> https://ggus.eu/ws/ticket_info.php?ticket=90528 (17/1)
>> Sno+ Jobs weren't making their way to Sheffield, tracked to a problem
>> with one wms. As the cause of the problem is unknown and completely
>> unobvious it was suggested restricting Sno+ jobs to the working WMS, but
>> still no reply from Sno+. Waiting for reply (19/2)
>>
>> https://ggus.eu/ws/ticket_info.php?ticket=86152 (17/9/2012)
>> Correlated packet loss on the RAL Perfsonar host. Did last week's
>> network intervention fix things? Or maybe the problem evapourated (I'm
>> ever the optimist)? On hold (16/1)
>>
>> IMPERIAL
>> https://ggus.eu/ws/ticket_info.php?ticket=91866 (28/2)
>> It looks like atlas jobs were running afoul of some cvmfs problems on
>> some nodes. They've been given a kick, it's worth seeing if the problem
>> has gone away. In progress (28/2)
>>
>> GLASGOW
>> https://ggus.eu/ws/ticket_info.php?ticket=91792 (26/2)
>> Atlas thought that they had lost some files, but it turns out that they
>> just had bad permissions on a pool node (root.root) - the problem's been
>> fixed and Sam is investigating with his DPM hat on, whilst checking the
>> filesystems for more possible bad files. In progress (4/3)
>>
>> https://ggus.eu/ws/ticket_info.php?ticket=90362 (13/1)
>> All Glasgow's CEs have been switched over to use the GridPP voms server
>> for ngs.ac.uk, they just need some testing. Waiting for reply (25/2)
>>
>> SHEFFIELD
>> https://ggus.eu/ws/ticket_info.php?ticket=91770 (25/2)
>> lhcb complaining about the default value being published for Max CPU
>> time. No news from Sheffield beyond the acknowledgement of the ticket.
>> In Progress (25/2)
>>
>> DURHAM
>> https://ggus.eu/ws/ticket_info.php?ticket=91745 (24/2)
>> enmr.eu having trouble with lcg-tagging things at DUrham. Mike gave this
>> a kick, and asked if the problem has gone away. Waiting for reply (25/2)
>>
>> RHUL
>> https://ggus.eu/ws/ticket_info.php?ticket=91711 (21/2)
>> atlas having trouble copying files into RHUL. It's being looked at but
>> PRODDISK and ANALY_RHUL have been put offline. In Progress (28/2)
>>
>> https://ggus.eu/ws/ticket_info.php?ticket=89751 (17/12/12)
>> Path MTU discovery problems to RHUL. On hold since being handed over to
>> the Network guys, who were following it up with Janet. On hold (28/1)
>>
>> LANCASTER
>> https://ggus.eu/ws/ticket_info.php?ticket=91304 (8/2)
>> LHCB having trouble on one of Lancaster's cluster as they like to run
>> their jobs in the home directory rather then $TMPDIR. Forcing this
>> behaviour is harder then it should be in LSF, so it looks like we're
>> going to have to relocate the lhcb home directories. In Progress (1/3)
>>
>> https://ggus.eu/ws/ticket_info.php?ticket=90395 (14/1)
>> dteam jobs failed at Lancaster, due to our old CE being rubbish. Its
>> since been reborn with new disks, but embarrassingly I haven't found the
>> time to set a UI up for dteam and test it myself (which I intend to do
>> as part of testing the UI tarball, but that's a whole other story). In
>> progress (18/2)
>>
>> ECDF
>> https://ggus.eu/ws/ticket_info.php?ticket=90878 (27/1)
>> lhcb were having problem with cvmfs at Edinburgh, but the fixes
>> attempted can't be checked due to dirac problems at the site. In
>> progress (could be knocked back to waiting for reply) (28/2)
>>
>> BRISTOL
>> https://ggus.eu/ws/ticket_info.php?ticket=90328 (11/1)
>> The Bristol SE is publishing some odd values - zero used space. Waiting
>> on another, similar ticket (90325) to be resolved. On hold (11/2)
>>
>> https://ggus.eu/ws/ticket_info.php?ticket=90275 (10/1)
>> The CVMFS taskforce have asked for Bristol's CVMFS plans. One Bristol CE
>> is migrated to using it, with one left to go. On hold (5/2)
>>
>> EFDA-JET
>> https://ggus.eu/ws/ticket_info.php?ticket=88227 (6/11/2012)
>> Jet have exhausted all options trying to fix this biomed job publishing
>> problem. They're looking at reinstalling the CE to fix it, which seems
>> like using a sledgehammer to crack a walnut(but I don't have any better
>> ideas). On hold (25/2)