PAGs, POGs, and DPGs are allowed to specify a limited number of people who will have special privileges at the Tier-2s, both for CPU as well as write access to storage. The special privileges entail:

• priority batch CPU access to half of the 50% of the pledged resources for analysis at all Tier-2s.
• write access into /store/group/ at all Tier-2s associated to that group.

We assume that on average a lot less than 25% of the CPU resources at the Tier-2s will be used that way. The policy is thus set up for a burst but not average use. We will monitor usage.

The space used in /store/group/ will have to be accounted by the site's system adminstrators towards the quote the group has at that site.

Conveners' Responsibility

The conveners fill out the following table to indicate their priority users, and then send an email to the AnalysisOps hypernews for information,also mention who has been removed from the list. They do this every time they want to change something. However, we would like the groups to not change the names more often than once every few months. We will try to keep the actual privileges available as implemented in the CMS VOMS in synch with this Twiki table. It will be the responsibility of the people listed there to subscribe to this role using the CMS VOMRS interface. It should take not more than a few working days to get an approval email. The dynamic list of people authorized for the priorityuser role is here

• user's DN is the output of the command: grid-proxy-info -identity (this will be used to access the StoreResults status web information, see below)

Priorityusers' Responsibility

• Request permission to use the role
  • following these instructions
• Create and use a proxy with the priorityuser Role when doing high priority work
  • following these instructions
  • that proxy is needed for every crab command, whenever you logout or proxy expires, do it again
  • make sure you add to crab.cfg, in the GRID section the line
    • role = priorityuser
• Select the appropriate stage-out directory /store/group/"groupname" at one of your group's "T2_XX_YY"
  • for the correct spelling of the "groupname" follow the CMS.PhEDEx group convention
  • download GetStorageCfgFromTFC.py into a CMSSW release area
  • execute python GetStorageCfgFromTFC.py --site="T2_XX_YY" --lfn=/store/group/"groupname" (replace "T2_XX_YY" and "groupname")
  • include the script output in the USER section of your crab.cfg
• Beware: by default all your shell sessions on the same host use the same proxy, do not try to operate at same time on normal task and priorityuser tasks (which is possible, but it is an expert operation and if you have no idea how to do it properly, it is better you do not do it). Using different roles on different machines (even simply two lxplus nodes) is OK.

Tier-2 Sites' Responsibility

In order to facilitate data transfers of physics results between Tier-2 sites, DDT has organized the commissioning of data transfer links in PhEDEx between Tier-2 sites associated with the same analysis group. Details can be found here. Priorities for link commissioning are suggested by the groups themselves. In practice, if groups have one or two Tier-2 sites with good connectivity in both directions to all of the others in a group, then data can be transfered via these "hub" Tier-2 sites between any of the other Tier-2's with at most 1 "hop" via the hub. Tier-2s should make sure that the -ignore and -accept options in their FileExport and FileDownload agents of PhEDEx are set up properly to enable transfers from other Tier-2s in their groups.

Please grant write access for VOMS CMS role=production to /store/results/ and for role=priorityuser to /store/group/. Please also check your TFC for these new LFN conventions. In addition, for data replications, PhEDEX needs to have read and write access on /store/results/.

Please configure your batch system that the share from the CMS pledges is 50% for role=production,the other half to be distributed 25% for role=priorityuser and 25% for "normal" CMS users. The appropriate way for the setup is to use a mapping to Pool Accounts in all three cases.