Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "PTP/designs/current PE"
(New page: = Current PE and LoadLeveler Resource Managers = == Current Implementation == The current PE and LoadLeveler proxies send attribute definitions to the client during startup to specify th...) |
|||
| Line 1: | Line 1: | ||
| − | = Current PE and LoadLeveler Resource Managers = | + | = Current PE and LoadLeveler Resource Managers = |
| − | == Current Implementation == | + | == Current Implementation == |
| − | The current PE and LoadLeveler proxies send attribute definitions to the client during startup to specify the set of fields that will be part of the tabbed sub-panel within the resources tab of the run or debug configuration. | + | The current PE and LoadLeveler proxies send attribute definitions to the client during startup to specify the set of fields that will be part of the tabbed sub-panel within the resources tab of the run or debug configuration. |
The class implementing the resources tab of the run configuration, org.eclipse.ptp.rm.ibm.pe.ui.rmLaunchConfiguration in the PE case, creates a tabbed widget with a set of predefined tabs. | The class implementing the resources tab of the run configuration, org.eclipse.ptp.rm.ibm.pe.ui.rmLaunchConfiguration in the PE case, creates a tabbed widget with a set of predefined tabs. | ||
| − | The createControl methofd in this class creates a TabFolder object then calls methods for each tab that create a TabItem object for the group and add widgets for fields where a matching attribute definition is recieved from the proxy. The set of widgets for a specific field on the panel are specified by logic in the rmLaunchConfiguration class if an attribute definition is received.<br> | + | The createControl methofd in this class creates a TabFolder object then calls methods for each tab that create a TabItem object for the group and add widgets for fields where a matching attribute definition is recieved from the proxy. The set of widgets for a specific field on the panel are specified by logic in the rmLaunchConfiguration class if an attribute definition is received.<br> |
| − | The proxy sends attribute definitions depending on the OS where the proxy is running (AIX or Linux), and in the PE case, whether PE is running stand-alone or usinjg LoadLeveler as a back end resource manager since certain options are valid only on AIX or Linux, or depend on LoadLeveler. If the rmLaunchConfiguration class does not find an attribute definition for an attribute, the field does not appear on the panel. | + | The proxy sends attribute definitions depending on the OS where the proxy is running (AIX or Linux), and in the PE case, whether PE is running stand-alone or usinjg LoadLeveler as a back end resource manager since certain options are valid only on AIX or Linux, or depend on LoadLeveler. If the rmLaunchConfiguration class does not find an attribute definition for an attribute, the field does not appear on the panel. |
| − | The attribute definitions in the current implementation are | + | The attribute definitions in the current implementation are |
| − | *Attribute name which corresponds to the PE environment variable name, for instance MP_PROCS or MP_HOSTFILE | + | *Attribute name which corresponds to the PE environment variable name, for instance MP_PROCS or MP_HOSTFILE |
| − | *Which combination of OS and with/without LoadLeveler is valid for that attribute | + | *Which combination of OS and with/without LoadLeveler is valid for that attribute |
| − | *A string which is used as the text of the Label widget which appears to the left of the field | + | *A string which is used as the text of the Label widget which appears to the left of the field |
| − | *A second string which is the flyover help text | + | *A second string which is the flyover help text |
| − | *The default environment variable value, if any | + | *The default environment variable value, if any |
| − | *For environment variables which are numeric values, the allowed minimum and maximum value | + | *For environment variables which are numeric values, the allowed minimum and maximum value |
*For environment variables which accept one of a list of values, a list of those values, which is used to populate a drop down list. Some environment variables allow only selections from thkis list and others allow selection from the list or any arbitrary string such as a filename. | *For environment variables which accept one of a list of values, a list of those values, which is used to populate a drop down list. Some environment variables allow only selections from thkis list and others allow selection from the list or any arbitrary string such as a filename. | ||
| − | When a new run configuration is created, the run configuration dialog is populated with the default values. Once values are filled in and run/apply clicked, the current values in the dialog completely replace the default values. | + | When a new run configuration is created, the run configuration dialog is populated with the default values. Once values are filled in and run/apply clicked, the current values in the dialog completely replace the default values. |
| − | When running a job, I think the attributes that get set on the run command must match the set of attributes valid in that particular combination of OS and LoadLeveler/no LoadLeveler. A given run configuration can be run once where PE is used stand-alone and then again where PE uses LoadLeveler as a backend. This requires either switching resource managers or editing the resource manager settings inthe 'edit resource manager' dialog. Specifically, attributes/environment variables that are valid only when LoadLeveler is the back end should not be sent when running a stand-alone PE resource mananger. | + | When running a job, I think the attributes that get set on the run command must match the set of attributes valid in that particular combination of OS and LoadLeveler/no LoadLeveler. A given run configuration can be run once where PE is used stand-alone and then again where PE uses LoadLeveler as a backend. This requires either switching resource managers or editing the resource manager settings inthe 'edit resource manager' dialog. Specifically, attributes/environment variables that are valid only when LoadLeveler is the back end should not be sent when running a stand-alone PE resource mananger. |
| − | The current implementation supports a basic and advanced mode. In basic mode, the individual settings are specified in fields in tabbed panes in the resources window. In advanced mode, the user specifies the pathname of a file that looks essentially like a setup script that sets environment variables. For instance | + | The current implementation supports a basic and advanced mode. In basic mode, the individual settings are specified in fields in tabbed panes in the resources window. In advanced mode, the user specifies the pathname of a file that looks essentially like a setup script that sets environment variables. For instance |
| − | '''# Sample expert mode script''' | + | '''# Sample expert mode script''' |
| − | '''MP_PROCS=2''' | + | '''MP_PROCS=2''' |
| − | '''MP_HOSTFILE=/tmp/hostfile''' | + | '''MP_HOSTFILE=/tmp/hostfile''' |
| − | Currently, this file must exist on the remote system. If the new model eliminates proxies running on the remote system then this becomes a local file again, and the client code is then responsible for reading the contents of the file and setting corresponding environment variables. | + | Currently, this file must exist on the remote system. If the new model eliminates proxies running on the remote system then this becomes a local file again, and the client code is then responsible for reading the contents of the file and setting corresponding environment variables. |
| − | == Considerations for new Implementation == | + | == Considerations for new Implementation == |
| − | In addition to considering the above in a new resource manager implementation, the configuration file for a PE or LoadLeveler resource manager instance should also allow the group that an attribute belongs to to be specified so that the code that builds the resources page in the run configuration knows how to group attributes into tabs in the resources page. | + | In addition to considering the above in a new resource manager implementation, the configuration file for a PE or LoadLeveler resource manager instance should also allow the group that an attribute belongs to to be specified so that the code that builds the resources page in the run configuration knows how to group attributes into tabs in the resources page. |
| − | Type information (numeric, string, fixed drop down list, open ended drop down list, boolean, input file, output file, directory) may be useful so that the code which builds the resource tab knows whay tyoe of widgets to add to a tab pane. | + | Type information (numeric, string, fixed drop down list, open ended drop down list, boolean, input file, output file, directory) may be useful so that the code which builds the resource tab knows whay tyoe of widgets to add to a tab pane. |
| − | We may need to know what version of PE or LoadLeveler is being used so that only options that are valid in a specific release are displayed. Maybe this is better managed by having a specific configuration file used for a specific release. | + | We may need to know what version of PE or LoadLeveler is being used so that only options that are valid in a specific release are displayed. Maybe this is better managed by having a specific configuration file used for a specific release. |
| − | == Screen Captures == | + | == Screen Captures == |
The following screen captures show what the current resources tab looks like for PE | The following screen captures show what the current resources tab looks like for PE | ||
| + | [[Image:PE_screencap1.jpg]] | ||
Revision as of 16:49, 13 January 2011
Contents
Current PE and LoadLeveler Resource Managers
Current Implementation
The current PE and LoadLeveler proxies send attribute definitions to the client during startup to specify the set of fields that will be part of the tabbed sub-panel within the resources tab of the run or debug configuration.
The class implementing the resources tab of the run configuration, org.eclipse.ptp.rm.ibm.pe.ui.rmLaunchConfiguration in the PE case, creates a tabbed widget with a set of predefined tabs.
The createControl methofd in this class creates a TabFolder object then calls methods for each tab that create a TabItem object for the group and add widgets for fields where a matching attribute definition is recieved from the proxy. The set of widgets for a specific field on the panel are specified by logic in the rmLaunchConfiguration class if an attribute definition is received.
The proxy sends attribute definitions depending on the OS where the proxy is running (AIX or Linux), and in the PE case, whether PE is running stand-alone or usinjg LoadLeveler as a back end resource manager since certain options are valid only on AIX or Linux, or depend on LoadLeveler. If the rmLaunchConfiguration class does not find an attribute definition for an attribute, the field does not appear on the panel.
The attribute definitions in the current implementation are
- Attribute name which corresponds to the PE environment variable name, for instance MP_PROCS or MP_HOSTFILE
- Which combination of OS and with/without LoadLeveler is valid for that attribute
- A string which is used as the text of the Label widget which appears to the left of the field
- A second string which is the flyover help text
- The default environment variable value, if any
- For environment variables which are numeric values, the allowed minimum and maximum value
- For environment variables which accept one of a list of values, a list of those values, which is used to populate a drop down list. Some environment variables allow only selections from thkis list and others allow selection from the list or any arbitrary string such as a filename.
When a new run configuration is created, the run configuration dialog is populated with the default values. Once values are filled in and run/apply clicked, the current values in the dialog completely replace the default values.
When running a job, I think the attributes that get set on the run command must match the set of attributes valid in that particular combination of OS and LoadLeveler/no LoadLeveler. A given run configuration can be run once where PE is used stand-alone and then again where PE uses LoadLeveler as a backend. This requires either switching resource managers or editing the resource manager settings inthe 'edit resource manager' dialog. Specifically, attributes/environment variables that are valid only when LoadLeveler is the back end should not be sent when running a stand-alone PE resource mananger.
The current implementation supports a basic and advanced mode. In basic mode, the individual settings are specified in fields in tabbed panes in the resources window. In advanced mode, the user specifies the pathname of a file that looks essentially like a setup script that sets environment variables. For instance
# Sample expert mode script
MP_PROCS=2
MP_HOSTFILE=/tmp/hostfile
Currently, this file must exist on the remote system. If the new model eliminates proxies running on the remote system then this becomes a local file again, and the client code is then responsible for reading the contents of the file and setting corresponding environment variables.
Considerations for new Implementation
In addition to considering the above in a new resource manager implementation, the configuration file for a PE or LoadLeveler resource manager instance should also allow the group that an attribute belongs to to be specified so that the code that builds the resources page in the run configuration knows how to group attributes into tabs in the resources page.
Type information (numeric, string, fixed drop down list, open ended drop down list, boolean, input file, output file, directory) may be useful so that the code which builds the resource tab knows whay tyoe of widgets to add to a tab pane.
We may need to know what version of PE or LoadLeveler is being used so that only options that are valid in a specific release are displayed. Maybe this is better managed by having a specific configuration file used for a specific release.
Screen Captures
The following screen captures show what the current resources tab looks like for PE
