 |
 |
On Wed, Sep 13, 2017 at 10:07 AM Daniela Bauer < [log in to unmask]> wrote: > Hi Sam et al, > > gfal2 works with the LFC, as you noticed it's the RAL LFC that has a > problem. > It does... but the original design for GFAL2 didn't, as the LFC was supposed to be phased out initially! There's still a feeling from the GFAL2 guys that they don't really *want* it to support the LFC. > We need to get the experiments of the LFC though, but no-one from EGI > seems to be willing to handle this, like they did e.g. the withdrawal of > the WMS. > We are already running into problems here: > > https://groups.google.com/forum/?hl=en-GB#!topic/diracgrid-forum/xsMBwZKpwgU > (I can't get google to link to the start of the thread). > Once everything moves to EL7, we'll be shit out of luck. > > Does anyone know how to get EGI to formally withdraw support and order the > remaining VOs (t2k, snoplus, possibly leftover na62 and mice) of the LFC ? > I think mice will need the LFC until the end of their data taking as their > datamover uses it, but then they have their last run ever coming up in > about 2 weeks, so that's a very fixed time frame. > I can't think of a way to force things other than what's already been tried - there's been concerted efforts to get people to stop using the LFCs, but there's never been a will to force them (and, as I noted, there's even new experiments choosing LFC over other technologies explicitly). Sam > > Cheers, > Daniela > > > On 13 September 2017 at 09:37, Sam Skipsey < > [log in to unmask]> wrote: > >> Hi Steve, >> >> So, I'm in two minds - >> >> on the one hand, in the Glorious Future of GridPP, the LFC is supposed to >> mostly be deprecated (in favour of experiment specific frameworks for those >> who have them, or the DIRAC File Catalog for those who don't) - and, as you >> note, GFAL2 has explicitly not really supported the LFC since started >> several years ago (because the LFC was also supposed to be phased out back >> then). [I argued with the GFAL2 guys at the time, and complained at CHEP >> talks about it, but no-one seemed to care about it that much back then...] >> >> On the other hand, de facto, there's still use of the LFC, so it needs to >> work for the people who still use it - and, indeed, there are new >> experiments which decided to choose the LFC as their technology for >> cataloging files (and presumably those people still use the old GFAL-1 >> tools with lcg-ls etc?) >> >> I think if you're running the service though, it should definitely still >> work reliably, and it doesn't seem like the GridPP LFC does. >> Let's do some testing of it... >> >> Sam >> >> >> >> On Tue, Sep 12, 2017 at 1:18 PM Stephen Jones <[log in to unmask]> >> wrote: >> >>> Hi Guys, >>> >>> Opinions wanted ... should I care about this: >>> >>> $ export LFC_HOST=lfc.gridpp.rl.ac.uk >>> >>> $ lcg-ls lfn:/grid/dteam/tutorial/Test-grid3.txt >>> [LFC][lfc_statg][] lfc.gridpp.rl.ac.uk: >>> /grid/dteam/tutorial/Test-grid3.txt: Could not secure the connection >>> lfn:/grid/dteam/tutorial/Test-grid3.txt: Communication error on send >>> >>> Then same command again ... >>> >>> $ lcg-ls lfn:/grid/dteam/tutorial/Test-grid3.txt >>> lfn:/grid/dteam/tutorial/Test-grid3.txt >>> >>> In short, sometimes I see the file, sometimes it says "Communication >>> error on send". >>> >>> But is lcg-ls (etc.) still needed? Is it all "GFAL" now... >>> >>> Cheers, >>> >>> Ste >>> >>> >>> -- >>> Steve Jones [log in to unmask] >>> Grid System Administrator office: 220 >>> High Energy Physics Division tel (int): 43396 >>> Oliver Lodge Laboratory tel (ext): +44 (0)151 794 3396 >>> <0151%20794%203396> >>> University of Liverpool >>> http://www.liv.ac.uk/physics/hep/ >>> >> > > > -- > Sent from the pit of despair > > ----------------------------------------------------------- > [log in to unmask] > HEP Group/Physics Dep > Imperial College > London, SW7 2BW > Tel: +44-(0)20-75947810 <020%207594%207810> > http://www.hep.ph.ic.ac.uk/~dbauer/ >