Answer in line...
On 5 Aug 2011, at 13:32, Ewan MacMahon wrote:
>> -----Original Message-----
>> From: Testbed Support for GridPP member institutes [mailto:TB-
>> [log in to unmask]] On Behalf Of Sam Skipsey
>> On 4 August 2011 22:42, Ewan MacMahon <[log in to unmask]>
>> wrote:
>
>
>>> Can I just clarify what the intended configuration is? It would appear
>>> from some of the responses that the /opt stuff has gone away, but
>>> there's still a need for an ATLAS_LOCAL_AREA variable and space; is
>>> that
>>> - still the case now?
>>> - expected to remain the case?
>>>
>>> And if so, what is it for?
>>
>> As Alessandra says, it's basically a place that contains your
>> setup.sh.local file for local ATLAS configuration. (Use of the CVMFS copy
>> of the conditions database is presently configured there, but the rest is
>> non-CVMFS local configuration you might have set up. So, if you were using
>> pcache, you'd have configured the alias for the pcache transfer script
>> here.) I can't see a way to avoid having to use this, since CVMFS is a
>> read-only filesystem on the client end, and I don't see ATLAS wanting to
>> move away from site-local configuration options.
>>
> If it's just that one file could I just pop it on the WNs
> with cfengine, or does it have to be editable by atlassgm,
> in which case I'll make some NFS space for it?
Here at least it sets some local versions of libraries to be used, as well as more general environment settings and paths, and for the time being they remain on NFS.
Clearly it would in principle be possible to have an area on CVMFS for both any local versions of libraries but also the site setups. No word on that though...
--Ian
>
> Also, what does it have to have in it to make the jobs look
> at CVMFS for the conditions database?
>
> Ewan
------------------------------------------------
Ian Collier [log in to unmask]
RAL Tier1 Fabric Team
+44 (0)1235 445440 +44 (0)7866 510075
------------------------------------------------
|