ATLAS SCCS Planning 02May2007
-----------------------------
9am, SCCS Conf Rm A, to call in +1 510 665 5437, press 1, 3935#
Present: Stephen, Wei, Chuck, Richard, Booker, JohnB
Agenda:
1. DQ2 Status/Web Proxy
Early this week or during the weekend CERN changed their ROOT
Certificate Authority so we had to change our installation to
follow their update or couldn't transfer files. Is working
now. Would have been useful to have been informed. Has also been a
problem at two other sites on OSG. Copied the new CA from the new
version of Globus, Globus and no longer releases patches with
updated certificates for the old version of Globus that we are
using. There is an official list of CAs that we should keep up to
date, need to make sure we are doing that.
- Users needing access to web services from batch
Don't know that the environment will support this generically in
the future. Perhaps the current ATLAS specific solution is the best
way forward. Ideally would have a specific set of on-site services
which contact specific off-site services.
For the moment can check the IP address of the node being used to
set the http_proxy if it is needed.
Other people (non-ATLAS) will probably have the same issue in the
future at SLAC. Should address their (whoever they are)
requirements as they come up.
2. Tier-2 Hardware
One storage machine has the OS. Should get two of the machines up
and running, allow Len to do some testing with the third
machine. There is some question about how many parity disks we
want, one or two. There is some discussion at HEPiX about how long
it takes to reconstruct an array after loosing a disk, we would be
at risk during the reconstruction. Len will try to measure how long
it takes and try to get information from other labs. With double
parity it is more reliable but there is a write-time and space
parity. An element of the discussion would be the type of data on
it, if it was really just a cache of data stored elsewhere or if it
was the primary storage. Even if we believe it is just a cache an
worry would be how long it would take to reimport all the data
again from BNL (probably around a week). Could setup different
areas for production with double parity.
Local access should be preferred to use xrootd. Could also have a
different area for DQ2 for users to avoid them interfering with
production. We can setup the production area and DQ2 space then we
can decide what to do for users.
The water cooled rack is arriving, which is on track. Have a good
feeling about the providers, so expect it will continue
be on schedule. There have also been good support from Jim even
though he doesn't like the design.
3. xrootd/srm
Have the machine requested. Once Booker is off the Hot Seat he'll
install SL3 on it.
During last weeks Facilities meeting Boston said they preferred
gsiftp. The person that operates the BNL DQ2 said SRM gave them a
set of problems. They thought they could get rid of FTS if they
didn't need to use SRM... not clear what the right picture is. SRM
has put and get methods which use SRM copy method, but SRM copy uses
another protocol (generally gsiftp).
There was a discussion today at the Grid Deployment Board on the
support of the CASTOR-XROOTD. CERN clearly couldn't support this
themselves. SLAC will support XROOTD but this is not a core
part. There should be some discussion about how this gets
supported, as we are currently bottle necked on Andy's time. ALICE
should probably work with SLAC to somehow arrange support or
collaboration. Could currently support the interface of xrootd to
everything.
Should have a discussion somewhere about using the PetaCache for
the ATLAS Tag data.
4. AOB
None.
Action Items:
-------------
070502 Stephen Email Gordon about his action item
070502 Stephen Arrange meeting about ATLAS TAG data on PetaCache
070502 Wei Check CA certificate update mechanism
070321 Gordon Discuss perception of SLAC Tier-2 with external folk.
070404 no info
070411 no info
061108 Richard Discuss with SLAC Security longterm approach to ATLAS VO
061115 No information.
061213 Nothing happened yet.
070103 No information.
070110 Richard & BobC in Denver, Stephen will email them.
070124 Don't know the status.
070131 Don't believe this happened.
070207 Have not done this. Randy has talked to Heather, didn't
have any time to comment today but she is aware about
it. Will treat each VO as an enclave, if you are using
anonymous accounts need to be able to show how ran a job
and when. The main issue is that VOs are not legal
entities and anyone can declare themselves a VO. Would
need to actually test that the required information can
actually be found.
070221 No info.
070228 No info.
070314 No info.
070321 No info.
070404 No info.
070411 No info.
070418 No info.
070425 No info.
070502 Drop till concrete action comes up.
