r3 - 10 Dec 2008 - 11:49:17 - RobertGardnerYou are here: TWiki >  Admins Web > LFCMeetDec10

LFCMeetDec10

Introduction

  • Meeting of the sub-committee to address LFC migration in the US cloud.
  • Coordinates:
    • Wednesday, Dec 10, 10am Central/5pm CERN
    • new phone (309) 946-5300, Access code: 735188; Dial *6 to mute/un-mute.
  • Background: SubCommitteeLFC, FileCatalog
  • Attending: Charles, Rob, Kaushik, Patrick, Paul
  • Apologies: Horst, John

LFC launch schedule

Oct 1  - LFC subcommittee  meeting to discuss launch
            plan (changes needed in all services and tools
            to switch a site) and resolve any voms
            group/role issues, etc
Oct 7 - AGLT2 : main burn in and validation on a single site...
followed by the rest of the sites:
Oct 14  - UC, UTA
Oct 16 - IU, BU
Oct 20 -  BU, SLAC
Oct 21  - OU, BNL
Oct 23 - WISC

New VDT release for LFC daemon stability

  • Released last week
  • Upgraded at UTA

Roles and permissions proposal (Kaushik)

We had many discussions about file and LFC permission issues during the past week. I summarize here a proposed plan for US ATLAS sites (Tier 1 and Tier 2 sites):
  • all ATLAS files should have ownership 'usatlas1' (files from both Panda production and central subscription). This means changing the ownership of some existing files at BNL. Tier 2's are hopefully Ok already (should be checked).
  • sites will map both voms roles, atlas/production and usatlas/production, to the same account 'usatlas1'. All other users get mapped to usatlas2-usatlas4.
  • LFC permissions will be configured to allow both atlas/production and usatlas/production roles group access (using secondary groups).
    • What is the definition of secondary groups? Hiro was going to send instructions?
  • filesystems will set up group and world to be read only.
  • LFC's will allow group write and world read.
  • user jobs will follow the same convention, till glexec is ready for production. Then we will have to rethink the strategy for users.

Does anyone see a problem with this plan for USATLAS facilities? Cheers, Kaushik

  • Run tests at the Tier2; make sure all files owned as usatlas1. And only production roles have r/w.
  • Check LFC r/w only for production role.
  • Main focus for now is integrity of production datasets.
  • The LFC keeps DNs of users writing data. Might be able to exploit this for user dataset deletion.
  • Kaushik will send specific instructions to usatlas-ddm-l for sites to check.

cleanse proposal (Charles)

  • A new script available that deletes datasets from the top down: dq2site-cleanse.py.
  • Deletes datasets in the central catalog, subscriptions in DQ2, produces a set a SFNs that can be deleted locally. Can be trivially adapted for specific backends (eg. posix, or dcache).
  • Patrick - has run over UTA's PRODDISK. Finds 14K files for potential deletion. Looking at data in LFC - many more files (140K) that may be candidates for deletion. Investigating.
  • Note - Panda mover data is not registered in DQ2.
  • Will need to modify for un-registered data in PRODDISK. Set up to manage as a cache.
  • Patrick points out that if there are multiple SE's used by the LFC, it deletes all of them. Need to add support for multiple SEs.


-- RobertGardner - 09 Dec 2008

About This Site

Please note that this site is a content mirror of the BNL US ATLAS TWiki. To edit the content of this page, click the Edit this page button at the top of the page and log in with your US ATLAS computing account name and password.


Attachments

 
Powered by TWiki
This site is powered by the TWiki collaboration platformCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback