VOMS Roles support at CMS GRID sites

Introduction

• Summary of VOMS Roles that need to be supported at CMS GRID sites
• Percentage of resources assigned for every VOMS role
  • Additional free resources should be awarded to other roles according to the resource percentage or priority
  • A single role should be able to take over all resources if all other roles don't have any work to do
• Pool accounts for the mapping of various VOMS groups and roles are strongly recommended
  • The lcgadmin Role can be mapped to a single account (this a legacy from the times when we installed CMSSW with this role, and that only supported a single account)
• The lcgadmin role is used to send most SAM tests
  • Needs almost no fair share (about 1 short job per hour and CE)
  • Needs highest priority to claim the next available slot in order to run SAM test as quickly as possible
• A note about national VOMS groups, e.g. cms:/cms/dcms (Germany), cms:/cms/escms (Spain) and many others
  • Used by various sites to treat their national users, e.g. to gain write access to the storage
  • Proxies with national groups are valid and must not fail at any site
  • For sites not implementing any special functionality for national VOMS groups should treat them like cms:/cms (just plain CMS voms "user" proxy")
  • The VOMS-admin interface provides
    • A full list of groups
    • A full list of roles
    • where not all require a dedicated treatment
• The following rules are addressing the pledged resources

Tier-1 sites

• Last major update June 2015:
  • Main T1 usage pattern:
    • At least half of the pledges resources should be reachable via multi-core pilots
      • The present "standard WLCG multi-core pilot" takes 8 cores
    • With disk/tape migration in place we want a low but ~continues flux of analysis jobs at Tier-1s
    • Analysis jobs sent via GlideinWMS (VOMS role=pilot) should take about 10% of the pledged slots, min 50 slots
      • This should allow for regular execution of glexec SAM test
    • t1production role is not used anymore after the GlideIn WMS frontends were merged, only the production role is used from now on
      • prioritization is done on the frontend level => fractional shares within the CMS T1 allocation are not needed anymore
    • disk/tape separation allows to open the T1 CPU resources for analysis accessing samples on the disk endpoints
  • Remarks on share policy:
    • available CPU resources should be assigned 90% to production role work and 10% to jobs sent via VOMS role pilot (those pilots are taking actually both production and analysis payloads 50/50
    • remaining share can be given to no role with lower priority

Tier-2 sites