Forge Home

Christian Paredes



10,305 latest version

1.5 quality score

Version information

  • 0.0.2 (latest)
  • 0.0.1 (deleted)
released Jul 7th 2011

Start using this module

  • r10k or Code Manager
  • Bolt
  • Manual installation
  • Direct download

Add this module to your Puppetfile:

mod 'cparedes-puppet_opsview', '0.0.2'
Learn more about managing modules with a Puppetfile

Add this module to your Bolt project:

bolt module add cparedes-puppet_opsview
Learn more about using this module with an existing project

Manually install this module globally with Puppet module tool:

puppet module install cparedes-puppet_opsview --version 0.0.2

Direct download is not typically how you would use a Puppet module to manage your infrastructure, but you may want to download the module in order to inspect the code.



cparedes/puppet_opsview — version 0.0.2 Jul 7th 2011

Stable release download

If you're looking for stable releases, you can download this module at the Puppet Forge.


Right now, the module only contains libraries to handle all of the REST requests to a given Opsview server. You will need to create /etc/puppet/opsview.conf with the following format on each client that you wish to connect with an Opsview server:

username: foobar
password: foobaz

The libraries are heavily based off of the original Opsview libraries, with contributions by Devon Peters.

These libraries are currently used in production at Seattle Biomed.

Please file bugs via the issue tracker above.


  • Puppet (of course :)) Tested with Puppet 2.6.8.
  • rest-client, json gems.


TODO: Need to list parameters for each resource.

  • opsview_contact
  • opsview_hostgroup
  • opsview_hosttemplate
  • opsview_monitored
  • opsview_role
  • opsview_servicecheck
  • opsview_servicegroup


  1. Use rest-client library instead of net/http. This allows us to authenticate clients over HTTPS and, overall, abstract a lot of the HTTP calls to the server.

  2. Create a subclass called "Puppet::Provider::Opsview" with default methods that may be overridden by any of the providers. The class contains methods that actually hook into the server - thus, the provider Ruby files (in particular, the flush method in each file) are reduced quite a bit, and we don't need to explicitly define a function that reads in token information from the Opsview server.

  3. Rename variables and methods, so they don't use camel case.

  4. Rename resources so that they have underscores in them (seems to make more sense to me to use opsview_monitored vs. opsviewmonitored.)

List of things to do

  1. Separate out a few get/set methods from Puppet::Provider::Opsview - put them in a utility module instead.

  2. Clean up Puppet::Provider::Opsview in general. Cull any class/instance methods we don't need (there's lots of duplication.)

  3. Add default providers so that Puppet runs don't fail when there's no rest-client / json gems to use.