Hi
You want to make a change on a Friday afternoon? Why aren't you working for the Tier 1?!
Please don't change over the software area and conditions access at exactly the same time as when something goes wrong its easier to debug. Also there is potentially some caching issue if you are getting both conditions and software from CVMFS (some sites set different cache sizes) so its worth staggering any change.
I am not that familiar with the new mount point for CVMFS as RAL is still using the old one and that does require some links. I will be more confident in telling other sites what to do when its been done at RAL. Alessandra F. is probably the best person to ask as she has got both working at Manchester. Although you need to be quick as she is off on holiday on Monday.
If you do switch over to CVMFS then I (or atlas cloud support) will need to inform Alessandro de Salvo to switch off the install jobs.
Alastair
On 5 Aug 2011, at 14:47, Ewan MacMahon wrote:
>> -----Original Message-----
>> From: Testbed Support for GridPP member institutes [mailto:TB-
>> [log in to unmask]] On Behalf Of Alastair Dewhurst
>
> <massive snip>
>>
>>
>> Hope this helps, thanks for the responses so far.
>>
> It does, rather a lot I think. So, just to pin down some
> details, for a current/new type cvmfs setup one needs:
>
> - to set VO_ATLAS_SW_DIR to /cvmfs/atlas.cern.ch,
>
> - set a new variable ATLAS_LOCAL_AREA to point to a directory
> that contains a (preferably atlassgm writeable) file called
> setup.sh and also a setup.sh.local (both of while can presumably
> be copied from the current software area),
>
> - add:
> ATLAS_POOLCOND_PATH="/cvmfs/atlas-condb.cern.ch/repo/conditions"
> to the setup.sh.local
>
> Is that it? And does there need to be any co-ordination with
> ATLAS, and is there any reason that someone feeling suitably
> enthusiastic shouldn't just do this right now?
>
> Ewan
|