Hi >> if you don't want to write an own parsed file provider which can edit >> parts of a certain file (like the one of the nagios resources) and/or do >> it with augeas, then yes. > > We don't have augeus conveniently at hand (and it doesn't have a > lens anyhow); > building a parsed file provider is possible, I guess. That looks > like quite a > lot of work for what I considered a conceptually simple problem though. > > The munin.conf format is a more-or-less ini style file: > ,---- > | global_option one > | global_two two > | > | [node foo.bar] > | node_attribute one > | node_attribute two > `---- > > It doesn't look like the default parsers support that nicely, and the puppet > resource structure doesn't really favour it either: there is no nice way to > express the '[node foo.bar]' attributes in a single object.
maybe, but maybe also not. it depends on how you would model it. > So, I would be stuck creating a bunch of separate entities that would require > parsing and rewriting the content entirely for each node, right? Plus, > another one to rewrite the global configuration options. maybe not that much, but yeah for sure for the global parameters and each node item. the idea behind puppet is that you manage resources.you might see munin.conf itself as one resource. But looking at it globally as one resource will give you the problems you currently encounter. munin.conf consists more of different resources, so each part is a resource on its own managed by puppet. >>> Is it possible for me to access the storeconfig database from a puppet >>> template running on the puppetmaster? >> >> yes. it's erb, so ruby and you can do whatever you'd like to do. however I >> think this one is much uglier than the solutions from above. > > Hmmm. I am curious why you think it is so ugly? because you'll hide some logic of your manifests in templates, which I'd rather avoid. > What I really want is access to a list of facts for hosts matching my > criteria: > > for each host with munin-node installed: > emit one stanza containing the 'fqdn' fact > > That doesn't seem conceptually challenging, at least to me. It seems, in > fact, like a quite reasonable use of the ability to introspect the entire > infrastructure within puppet in order to have cross-host awareness of > configuration. well this you get as well with exported resources. and as davids mentioned he does exactly this in his munin-module and it works perfectly. I'm a very happy long-time user of it and in my opinion it's more the puppet way than all other attempts. But yeah we could now start a philosophical discussion about that ;) cheers pete --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
