Hi Daniela,
On Thu, 1 Dec 2016, Daniela Bauer wrote:
> Hi Marcus,
>
> I've replicated the content from UKI-SCOTGRID-ECDF1-disk to
> UKI-LT2-IC-HEP-disk (at least all the bits that are contained within
> the dirac catalogue):
>
> Number of files copied: 1942
> Data copied: 7.041 GB
> So they should stay accessible no matter what happens to the ECDF SEs.
Thanks!
The SE UKI-SCOTGRID-ECDF-disk will remain like it is only with added space
in the future (hopefully before the end of the year).
>
> The GridPP dirac server is a standard 'generic' dirac server - most
> stuff LCHb does eventually trickles down to it, but it's not a
> one-to-one mapping. LHCb only solve their specific problems and not
> the more generic cases we tend to face. The last time we tried to use
> xrootd, the dirac server just broke, so it's turned off. We now have a
> dirac test instance which we use to debug such things, so whenever
> your SE is ready, we can have a look.
SE UKI-SCOTGRID-ECDF-disk is ready and in production. What would be needed
to do to access it through the test dirac server, for example by the
central nagios tests?
Cheers,
Marcus
> As dirac ships it's own externals which at the moment include lcgutils
> it's probably going to stay around for a while.
>
> Cheers,
> Daniela
>
> On 30 November 2016 at 15:01, Marcus Ebert <[log in to unmask]> wrote:
>> Hi Daniela,
>>
>>
>> On Wed, 30 Nov 2016, Daniela Bauer wrote:
>>
>>> Hi Marcus,
>>>
>>> as for the bdii both SEs are still there:
>>> lx01:uki-lt2-ic-hep :~] lcg-infosites --vo lsst se | grep ecdf
>>> 21614809465 37398041181 SRM gridpp09.ecdf.ed.ac.uk
>>> 87167372114 11788674384 SRM srm.glite.ecdf.ed.ac.uk
>>> 140325881655 423808716 SRM srm.glite.ecdf.ed.ac.uk
>>>
>> Yes, that's the confusing part and I'm not sure why srm.glite appears 2
>> times there too...
>>
>>> It might just be cached somewhere, or if it's DPM I remember it being
>>> particularly recalcitrant in letting VOs go.
>>>
>> Ah, yes that could be. I'll look into it more once the files are copied and
>> deleted. Maybe the lsst vo has to be removed to not appear on dpm-listspaces
>> anymore.
>>
>>
>>> There's no xrootd in dirac, I thought gfal2 was the official
>>> replacement for the lcgutils.
>>> I'd suggest once the new SE is setup we see how it goes and what kind
>>> of adjustments we need to make.
>>>
>> That's interesting. Is this a feature of GridPP dirac?
>> We use xrootd through LHCb's dirac I believe and I can see in their
>> configuration for the sites that xrootd is a supported protocol at least for
>> their Dirac installation.
>>
>> For us there will be no new prodcution SE, only the one behind srm.glite
>> which will also get the disk space currently used by gridpp09. I recognized
>> the problem when looking to the new nagios tests for srm.glite that are in
>> place now.
>>
>>
>> Cheers,
>> Marcus
>>
>>
>>> Regards,
>>> Daniela
>>>
>>> On 30 November 2016 at 14:17, Marcus Ebert <[log in to unmask]> wrote:
>>>>
>>>> Hi Daniela,
>>>>
>>>> Yes, I'm in the process of copying everything over to
>>>> UKI-SCOTGRID-ECDF-disk
>>>> and then wanted to delete the old files
>>>> (all through the dirac tools which should make sure the file catalogue
>>>> stays
>>>> correct, I hope)
>>>>
>>>> I know I asked in the past how to make a SE visible for Dirac through
>>>> BDII,
>>>> but can't figure out right now what is needed to have it removed again. I
>>>> removed lsst from /var/lib/bdii/gip/glite-info-service-srm2.2.conf but it
>>>> still appears in the list. Do you know of any other place where it needs
>>>> to
>>>> be removed?
>>>>
>>>> Another SE related issue that came up while looking to lsst jobs is the
>>>> transfer protocol used. On our SL7 worker nodes there are no lcg-utils
>>>> available. To configure the site in dirac to use the xrootd protocol
>>>> instead
>>>> of srm, is this something that also needs to be done through the side
>>>> BDII
>>>> or centrally on the dirac server?
>>>> (sorry for mixing 2 issues here)
>>>>
>>>> Cheers,
>>>> Marcus
>>>>
>>>>
>>>> On Wed, 30 Nov 2016, Daniela Bauer wrote:
>>>>
>>>>> Hi Marcus,
>>>>>
>>>>> Do you want these files transferred to UKI-SCOTGRID-ECDF-disk
>>>>> (srm.glite.ecdf.ed.ac.uk) ?
>>>>> If you remove lsst from the bdii, the SE on dirac will automatically
>>>>> update.
>>>>> However, the real problem is that the files are registered in the
>>>>> dirac file catalogue and they will have to be moved (deleted and
>>>>> reregistered) within the catalogue - one of the reasons why switching
>>>>> SEs is somewhat frowned upon.
>>>>>
>>>>> Regards,
>>>>> Daniela
>>>>>
>>>>>
>>>>>
>>>>> On 28 November 2016 at 18:07, Marcus Ebert <[log in to unmask]>
>>>>> wrote:
>>>>>>
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I need to move and reinstall a SE and in the process the data on it
>>>>>> will
>>>>>> get
>>>>>> lost.
>>>>>> It's mostly used for ATLAS tests in the past, but was also integrated
>>>>>> into
>>>>>> Dirac as a SE for LSST.
>>>>>> Does anyone knows what is needed to have it removed from the list that
>>>>>> one
>>>>>> gets with dirac-dms-show-se-status?
>>>>>> I'm writing out the list of files for LSST on that machine right now
>>>>>> and
>>>>>> will replicated it to our other storage element. Once that is done, the
>>>>>> LSST
>>>>>> support needs to be removed from that SE(UKI-SCOTGRID-ECDF1-disk).
>>>>>>
>>>>>>
>>>>>> Cheers,
>>>>>> Marcus
>>>>>>
>>>>>> --
>>>>>> The University of Edinburgh is a charitable body, registered in
>>>>>> Scotland, with registration number SC005336.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> The University of Edinburgh is a charitable body, registered in
>>>> Scotland, with registration number SC005336.
>>>
>>>
>>>
>>>
>>>
>>
>> --
>> The University of Edinburgh is a charitable body, registered in
>> Scotland, with registration number SC005336.
>
>
>
>
--
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
|