----- Original Message ----- > From: "jcbollinger" <john.bollin...@stjude.org> > To: puppet-users@googlegroups.com > Sent: Tuesday, October 15, 2013 2:08:10 PM > Subject: Re: [Puppet Users] Re: Status of Data in modules > > > > On Tuesday, October 15, 2013 12:52:39 AM UTC-5, David Schmitt wrote: > > > > On 14.10.2013 16:16, jcbollinger wrote: > > > So the proposed solution at this point is: > > > - enable an implicit data-binding lookup against the hiera-puppet > > > backend for a value of 'classname::variable' in the file > > > 'modules/classname/manifests/params.pp', which simplifies class > > > definition and provides consistency with other hiera backends. As a > > > module author, you'd still leave your logic for variables in > > > params.pp, but they'd be implicitly looked up via data bindings as > > > the class is declared, after consulting site-wide hiera. > > > > > > > > > > > > Do I understand correctly that you set out to get rid of the ::params > > > class pattern, but now you favor an approach that depends on that > > > pattern? Why is that better than being more general: enable an implicit > > > lowest-priority hierarchy level for values of form > > > 'modulename::variable', drawing on data from per-module data files such > > > as modules/modulename/data.yaml? > > > > AIUI, prototyping revealed that many params classes contain logic that > > cannot be expressed in .yaml to calculate default values. Making the > > fallback lookup check the params class, the logic can be preserved while > > avoiding verbose boilerplate code like the params_lookup calls in > > Alessandro's modules. > > > > > > I'm not saying that categorically getting rid of ::params classes is a > viable target. In fact, I don't really understand why it was ever an > objective in the first place. On the other hand, I don't see why it makes > sense for Puppet to give special significance to that pattern, either. A > more general data-in-modules feature such as I describe would give users > the option to avoid ::params classes in some cases, and I'm inclined to > think that it would be easier to implement, to understand, and to use. >
there are many reasons to avoid params.pp. It's *code* not *data* and it's one file that tends to include data for many different roles/sources/uses. You have to consider the main reasons for separating data from code in order to understand the motivation. When you have a params.pp you end up with stuff like this: https://github.com/puppetlabs/puppetlabs-ntp/blob/master/manifests/params.pp#L28-140 No-one would call that maintainable or readable vs say having AIX.json, Debian.json and so forth. For a community member who wants to add support for a new OS this simplifies things a LOT. They can see what operating systems are supported already and they can easily add a new one by dropping a single file. This improves the contributor life cycle significantly: * Adding FooOS support will not break existing supported OS support. FooOS.json is only going to be read on FooOS machines. * They do not have to worry about complex merge conflicts on busy modules such as the ones you'd find internal to large companies vs many team members editing a single param.pp * There's no syntax and stuff to bother about, its pretty easy evaluate the data and to pre/post commit check this stuff. Contributor dont have to test extensively to ensure he didnt accidentally mess up params.pp complex nested statements in some subtle manner * In large environments if you have strict change control etc, the previous points help things a lot, you can easily reason about the implications and you can be sure they wont affect existing systems. It's just data that will affect a small subset users. This improves the maintainers life because: * They can find it easier to merge new OS support because the change is contained in seperate files and easy to evaluate * Fewer complex merge commits and easier, cleaner, commit history * The code is simpler and generally easier to maintain in the long term This improves the module user life because: * He can just look at existing data files and know without having to parse complex nested case statements what the available overridable data is and what the keys would be etc. There are more but these are the basics >From a Puppet system perspective its important that this feature behave >consistently and predictably with the current more or less universally accepted standard of data seperation - hiera. And hiera is all about data, the hiera puppet backend has been broken for ages and not been missed because it does not provide a solution that solves the above points. And so the data separation around params.pp will not solve the real problems either. Data simply should not be mixed with logic - because then it becomes code again with all the related problems. -- 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 post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
