2. Authorization, Resource Management, Enforcement: The following are a list of user requirements.
The resource owner control must control
Who can run what code on what computer
How much of those resources can the person/code/project use.
For example, number of processors in cluster, total CPU time, disk space, memory.
Resources need to be controlled on different time scales
(e.g. daily, monthly, and yearly totals)
Resource owner can allow preemptive scheduling
Who can access what data (read and write authorization
may be different).
The Interface for the resource owner allows specifing authorization policy
It should be GUI based for ease of use
The GUI interface should be linked to a historical database
for rapid understanding of previous usage
Single interface for all users to all Grid Resources
Web based so that they can easily understand what they
are allowed to use for their code/project.
The web interface should be linked to a historical database
for rapid understanding of previous usage
These web views need to be able to span resources
Authorization errors
Errors that indicate authorization is denied need to be clear
to the user so that they can proceed to obtain proper authorization
Errors need to be at the same granularity as the authorization capability.
Error messages should alert the user who is reasonable for the
resource that they were denied to use.
The meaning of person/code/project is as follows
Person: identified by certificate
Code: Need to control what computers and codes are used
One person may control the code while another person
may control the computer it runs on.
Project: One user often works on more than one project.
e.g. DIII-D (machine), ITER (design),
NIMROD (simulation project)
For now, we are willing to trust the person to specify
what project each request is associated with.
Dynamic accounts
Desired by GS2
Can not be used exclusively at PPPL but will still be valuable.
Requriements by individual codes
GS2: who can run, dynamic accounts, number of processors, wall clock limit
on individual job (hard wired upper limit, formula to predict total time
or user supplied), GUI for resource owner control.
GYRO: who can run, dynamic accounts, number of processors, wall clock limit
on individual job (hard wired upper limit, formula to predict total time
or user supplied), GUI for resource owner control.
TORIC
MDSplus data access
Presently only local account mapping is used and this does not scale since
a new account is needed by each new person.
Need a solution that scales and gives fine granularity for data access.
In general, keep things simple.
When push comes to shove we opt for less security and more ease of use.
We want FusionGrid to be useful rather than secure and not useful.
