![]() |
|||
![]() |
![]() ![]() |
![]() |
![]() ![]() |
![]() |
![]() ![]() |
![]() |
| ||
Defining ProjectsProjects provide a means to organize joint computational tasks from multiple users. A project also defines resource usage policies for all jobs that belong to such a project. Projects are used in three scheduling policy areas:
Projects must be declared before they can be used in any of the three policies. Grid engine system managers define projects by giving them a name and some attributes. Grid engine users can attach a job to a project when they submit the job. Attachment of a job to a project influences the job's dispatching, depending on the project's share of share-based, functional, or override tickets. Defining Projects With QMONGrid engine system managers can define and update definitions of projects by using the Project Configuration dialog box. To define a project, on the QMON Main Control window, click the Project Configuration button. The Project Configuration dialog box appears. Figure 4-3 Project Configuration Dialog Box ![]() The currently defined projects are displayed in the Projects list. The project definition of a selected project is displayed under Configuration. To delete a project immediately, select it, and then click Delete. To add a new project, click Add. To modify a project, select it, and then click Modify. Clicking Add or Modify opens the Add/Modify Project dialog box. ![]() The name of the selected project is displayed in the Name field. The project defines the access lists of users who are permitted access or who are denied access to the project. Users who are included in any of the access lists under User Lists have permission to access the project. Users who are included in any of the access lists under Xuser Lists are denied access to the project. See Configuring Users for more information. If both lists are empty, all users can access the project. Users who are included in different access lists that are attached to both the User Lists and the Xuser Lists are denied access to the project. You can add access lists to User Lists or Xuser Lists, and you can remove access lists from either list. To do so, click the button at the right of the User Lists or the Xuser Lists. The Select Access Lists dialog box appears. ![]() The Select Access Lists dialog box displays all currently defined access lists under Available Access Lists. The dialog box displays the attached lists under Chosen Access Lists. You can select access lists in either list. You can move access lists from one list to the other by using the red arrows. Click OK to save your changes and close the dialog box. Click Cancel to close the dialog box without saving your changes. Defining Projects From the Command LineTo define projects from the command line, type the following command with appropriate options:
The following options are available:
Using Path AliasingIn Solaris and in other networked UNIX environments, users often have the same home directory, or part of it, on different machines. For example, the directory might be made accessible across NFS. However, sometimes the home directory path is not exactly the same on all machines. For example, consider user home directories that are available across NFS and automounter. A user might have a home directory /home/foo on the NFS server. This home directory is accessible under this path on all properly installed NFS clients that are running automounter. However, /home/foo on a client is just a symbolic link to /tmp_mnt/home/foo. /tmp_mnt/home/foo is the actual location on the NFS server from where automounter physically mounts the directory. A user on a client host might use the qsub -cwd command to submit a job from somewhere within the home directory tree. The -cwd flag requires the job to be run in the current working directory. However, if the execution host is the NFS server, the grid engine system might not be able to locate the current working directory on that host. The reason is that the current working directory on the submit host is /tmp_mnt/home/foo, which is the physical location on the submit host. This path is passed to the execution host. However, if the execution host is the NFS server, the path cannot be resolved, because its physical home directory path is /home/foo, not /tmp_mnt/home/foo. Other occasions that can cause similar problems are the following:
To prevent such problems, grid engine software enables both the administrator and the user to configure a path aliasing file. The locations of two such files are as follows: | ||
| ||
![]() |