Sun Microsystems
Products & Services
 
Support & Training
 
 

Previous Previous     Contents     Index     Next Next

Defining Projects

Projects 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 QMON

Grid 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

Dialog box titled Project Configuration. Shows Projects and Configuration
lists. Shows Add, Modify, Delete, Done, and Help buttons.

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.

Dialog box titled Add/Modify Project. Shows Name, User Lists,
and Xuser Lists fields. Shows Ok and Cancel buttons.

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.

Dialog box titled Select Access Lists. Shows Available Access
Lists and Chosen Access Lists. Shows Ok, Cancel, and Help buttons.

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 Line

To define projects from the command line, type the following command with appropriate options:

# qconf options

The following options are available:

  • qconf -aprj

    The -aprj option (add project) opens a template project configuration in an editor. See the project(5) man page. The editor is either the default vi editor or the editor specified by the EDITOR environment variable. After you save your changes and exit the editor, the changes are registered with sge_qmaster.

  • qconf -Aprj filename

    The -Aprj option (add project from file) parses the specified file and adds the new project configuration. The file must have the format of the project configuration template.

  • qconf -dprj project-name[,...]

    The -dprj option (delete project) deletes one or more projects.

  • qconf -mprj project-name

    The -mprj option (modify project) enables you to modify an existing user entry. The option loads the project configuration in an editor. The editor is either the default vi editor or the editor specified by the EDITOR environment variable. After you save your changes and exit the editor, the changes are registered with sge_qmaster.

  • qconf -Mprj filename

    The -Mprj option (modify project from file) parses the specified file and modifies the existing project configuration. The file must have the format of the project configuration template.

  • qconf -sprj project-name

    The -sprj option (show project) displays the configuration of a particular project.

  • qconf -sprjl

    The -sprjl option (show project list) displays a list of all currently defined projects.

Using Path Aliasing

In 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:

  • Fixed NFS mounts with different mount point paths on different machines. An example is the mounting of home directories under /usr/people on one host and under /usr/users on another host.

  • Symbolic links from outside into a network-available file system

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:

  • sge-root/cell/common/sge_aliases -- A global cluster path-aliasing file for the cluster

  • $HOME/.sge_aliases -- A user-specific path-aliasing file


    Note - Only an administrator should modify the global file.


Previous Previous     Contents     Index     Next Next