Attendance … I don’t see the point (am I missing something?)

 

1.  DQ2 v0.2.12 upgrade:

 

-          Sites done so far: BNL, BU, UTA (2 instances), SLAC (on the new system; the current remains as is and will be phased out in few months)

-          Active work at UMich

o        New instructions and new package (Need more volunteers to test them. OU, interested?)

o        Pbs. from the 64bit OS:

§         Need 64bit MySQL and Python provided as local service and pointed at during the installation.

§         The creation of a new MySQL would consequently require the migration of the current LRC data.

§         If the above services are provided and the LRC data is migrated to the new catalog, the rest of the Dq2 installation should work.

o        Patrick and Shawn will work it (this afternoon).

o        Additional problem: repeated callbacks (since Jan). Why? Under investigation.

-          NEXT: OU

-          NEXT: MW

 

2. LRC upgrade:

 

-          Necessary to overcome the limitation to 256char in physical file names

-          Requires a new schema, which requires MySQL v5. Also requires a modified version of POOL, without an internal limitation of filenames to 256char. Available (at least) at BNL.

-          So the stack of upgrades is:

o        Upgrade to MySQL v5

o        Apply new schema

o        Replace old POOL with the “enhanced” version

o        Migrate old LRC data

o        Recompile Python MySQL libs (to integrate the new MySQL v5 libs)

o        Recompile/Refresh DQ2 install(?)

-          The above assumes that no POOL usage exists outside PANDA/Production (otherwise the users will find themselves with the wrong POOL version). User access is assumed to be performed through the web interface.

-          BNL will setup a Twiki page/site to work together at the details of the upgrade (Dantong).

-          Hiro will place his instructions (from BNL’s experience) on this page and all are encouraged to contribute.

-          When all the details, concerns and issues will be worked out, we should obtain a “community sanctioned” recipe… that we’ll follow on a mutually agreed schedule.

 

3. AOD replication:

 

-          The US data management model anticipates the replication of 100% of the AOD dataset at each T2 site (except SLAC – 10%) to support analysis activities.

-          The recent substantial increase in AOD event size prompts concerns with the T2’s ability to support such a large dataset.

-          Is this model still feasible?

-          A more accurate estimate of total needs will be available soon.

-          Currently available:

o        MW ~50TB

o        SW 12TB (addt’l 50TB+ in few weeks)

o        SLAC 4TB (+18TB mid March)

o        AGL ~ 35TB (+21TB on order)

-          The distribution of data will be handled automatically (given the subscription percentage) from T1

-          The proper balancing of workload at split installations is a concern.

-          To be continued…

 

4. Site updates:

 

-          AGL:

o        Order placed (Dell), quad cores, 21TB (RAID50). Storage initially served via NFS. Later will try (grid)NFS over dCache.

-          MW:

o        “Proxy not valid” errors observed at MWT2_UC. Under investigation.

-          BNL:

o        Farm upgrade to SL4

o        dCache upgrade yesterday. Still working at the optimization.

o        DQ2 backlog formed due to the disruption. Currently clearing up.

-          SW:

o        Work in progress at the new cluster installation.

-          SLAC:

o        Requisition out this week. Installation expected in early April.

o        Prototype xrootd installation in progress (gsiftp frontend), using small size federation.

o        DQ2 site functional.

o        Panda preparations in progress.

 

5. AOB:
   1. Don’t forget the UCSD T2/T3 meeting travel arrangements.

 

 

Have a nice week!

 

R