On Thu, Sep 22, 2011 at 09:23:56AM -0700, Douglas Garstang wrote: > On Thu, Sep 22, 2011 at 9:14 AM, Christopher Wood > <christopher_w...@pobox.com> wrote: > > On Thu, Sep 22, 2011 at 09:05:32AM -0700, Douglas Garstang wrote: > >> On Thu, Sep 22, 2011 at 5:57 AM, jcbollinger <john.bollin...@stjude.org> > >> wrote: > >> > > >> > > >> > On Sep 21, 6:34 pm, Nigel Kersten <ni...@puppetlabs.com> wrote: > >> >> On Wed, Sep 21, 2011 at 1:20 PM, Douglas Garstang > >> >> > >> >> <doug.garst...@gmail.com> wrote: > >> >> > All, > >> >> > >> >> > I have a situation where I need to get some fairly complex > >> >> > configuration files onto systems, and I'm wondering if puppet can even > >> >> > do this. Lets say that my external node script will go and source all > >> >> > the data it needs from an external database, and dump out all > >> >> > variables that the node will need. The relevant puppet module(s) will > >> >> > then have to inject these variables into templates to be deployed to > >> >> > the systems. > >> >> > >> >> Can you provide an example of a chunk of actual data and the desired > >> >> end result to see if there's a better alternative Doug? > >> > > >> > > >> > I second that request. The scenario presented is more a design > >> > concept than a problem description. Although I am confident that > >> > Puppet indeed can handle the scenario as presented, it may be that > >> > there are alternative designs that would accomplish the same objective > >> > in a simpler way. > >> > >> Well, speaking somewhat generically still, we have an application that > >> will need to run multiple times on a single system, and each instance > >> of that running application will have it's own config file, each with > >> a variable number of items (they're disk volumes). > >> > >> If the external node script returned YAML data like this: > >> > >> appX_inst1_vol1_name: vol1 > >> appX_inst1_vol1_size: 1G > >> appX_inst1_vol1_active: true > >> appX_inst2_vol1_name: vol2 > >> appX_inst2_vol1_size: 2G > >> appX_inst2_vol1_active: false > >> > >> ... and so on. All the volumes for inst1 need to go into one config > >> file, all the volumes for inst2 in another config file and so on. I > >> don't see a way that puppet can iterate over a variable number of > >> items and split the data into multiple files. > > > > At the risk of sounding dim, if you have variable files full of variable > > data, why don't you handle that logic in the ruby stanzas in your template? > > You can template the main file, and the ruby portions can write other files > > as needed. > > I wasn't quite sure, but is the embedded ruby in the templates fully > functional ruby? ie it can write files etc?
Yes and no. Templates are sorted out on the server, so files are written there. I'm using this capacity to create /etc/network/interfaces in Debian/Ubuntu, still thinking about how to handle the same thing in CentOS/RedHat. I suspect I'll end up templating a yaml file and having an agent-side script create the files themselves. The script exec can subscribe to the yaml file and kick off the networking reload itself. > > Otherwise, if you really have variable files full of variable data, I'm > > curious about just what application you're attempting to configure. > > > > It's proprietary software. Every service company has proprietary > software that may (or may not in our case) be designed very well. Tell them that the internet people had you name your config handling module vendorname__workarounds. > Doug. > > -- > 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. > > -- 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.
