Changes between Initial Version and Version 1 of tier-one-meeting-20170926

09/26/17 15:17:53 (4 years ago)



  • tier-one-meeting-20170926

    v1 v1  
     2= dCache Tier I meeting September 26th, 2017 = 
     3[part of a [wiki:developers-meetings series of meetings]] 
     5== Present == 
     6, IN2P3(), Sara(), Triumf(), BNL(), NDGF(Ulf), PIC(), KIT(Samuel), Fermi(), CERN() 
     9= Agenda = 
     11(see box on the other side) 
     13= Site reports = 
     15== NDGF == 
     17Currently going quite well. 
     19Finally got the Danish pool online. 
     21Started -- checksum of all the files -- 2.5x10^6 files => 1 week to complete checksum. 
     23When starting up -- the pool doesn't check whether the file is acceptable permissions on start-up.  This is only discovered when trying to read the file (e.g. checksum ) 
     25Ulf to open a ticket. 
     27== KIT == 
     29Everything is running fine 
     31Upgraded ATLAS instance -- everything work, but update took a long time. 
     33=== Database locks === 
     35Liquibase seems to lock the entire database -- could it lock just the table it is operating on? 
     37This would allow upgrades to happen concurrently (e.g., pinmanager, srm, spacemanager, ..) 
     39Paul suggested placing the different services in different databases (possibly keeping them within the same DBMS system).  This is now the default configuration, although many sites have the old deployment with all non-chimera databases in a single database called "srm". 
     41=== GPFS logical manager issue === 
     43RT ticket 9217. 
     45After some discussion, the desire is to have a dCache pool start so that data stored on the pool can be migrated off onto another pool. 
     47I.e., have a pool start in "emergency mode" where it does not attempt to modify any data and allows only pool-to-pool transfers. 
     49=== Pool startup === 
     51RT ticket 9214. 
     53The fast switch from disabled to read-only is appreciated; however, the full start-up still takes a long time. 
     55The concern is that, if they need to restart all pools then ATLAS cannot write data until the first pool has completed its start-up. 
     57After some discussion, it seems that the pool is CPU bound, using a single thread. 
     59= Support tickets for discussion = 
     61[Items are added here automagically] 
     63= DTNM = 
     65Same time, next week.