Monday 20th January 2014, 14.30 GMT</br>
There are 42 Open UK tickets this week. Where did they all come from? Let's take a look.
EFDA-JET</br>
https://ggus.eu/ws/ticket_info.php?ticket=97485 (21/9/2013)</br>
LHCB jobs failing at Jet. The Jet chaps have just fixed an SSL problem at their site, so would like to see if this has fixed the LHCB problems. Waiting fore reply (20/1) Update - things are still failing, reading the error perhaps JET have picked up some wierd rpms somewhere?
(This also possibly solves the Jet gLeXeC ticket https://ggus.eu/ws/ticket_info.php?ticket=95295 UPDATE-SOLVED, the Jet guys put in a fix to JAVA to solve the keysize problem and things work now )
UCL</br>
https://ggus.eu/ws/ticket_info.php?ticket=100342 (16/1)</br>
Atlas are seeing transfer failures to/from UCL's dpm. Looks like an authentication problem, Ben might need a hand. In progress (20/1)
TIER 1</br>
https://ggus.eu/ws/ticket_info.php?ticket=100333 (16/1)</br>
Looks like this problem Tom and Chris spotted with one of the RAL WMSii has been solve, case can be closed. In progress (17/1) SOLVED
https://ggus.eu/ws/ticket_info.php?ticket=100343 (16/1)</br>
But the WMSses still bring us pain, here Chris documents that the RAL ones are still producing 512-bit proxies. Chris also helpfully links two other WMS tickets. In progress (17/1)
https://ggus.eu/ws/ticket_info.php?ticket=98122 (17/10/2013)</br>
But Tom provides another win, this time with the cern@school cvmfs repo. He's managed to get it working, able to put data into it, so this ticket can probably be closed too. In progress (17/1) SOLVED
https://ggus.eu/ws/ticket_info.php?ticket=100114 (8/1)</br>
But then the WMS try to spoil our buzz again with another ticket. Although I believe this is the forerunner to 100343 above. In progress (16/1)
BRUNEL</br>
https://ggus.eu/ws/ticket_info.php?ticket=100188 (10/1)</br>
Raul has provided Brian with the database dump from his SE (it should have landed in Brian's inbox), I think this ticket can be closed if the dump looks alright. In progress (16/1)
BRISTOL</br>
https://ggus.eu/ws/ticket_info.php?ticket=99910 (20/12/2013)</br>
LHCB problems at Bristol, due to ARC doing strange things to the environment. A few brave fixes have been tempted, but no joy. Waiting on feedback from the ARC developers - if that takes a while this ticket will need to be On Holded. In progress (14/1)
ECDF</br>
https://ggus.eu/ws/ticket_info.php?ticket=99794 (16/12/2013)</br>
Poking holes in the Edinburgh firewall for the perfsonar box. Any news from the IT overlords? I understand that there's a pending Edinburgh baby boom, so I'm not sure if anyone's still about? On hold (13/1)
GLASGOW</br>
https://ggus.eu/ws/ticket_info.php?ticket=98253 (21/10/2013)</br>
The "getting CMS working at Glasgow" ticket. It's looking almost as neglected as my gym membership. On hold (16/12/2013)
MANCHESTER</br>
https://ggus.eu/ws/ticket_info.php?ticket=97066 (5/9/13)</br>
Getting the Manchester perfsonar boxes back up and running. How goes it? On hold (7/1)
SHEFFIELD</br>
https://ggus.eu/ws/ticket_info.php?ticket=98594 (4/11/2013)</br>
The LHCB job uploading problem at Sheffield. It seems all parties have gotten stuck, so we need to decide where to go with this. On hold (8/1)
DURHAM</br>
https://ggus.eu/ws/ticket_info.php?ticket=99621 (10/12/13)</br>
Just making sure this ticket, with a bad node needing offlining, isn't forgotten about. On hold (19/12)
Similar with the Durham GLEXEC ticket https://ggus.eu/ws/ticket_info.php?ticket=95302 - it was On Holded over Christmas, but Christmas was a while ago now. In fact, with Creme eggs out, it must be nearly Easter already... right?
EXTRA EXTRA</br>
RALPP
https://ggus.eu/ws/ticket_info.php?ticket=100401 (20/1)
This nagios glexec alarm ticket which Chris quickly jumped on has been reopened on you guys. Just bringing it up as reopened tickets have a habit of sneaking under the radar. Reopened (21/1)
OXFORD</br>
https://ggus.eu/ws/ticket_info.php?ticket=100348 (17/10)
Atlas are getting a little ansy for some news on this ticket. And also don't seem to understand the waiting for reply state is for... Waiting for reply (21/1)
|