Bugzilla – Full Text Bug Listing
| Summary: | [JAXB] separate UI elements to submit an interactive PBS job and run the mpi application | ||
|---|---|---|---|
| Product: | [Tools] PTP | Reporter: | levent <leventyilmaz> |
| Component: | RM | Assignee: | Greg Watson <g.watson> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | arossi, beth, g.watson |
| Version: | 5.0 | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
|
Description
levent
I don't see why this requires a separate UI. All of what you are asking for is either currently possible or could be configured using the current API. 1 & 2. are currently done together. The one thing that needs to be added for interactive sessions is to pass the Environment Tab settings in a generic way to the command. This is enabled for script-based submissions, but I neglected to put this in place for purely interactive jobs. The environment would have to be added to the Process Builder rather than set in the script. 3. You can currently do this, or you can modify the Launch Tab configuration to do this. Essentially, when you submit a PBS interactive job, the resource requests apply to the initial PBS -I command. Everything else is a redirect to stdin. So if you change the application, the -np number, etc., and resubmit, it should happen. NOTE: this is not yet enabled for debug. That is the one thing missing. Enabling debug for PBS interactive will entail a slight modification of the underlying code in order to add a start-debugger command to execute just before the actual job. Al Our experience from the workshop was that rerunning the job using the launch button is a bit non-intuitive. This is because the behavior of the launch button changes depending on the state of a job, something that doesn't normally happen in Eclipse. Instead, we were thinking that the launch button should always do the same thing, i.e. submit the job. For interactive jobs, once the job is in the running state, the setup and interactive portion of the job would be restarted using the job context menu. This roughly corresponds to the action a user would normally have to take to run an interactive job, and I think is more intuitive for the user. (In reply to comment #2) > Our experience from the workshop was that rerunning the job using the launch > button is a bit non-intuitive. This is because the behavior of the launch > button changes depending on the state of a job, something that doesn't normally > happen in Eclipse. Instead, we were thinking that the launch button should > always do the same thing, i.e. submit the job. For interactive jobs, once the > job is in the running state, the setup and interactive portion of the job would > be restarted using the job context menu. This roughly corresponds to the action > a user would normally have to take to run an interactive job, and I think is > more intuitive for the user. If this is separate UI, it should be built the same way as the Launch Tab (configurable). It would be in my opinion a good idea to try to reuse the code that exists, perhaps with a custom wizard which differs from the Launch Tab only in that its parent is not the Resources Tab. You may want to modify the XSD to include an "interactive tab" attribute on the Launch Tab, though it is true this info can be obtained from how the launch commands are defined. The Jobs View will also need to check to see if the configuration is interactive in order to activate the appropriate actions. (In reply to comment #3) > (In reply to comment #2) > > Our experience from the workshop was that rerunning the job using the launch > > button is a bit non-intuitive. This is because the behavior of the launch > > button changes depending on the state of a job, something that doesn't normally > > happen in Eclipse. Instead, we were thinking that the launch button should > > always do the same thing, i.e. submit the job. For interactive jobs, once the > > job is in the running state, the setup and interactive portion of the job would > > be restarted using the job context menu. This roughly corresponds to the action > > a user would normally have to take to run an interactive job, and I think is > > more intuitive for the user. > > If this is separate UI, it should be built the same way as the Launch Tab > (configurable). It would be in my opinion a good idea to try to reuse the code > that exists, perhaps with a custom wizard which differs from the Launch Tab > only in that its parent is not the Resources Tab. You may want to modify the > XSD to include an "interactive tab" attribute on the Launch Tab, though it is > true this info can be obtained from how the launch commands are defined. The > Jobs View will also need to check to see if the configuration is interactive in > order to activate the appropriate actions. You also need to keep in mind that application, argument and environment come from Launch tabs as well. You will need to access all of these, or at least the LaunchConfiguration, to make this work. fix typo in title JABX->JAXB The new method will work as follows: 1. User submits batch-interactive job using run configuration/run button. 2. When job changes to RUNNING (from SUBMITTED), input will be sent to process. 3. When user wants to re-run the job (i.e. re-send the input), they will right-click on the running job, and choose "Re-run Job" from the context menu. Initial changes committed to master. This provides a rerun() method that can be called to resend the input to the job. Still need to hook up UI to enable this functionality. This work is now complete. |