search

dpeters / puppet-opsview

Puppet types/providers to support Opsview resources
12 stars 10 forks source link

configure /etc/puppet/opsview.conf file #6

Closed amosshapira closed 12 years ago

dpeters commented 12 years ago

I appologize for the huge delay in reviewing this!

I would prefer to keep site-specific manifests outside of this module for now - at least until there's more of a comprehensive set of manifests for managing Opsview. The current goal of this project is to maintain the types and providers for opsview_* resources.

If you were to move this manifest into an "examples" directory, I'd be happy to accept it.

amosshapira commented 12 years ago

I agree that site-specific configuration shouldn't be included in a generic module, but I don't understand why you think this is a site-specific file. This file is required in order for the opsview client to work, isn't it? Are you suggesting that users of the module should install this file from somewhere else?

dpeters commented 12 years ago

Are you suggesting that users of the module should install this file from somewhere else?

In a sense, yes. If the opsview class is being included on all nodes that run an agent, then it means that all opsview agents will have this user/password combo stored locally.

As an example, in my environment this file is managed via opsview::server::master, and is only installed on opsview master servers (which are also the dedicated opsview API hosts). The opsview class itself is only used to manage agent installation/configuration. This sort of setup has the benefit of only storing the username/password combo on the one server that needs to talk the API (and it could be further locked away by storing these values in hiera_gpg rather than in manifests or node definitions).

I think this does bring up a good point, that I need to put some effort into defining some best practices for this module.

There is a simple wiki page on how to use the module with exported resources and a single API host, but I think more info explaining the benefits and tradeoffs would be helpful.

Let me know what you think.

amosshapira commented 12 years ago

I agree with you about the sensitivity of this file. The way we implemented Opsview with Puppet is that the puppet "opsview client" module configures this file on each monitored node then puppet on the node itself tells the opsview server to start monitoring it via direct API. In any case - even in your setup - that file has to be configured somehow and the current Puppet module doesn't provide it.

dpeters commented 12 years ago

The current module isn't so much a module, as a set of types and providers. The current state requires the user to completely manage the module (manifests/files/templates) on their own.

Unless there's a more complete module to manage installation of masters and agents (preferably slaves as well) I'd rather have that sort of item in a separate /examples directory, that way users can see some of options they can go with, rather than forcing one way or another.

amosshapira commented 12 years ago

I agree with you about this module being a shell of a module and the reasoning that follows from that.