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.
|