Rod, the UK T1 funding does not include people specifically for each
VO. There are UK-funded people on each experiment but we expected that
contacting the experiment centrally would result in this work being
delegated appropriately.
John
> -----Original Message-----
> From: LHC Computer Grid - Rollout
> [mailto:[log in to unmask]] On Behalf Of Rod Walker
> Sent: 20 September 2005 20:10
> To: [log in to unmask]
> Subject: Re: [LCG-ROLLOUT] Removal of Files from Durham SE
> (gallows.dur.scotgrid.ac.uk)
>
> Hi,
> I`m talking about Atlas Tier 1's, and these will have someone
> in the atlas
> VO. Anyone in the Atlas VO can replicate and delete Atlas
> files - tragic
> but true. There are tools to do this and I`m afraid people
> need to get
> their hands dirty.
> I`m thinking the Atlas T1's must have some responsibility to
> service the
> sites in their area who accept the Atlas VO, bearing in mind
> that some of
> those sites will not have local Atlas people. This cannot be done
> centrally, and the Tiered system must be something more thatn
> a funding
> construct.
>
> Changing a site name, or root path, shouldn't difficult in either the
> distributed or cental calalog model. It is made more awkward
> when the host
> and root path are buried in the sfn. I think this is still
> the case with
> LFC and from a (laymans) Db design perspective is perverse.
> Traditionally
> you would have a table, SITE HOSTNAME ROOTPATH, and only
> reference the
> SITE in the sfn.
>
> Cheers,
> Rod.
>
> Ps. The Atlas dataset location catalog will contain references to the
> local LFC's presuamably by hostname. We should certainly have
> table similar to the above so that host changes can be made
> in 1 place.
> The full sfn is only stored in the site LFC and every entry
> would need to
> be changed if the host or path changes.
>
> Pps. We certainly must use available disk space at T2's. I
> was refering to
> opportunistically used non-atlas sites with small disk allocations.
>
|