Hi,
I've simply mounted the existing software area onto the newer SL6 nodes,
with no changes at all - it is the same setup as the older SL5 nodes. The
name has sl5 in it (pest). The VO_SW_DIR variable is unchanged.
If anything else is needed, it could be sent in a ticket. I'd be glad to
do whatever is best. Personally, I think it might work as it is. If not, I
guess people will complain. To decide, we'd have to do a study and create
a VO consensus. That's the right thing to do, actually, but it's a lot of
work and is the buy-in there for it?
Steve
----------
ihepsoft1:/software/exp_soft_sl5
2635987968 2001361600 634626368 76% /opt/exp_soft_sl5
cvmfs2 102400000 54275866 48124135 54% /cvmfs/atlas.cern.ch
cvmfs2 102400000 216727 102183274 1%
/cvmfs/atlas-condb.cern.ch
cvmfs2 102400000 2732162 99667839 3% /cvmfs/lhcb.cern.ch
cvmfs2 102400000 86763 102313238 1%
/cvmfs/mice.gridpp.ac.uk
cvmfs2 102400000 16250 102383751 1%
/cvmfs/na62.gridpp.ac.uk
cvmfs2 102400000 5746325 96653676 6%
/cvmfs/hone.gridpp.ac.uk
>> -----Original Message-----
>> From: Testbed Support for GridPP member institutes [mailto:TB-
>> [log in to unmask]] On Behalf Of RAUL H C LOPES
>> Sent: 31 July 2013 12:29
>>
>> They've never written in that area. Neither Atlas or LHCB.
>> so... are we allowed to clean them?
>>
>
> For VOs that have moved to CVMFS, if your VO_XXX_SW_DIR environment
> variable point to CVMFS (as they should for at least LHCb, CMS and
> ATLAS), then you can definitely clean them up - VO software areas
> aren't mounted in a standard place, so if the environment doesn't
> point to them, there's no proper way the VO could find the old area
> anyway.
>
> For OS version upgrades, I'd definitely go with a new, blank area,
> but make sure to blank the CE tags areas in sync with that so that
> you're not advertising tags for things you don't have any more.
> I'm not sure anyone actually uses CE software tags for anything,
> mind, but it's the principle of the thing.
>
> Ewan
>
|