On Sep 22, 4:11 pm, Douglas Garstang <doug.garst...@gmail.com> wrote: > On Thu, Sep 22, 2011 at 1:56 PM, jcbollinger <john.bollin...@stjude.org> > wrote: > > > On Sep 22, 11:05 am, Douglas Garstang <doug.garst...@gmail.com> 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. > > > Part of the question is why the ENC would structure the data that way > > in the first place. I don't use one, so perhaps I am displaying my > > ignorance, but can't ENCs assign hash and array values to variables? > > As any Perl hand will know, arrays and hashes are plenty to build data > > structures of arbitrary complexity. > > The ENC needs to structure the data that way in order to allow puppet > to reformat the data in a way that the software recognises. I don't > think ENC's can do anything more complex than assign key/value pairs > under 'parameters'. I've tried to put more complex data under > parameters, but I can't access it in the manifest.
It looks like this would be http://projects.puppetlabs.com/issues/3154. Sorry for that red herring. > I also need to > break the data into multiple files, which erb can't do, since it can > only write files to the server, not the client. As I see it, you have two main problems: 1) Obtaining or building a sufficiently structured form of the data defining the needed config files 2) Building the files from the data It is a shame that (1) cannot currently be accomplished directly from your ENC, but that does not mean it cannot be accomplished at all. If you are free to obtain the data from a separate data source, then a custom function can in principle do whatever you want. For this job, however, Hiera looks like it could already do the job nicely. Perhaps extlookup() could also, but I'm not sure off-hand whether it can provide data of complex types. Even with the data coming from the ENC largely as you are currently trying to do, you should still be able to analyze it successfully in Puppet. In particular, it looks like one of your key problems is determining which variables are present for your node to use, but you should be able to use an inline template to find these (see http://docs.puppetlabs.com/guides/templating.html#access-to-variables-and-puppet-functions-with-the-scope-object). As for problem (2), I reiterate that Puppet DSL gives you enough to accomplish your objective. Nevertheless, you also have the option of writing pure-Ruby manifests, which provides all the capabilities of a general-purpose programming language. > > On the Puppet side, array resource titles, defined types, and > > create_resources() have enough power to pull that data back out, at > > least if you structure it with a bit of care. I think hiera could > > help go even further. > > See my post just now about passing an array to a definition. It looks > like the $name field has a size limit which stops me from passing all > the data I need. As Ken Barber already replied, in that case you are attempting to pass a hash as the resource title. Puppet does the best it can with that (in particular, it flattens it to a string), but that is extremely unlikely to be what you want. > Not sure what create_resource is .... documentation? http://docs.puppetlabs.com/references/stable/function.html#createresources It is for declaring a resource based on a hash of its properties, which appears to be what you were looking for when you tried passing a hash as a resource title. John -- 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.
