Project States

A project does not actually enforce the resource consumption boundaries that you set for an application. Rather, after the minimum CPU reservation and memory cap are provided and the project is activated, the Solaris kernel begins enforcing these boundaries. Before using projects, you need to know more about project states. A project can be in one of the following three states: defined, active, and inactive.

Figure 3–2 Project States

A project can move between these states throughout its lifetime.

Containers and Projects

The container is created during the initial stage when the project itself is still not fully formed. Each project must have a unique name and can be saved indefinitely in the database.

Figure 3–2 shows the project moves into the active state after the container is associated with a host. An inactive project can move back into the defined state after it has been deactivated and is no longer associated with a host.

Project Activation

The first step in making a project active is to associate its container with a host. The second step is to set the resource boundaries, namely, to assign the minimum CPU reservation and the memory cap for the project. The project must be associated with a host that can support these resource boundaries. An active project can also be referred to as being deployed, in the sense that the project has been pushed out and resides on a host.

When creating an application-based project with the New Project Wizard, a match expression can be provided that identifies the processes associated with the application. All processes that correspond to the match expression are then automatically moved under this container. On project activation, an entry in the /etc/project database is created on the host that the container is associated with. Correspondingly, the matching processes are then moved under the project name for the container. After the processes are moved, all resource utilization data is collected and saved for the project.

Inactive Project

When a project is deactivated, the resource boundaries are no longer enforced. A deactivated project enters into an inactive state and is deleted from the host's /etc/project file. While inactive, the project still exists in the software's database, pending future activation. After the inactive project is reactivated, the container's resource boundaries are again enforced.

All data collected about the project's use of resources while it was active is preserved in the database. You can still request utilization reports for an inactive project for up to 30 days after the project was deactivated.