Daniel Pittman
2009-Jul-10 06:54 UTC
[Puppet Users] Best practices for building a file from distributed data.
G''day. I am wondering what the current best practice for building a single file out of distributed fragments is with puppet. Specifically, my problem: 1. Install munin-node on arbitrary machines. 2. Install ''munin.conf'' as a single file on one machine, containing a configuration stanza for every machine that munin-node is installed on. The current best practice looks to be: 1. In the munin-node manifest, create an exported ''file'' containing the configuration for that machine. (storeconfig enabled, obviously.) 2. On the munin central host, collect the exported file objects, creating them on disk in a random directory. 3. On the munin central host use some solution like "concatenated_file" to run a shell command, post-hoc, to build the munin.conf file from those fragments stored on disk. Is this really still the best method for achieving this? Is it possible for me to access the storeconfig database from a puppet template running on the puppetmaster? Regards, Daniel -- ✣ Daniel Pittman ✉ daniel@rimspace.net ☎ +61 401 155 707 ♽ made with 100 percent post-consumer electrons --~--~---------~--~----~------------~-------~--~----~ 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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
Daniel Pittman
2009-Jul-10 07:33 UTC
[Puppet Users] Re: Best practices for building a file from distributed data.
Daniel Pittman <daniel@rimspace.net> writes:> I am wondering what the current best practice for building a single file out > of distributed fragments is with puppet.[...]> 2. On the munin central host, collect the exported file objects, creating them > on disk in a random directory. > > 3. On the munin central host use some solution like "concatenated_file" to run > a shell command, post-hoc, to build the munin.conf file from those > fragments stored on disk.Another option that my research has turned up, which is fractionally less ugly, is to collect these files on puppetmaster, then use template() or the content of the template to collect them while building the manifest. That marginally reduces the ugliness: the munin.conf file is built on the puppetmaster, from the fragments, but it still isn''t really nice. Regards, Daniel -- ✣ Daniel Pittman ✉ daniel@rimspace.net ☎ +61 401 155 707 ♽ made with 100 percent post-consumer electrons --~--~---------~--~----~------------~-------~--~----~ 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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
Peter Meier
2009-Jul-10 08:10 UTC
[Puppet Users] Re: Best practices for building a file from distributed data.
Hi> Is this really still the best method for achieving this?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.> 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. 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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
Daniel Pittman
2009-Jul-10 09:32 UTC
[Puppet Users] Re: Best practices for building a file from distributed data.
Peter Meier <peter.meier@immerda.ch> writes:>> Is this really still the best method for achieving this? > > 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. 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.>> 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? 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. Regards, Daniel -- ✣ Daniel Pittman ✉ daniel@rimspace.net ☎ +61 401 155 707 ♽ made with 100 percent post-consumer electrons --~--~---------~--~----~------------~-------~--~----~ 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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
David Schmitt
2009-Jul-10 10:00 UTC
[Puppet Users] Re: Best practices for building a file from distributed data.
Daniel Pittman wrote:> G''day. > > I am wondering what the current best practice for building a single file out > of distributed fragments is with puppet. Specifically, my problem: > > 1. Install munin-node on arbitrary machines. > 2. Install ''munin.conf'' as a single file on one machine, containing a > configuration stanza for every machine that munin-node is installed on. > > The current best practice looks to be: > > 1. In the munin-node manifest, create an exported ''file'' containing the > configuration for that machine. (storeconfig enabled, obviously.) > > 2. On the munin central host, collect the exported file objects, creating them > on disk in a random directory. > > 3. On the munin central host use some solution like "concatenated_file" to run > a shell command, post-hoc, to build the munin.conf file from those > fragments stored on disk. > > > Is this really still the best method for achieving this?Yes. Please checkout my munin module on github[1] or my private repos[2]. They already bring everything you need in a convenient package together with defines to handle plugins locally and remotely. Regards, DavidS [1] http://github.com/DavidS/puppet-munin/tree/development [2] http://git.black.co.at/?p=module-munin --~--~---------~--~----~------------~-------~--~----~ 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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
Peter Meier
2009-Jul-10 13:30 UTC
[Puppet Users] Re: Best practices for building a file from distributed data.
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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
Daniel Pittman
2009-Jul-11 09:37 UTC
[Puppet Users] Re: Best practices for building a file from distributed data.
David Schmitt <david@dasz.at> writes:> Daniel Pittman wrote:[...]>> Is this really still the best method for achieving this? > > Yes. Please checkout my munin module on github[1] or my private > repos[2]. They already bring everything you need in a convenient package > together with defines to handle plugins locally and remotely.*nod* I am aware of the module, and thank you for making it available. Regards, Daniel -- ✣ Daniel Pittman ✉ daniel@rimspace.net ☎ +61 401 155 707 ♽ made with 100 percent post-consumer electrons --~--~---------~--~----~------------~-------~--~----~ 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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---