Project is a way to categorise jobs independently of users or groups.
Project can be a key for accounting resources consumed, by a project or reservation.
Characteristics:
Each reservation can belong to at most one project.
Jobs within the reservation will not automatically inherit the reservations project tag. The tag for jobs in the reservation has to be explicity requested using the -P option.
Projects are not tied to users or groups.
Type String. Can contain any characters except for the following: Slash ("/"), left bracket ("["), right bracket ("]"), double quote ("""), semicolon (";"), colon (":"), vertical bar ("|"), left angle bracket ("<"), right angle bracket (">"), plus ("+"), comma (","), question mark ("?"), and asterisk ("*").
Access to the attribute from server hooks.
Usage - pbs_rsub -P <project-name
Proposed Solution :
The proposed solution aims at making use of the already present project attribute in pbs_ifl and registering it to reservations by editing the reservation attribute XML. We then make changes accordingly to the reservation header file and add a link between the job and reservation project attribute. This attribute is available only to the server and is not a scheduler attribute.
Please suggest any changes or an alternate approach if needed.
Please include example accounting log messages showing how the project association will be represented and in what records (“U”, “Y”, “B”, “K”, etc.).
The term used int he EDD “server hooks” is too ambiguous for me, since there are vastly different types of server hooks, such as those associated with specific jobs, specific reservations, and also periodic and provisioning hooks which are not associated with individual jobs or reservations.
An example of how the attribute is expected to be accessed from a “typical” hook would also be helpful.
I’d like to see us list characters that CAN be used in the project string, rather than those that cannot. Otherwise, someone may try to name their project “” (unicode snowman). That is a bigger topic than just this EDD, though.
Will pbs_ralter be able to change the associated project? On the one hand, pbs_ralter can be used to change the reservation name, so I think for consistency it should be able to change the project as well. On the other hand I am assuming the project association is primarily useful from an existing pbs_rsub hook event, and we do not currently have an event triggered by pbs_ralter, so not allowing it to be changed in pbs_ralter is probably more desirable for now. I am curious to hear your thoughts.
What about ASAP reservations? Would the project association from a job that turns into an ASAP reservation carry forward into the reservation?
The EDD should address any special considerations/restrictions for standing reservations. For example, must the project only be set on the standing reservation as a whole? This question and certainly this example is relevant only if pbs_ralter can change the project on an existing reservation, I suppose.
I feel that the Project field should be an ACL on the Reservation by default so it will only accept jobs with the same Project specified. If no project is specified for a reservation then there would be no project ACL on the reservation (excepting that it may use the default/global project that jobs inherit).
A job converted to an ASAP reservation should preserve the Project attribute?
In my view a Standing Reservation should inherit the project to all instances.
” (unicode snowman). That is a bigger topic than just this EDD, though.