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.