On Tuesday, June 24, 2014 4:27:41 PM UTC+2, pablo.f...@cscs.ch wrote: > > Hi, > > On 23/06/14 19:15, Alessandro Franceschi wrote: > > As a side note I'm a bit perplex about the proliferation of parameters in > classes or defines in order to match single application specific > configuration entries. > When I look at this, for example: > > https://github.com/puppetlabs/puppetlabs-apache/blob/master/manifests/vhost.pp > my backbone freezes. > A huge amount of define parameters, that map Apache directives, and not > even a parameter that allows me to provide a custom template. > > > I agree... it sucks! But I think it sucks more to the person that wrote > the module than to those using it. When you see a declaration of a vhost, > written in puppet language, it's clear and self-explanatory. But if you > pass a template instead, the clarity is lost: you need to look for it > elsewhere, it's much more complicated to understand a template than a > puppet hash, and you need to seek each variable to see where its value is > coming from. > > The specific problem with vhosts (and other of the kind) is a problem with > the language itself: Hiera does not search parameters of defined types, and > you need to find your way around with a class that does a simple > create_resources to create those resources of that defined type (and > probably set defaults with parameters). It could be worse, though :) >
> Also, if you want a pure data driven setup, where you place on hiera > hashes of data with all the stuff you need, you can still have this using a > template and a single parameters ( such as the options_hash ) > > > I have mixed feelings about this: if it's not a parameter, you don't have > automatic hiera lookups, and additionally you have to properly document the > structure of the hash. Parameters are almost self-explanatory... but I > agree that there are some modules where everything is a parameter, and it's > difficult to handle. But I think I would rather have that than doing a > template do all the work and have to parameters (template and options_hash) > Sometimes I wonder if a totally data driven approach is something that is always the right choice. Given that it's mostly a matter of personal preference, infrastructure design, skills and so on, I feel like that sometimes modules' author forget that Puppet users are most of the times system administrators that know exactly how to configure their files and need Puppet to replicate the configurations they have. So having to study a module in order to achieve the intended output on the generated configurations might be frustrating. Anyway if you want all your data in hiera, also the application specific settings, nodody prevents you from placing in hiera a key with this data and placing it in a variable that you use to feed the options_hash parameter. Really, I have seen and tested different approaches on how to organise things with Puppet: all the data on Hiera, no Hieraat all; class groupings in an ENC, Hiera, a site module; nodes classification using nodes' inheritance, a nodeless setup, an ENC; file managed or settings managed configurations.. I don't have any real reason to say that one approach is better than another, and actually my intention is to find ways (modules) that can adapt to different usage patterns. > Hope my clarification exposes better the rationale behind the second > part. > > > Yes, I understand your approach... but I don't think it's going very far > (given the current trend): Puppet has chosen the "multi-parameter" route > because they want to be able to plug in different data feeds. Neither a > config_hash nor a template are really feed-able. > Well, if this is the path I think it has to be walked with care, at least for scalability issues: - If you use augeas, file_line or similar to manage per-setting configurations you risk to multiply the number of resources for each node. - If you add many parameters to your classes, besides the extra time needed for the data binding lookups, you have higher module's maintenance costs I'm not saying this should not be done at all, but at the same time that should not be the unique way. Choice, IMHO, reusability is all about freedom of choice. Users' choice, not authors. Al > > As a side note, a problem with "forking" the model: when people do fancy > stuff (like the truth_enforcer - I loved the idea BTW - or using special > libraries as requirements) regular users often can't profit from their > modules. Too much effort lost from both sides!! I think PuppetLabs (they > have the steering wheel) is more-or-less clear with how they envision the > "ideal" module. As long as we stick to that, our modules will live longer > and be used more often. This should not prevent us from thinking of > alternatives, obviously. > > BR/Pablo > > > -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/54a0b04c-6f3c-4796-83a8-a184e363dc7b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
