| Summary: | PBS launch configuration should make better use of queue information | ||
|---|---|---|---|
| Product: | [Tools] PTP | Reporter: | Greg Watson <g.watson> |
| Component: | RM.PBS | Assignee: | Project Inbox <ptp-inbox> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | arossi, roland |
| Version: | 4.0.2 | ||
| Target Milestone: | --- | ||
| Hardware: | Macintosh | ||
| OS: | Mac OS X | ||
| Whiteboard: | |||
|
Description
Greg Watson
Sure, this shouldn't be too difficult to do. I'll take a look. The Launch Tab for PBS now displays the list of machine queues available as a combo box, values derived from the IPQueue elements sent during RM model definition. The auxiliary method for populating the box is improperly encapsulated (it belongs in the Wizard Page), but this would have required an API change. Also, "destination" must be a fixed item in the PBS client's attribute name vocabulary for this to work. Committed to HEAD and 4_0. I'd suggest a couple of other things. This field should probably be first in the list of attributes, since it is probably the most important. How are the attributes ordered? Second, "destination" seems a strange designation. Is this PBS standard? I would have thought "Queue" would have been better, or at a minimum "Destination". (In reply to comment #3) > I'd suggest a couple of other things. This field should probably be first in > the list of attributes, since it is probably the most important. How are the > attributes ordered? Second, "destination" seems a strange designation. Is this > PBS standard? I would have thought "Queue" would have been better, or at a > minimum "Destination". The user can order them any way she wants, through the template. The default templates certainly can put it first. All the attribute names are exactly the same as what PBS specifies in its internal API. The shell command is -q. The description field reads: "Designation of the queue to which to submit the job." Hover over destination, and you will also see the message: Format: queue[@server] Since we are processing attributes dynamically now, we can't really do arbitrary mappings because that would require knowledge of the attribute names ahead of time; however, since the client does need to know about this particular attribute, the mapping could be hidden from the user and "queue" used instead in this case.
> Since we are processing attributes dynamically now, we can't really do
> arbitrary mappings because that would require knowledge of the attribute names
> ahead of time; however, since the client does need to know about this
> particular attribute, the mapping could be hidden from the user and "queue"
> used instead in this case.
On further reflection, PBS followed the original model of using the pbs API names, but since the client actually contructs the shell scriipt, it really isn't necessary. The XML file on the proxy side could arbitrarily change these names, so long as the mapping to the attribute flags is known somewhere.
And, this reminds me that this latter mapping was not addressed in our original plan, so I need to bring it up with Roland and Benjamin.
|