Adoptable Cookbooks List

Looking for a cookbook to adopt? You can now see a list of cookbooks available for adoption!
List of Adoptable Cookbooks

Supermarket Belongs to the Community

Supermarket belongs to the community. While Chef has the responsibility to keep it running and be stewards of its functionality, what it does and how it works is driven by the community. The chef/supermarket repository will continue to be where development of the Supermarket application takes place. Come be part of shaping the direction of Supermarket by opening issues and pull requests or by joining us on the Chef Mailing List.

Select Badges

Select Supported Platforms

Select Status

RSS

resource-control (5) Versions 0.0.3

Lightweight resource providers for project and task management in Solaris

Policyfile
Berkshelf
Knife
cookbook 'resource-control', '= 0.0.3', :supermarket
cookbook 'resource-control', '= 0.0.3'
knife supermarket install resource-control
knife supermarket download resource-control
README
Dependencies
Quality -%

Resource Control

Resource Control is a chef cookbook for managing Solaris projects, tasks and resource
limits using the Resource Control Facility.

Provides

LWRPs:
* project

Recipes:
* default - does nothing

Requirements

  • Solaris or Illumos-based operating system
  • Tested on SmartOS

Due to differences in hash behaviors, it is recommended that the LWRPs in this cookbook
only be used with Ruby 1.9 or greater. In earlier versions of Ruby, notifications may
fire from resource blocks even if the resource does not change.

Project LWRP

Solaris projects are useful in a number of ways. Processes for a service can be grouped together
to better report on aggregate resource utilization. Limits can also be set on numerous metrics,
or altered from system defaults.

Projects are the only way that certain settings can be relaxed for process groups, for instance
max file descriptors or shared memory limits.

Attributes

  • project_limits
  • task_limits
  • process_limits
  • comment
  • users

Actions

  • :create - default
  • :nothing

Overview

resource_control_project "postgres" do
  comment "PostgreSQL 9.2"
  users "postgres"

  project_limits "max-shm-memory" => 12000000,
                 "max-lwps"       => 6
  task_limits    "max-cpu-time"   => 3600
  process_limits "max-cpu-time" => [
                     {"value" => 3600, "signal" => "TERM"},
                     {"value" => 3660, "deny" => true}
                 ],
                 "max-file-descriptor" => {
                     "value" => 32768, "deny" => true
                 }
  action :create
end

See the documentation of resource controls in the References section below for available
resource limits.

Users

Tasks started as a superuser can be added to any project, but if a task or process is started
by a non-privileged user, that user should be added to the project.

The users attribute can be set as a String or an Array.

Local actions and signalling

By default limits will not be enforced (local action set to none). This may seem
counter-intuitive, but can be useful for monitoring purposes when overages are logged
to syslog.

The local action can be set to either deny or signal through the following syntax:

resource_control_project "redis" do
  process_limits "max-cpu-time" => {
          "value" => 3600,
          "deny"  => true
      }
end
resource_control_project "sidekiq" do
  process_limits "max-cpu-time" => {
          "value" => 7200,
          "signal"  => "TERM"
      }
end

Available signals are:

  • ABRT - Terminate the process
  • HUP - Send a hangup signal. Occurs when carrier drops on an open line. Signal sent to the process group that controls the terminal.
  • TERM - Terminate the process. Termination signal sent by software.
  • KILL - Terminate the process and kill the program
  • STOP - Stop the process. Job control signal.
  • XRES - Resource control limit exceeded. Generated by resource control facility.
  • XFSZ - Terminate the process. File size limit exceeded.
  • XCPU - Terminate the process. CPU time limit exceeded.

Note that in a lot of documentation, signals take the form "SIGTERM" whereas we just
use "TERM". This is to avoid complicating the provider code, as the text actually set in
the projects database is the short version.

Also note that not every signal or action can be set for every resource limit. Please read the documentation
and man pages for more information.

Cascading limits

In some cases, multiple limits may be desirable for a key. In this case, use an Array for the value
of the key:

resource_control_project "sidekiq" do
  process_limits "max-cpu-time" => [
          { "value" => 7200, "signal" => "TERM" },
          { "value" => 7260, "signal" => "KILL" }
      ]
end

Privilege level

By default, the limits set by the project provider can only be modified by superusers. Assuming
that the chef run is executed by root, this should never need to be changed.

References

No quality metric results found