UConn-OSG Use Policy Statement

Richard Jones, University of Connecticut
last updated May 8, 2013

User Policies:

  1. Your use of the Open Science Grid (OSG) is subject to your acceptance of the OSG User Acceptable Use Policy (AUP).
  2. Access to UConn-OSG resources is provided via GUMS/VOMS authorization software and is restricted to OSG member VOs. Users are mapped to VO group accounts exclusively when they obtain VOMS proxy credentials for their session. No individual accounts are permitted.
  3. Any planned event that would impact the regular operation of processing at our site will by preceded by public notices on the UConn cluster message board at least 24 hours in advance. Unplanned outages will be reported on the same message board as soon as the issue is detected, together with an estimate for the time when normal operations are expected to resume.

Processing Policies:

  1. UConn-OSG consists primarily of AMD x86_64 and Intel i7 processors, together with a smaller number of older 32-bit nodes. Compute resources are shared between local users and OSG VO group accounts, with priority given to local users. There are 516 job slots on the UConn site currently. The Condor scheduler configuration allocates approximately half of the processors to OSG Gluex jobs, and opportunistic running to the other half subject to preemption by local jobs. Compute resources are made available to non-Gluex OSG VO users on an opportunistic basis.
  2. All jobs are limited to a maximum of 72 hours of runtime. Jobs exceeding this limit may be terminated without warning and removed from the queue of executable jobs.
  3. Jobs must be able to run within a small local filesystem on the worker nodes pointed to by the environment variable $OSG_WN_TMP, which have about 10GB of local storage capacity and 1GB of resident memory per job. This local per-job storage quota includes all files that are locally staged during job startup, plus whatever output and log files are generated by the job during execution. Jobs that overflow this limit should consider how to make use of space in the $OSG_APP and $OSG_DATA areas (see the Storage section below), and also the local dCache Storage Element.
  4. All access to processing resources by OSG users is opportunistic. Jobs submitted by local users have priority over those submitted by non-local VO members. Any jobs that are preempted to allow a local user's job to run will be requeued and eventually restarted. Any previously executed work performed by such jobs will be lost, and the job will be restarted from the beginning.
  5. UConn-OSG may suspend or ban DNs, VOs, Roles and/or CAs as necessary to assure operations. Under normal running conditions, we will attempt to contact the affected VOs and/or users through the OSG Operations Center and attempt to provide up to 4 hours of warning before taking these actions. During some running conditions we may be forced to take this action without warning.
  6. VOs and VO members that desire to use UConn-OSG grid resources must initialize their credentials using: 
    $VDT_LOCATION/voms/bin/voms-proxy-init
    Those VOs and VO members that fail to use voms-proxy-init may be blocked from accessing UConn-OSG grid resources.
  7. UConn-OSG requests that VOs submit using Condor Grid Monitor. VOs unable to submit through grid monitor may be limited in the number of active processes allowed. UConn-OSG requires that VO's submitting multi user pilot jobs use the glexec package to validate the grid credentials of the actual user who has submitted the job.

Storage Policies:

The following three canonical storage areas are provided for the use of VO's to install software builds, stage shared data that is accessed by multiple jobs, and locally cache large data files in the local dCache Storage Element. Remote access to any of these areas should be over gridftp, or through SRM in the case of the SE.
  1. $OSG_APP is an area for installing software builds of the applications to be run by a given VO on this site. It is mounted read/write from the head node, accessible to remote users via the jobmanager-fork queue on the CE. It is mounted read-only on the worker nodes. Default quotas are 30 GB for all the users in a VO. VO's that have more than one user may request that only a single privileged user be allowed quota to write files. By default, the directory has permission mode 1777.
  2. $OSG_DATA is a NFS-mounted area which is accessible read-write from the head node, accessible to remote users via the jobmanager-fork queue on the CE. It is mounted read-only on the worker nodes. Guest VO's are granted a small default quota, which is shared between all members of the VO. The quota for a guest VO can be increased upon request.
  3. OSG also defines $SITE_READ and $SITE_WRITE which are URL's that point to a local storage element accessible by SRM and gridftp for reading, and by SRM for writing. This is volatile storage with a total available space of 100 TB. Files are deleted, if necessary, on a least recently used basis and there are no quotas. This space is not backed up to tape.
  4. VO's can request opportunistic storage on the UConn SE in order to stage data locally on the site, and make job startup more efficient. Space allocation up to 1 TB will be made available to VO's upon request, subject to availability of free space on the SE.