----- Original Message ----- > From: "jcbollinger" <john.bollin...@stjude.org> > To: puppet-users@googlegroups.com > Sent: Wednesday, October 16, 2013 4:23:17 PM > Subject: Re: [Puppet Users] Re: Status of Data in modules > > > > On Tuesday, October 15, 2013 8:35:00 AM UTC-5, R.I. Pienaar wrote: > > > > > > > > ----- Original Message ----- > > > From: "jcbollinger" > > > To: puppet...@googlegroups.com <javascript:> > > > 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 > > > > > Eric observes -- and this comes as no surprise to me -- that the reason it > didn't work well to eliminate params.pp was that sometimes you *need* code > to help set appropriate default parameter values. Or at least that is the > practical conclusion that arose from field testing the original approach. > I am all for pushing the actual data out of manifests, but you still need a > place to hang code. Pushing code out into the data to allow ::params > classes to be dropped does not achieve the objective of separating data > from code. > > > > > one file that tends to include data for many different roles/sources/uses. > > > > > That's a fair observation, though a bit usage-oriented. Nothing prevents > users from creating a separate class::params class for every single class, > which would at least partially address that. In any case, the proposed new > data in modules approach does nothing to address that concern -- if > anything, it magnifies that problem. If the objective is still to avoid > params.pp, then why does the revised data in modules proposal provide data * > only* to ::params classes? > > > > > > > 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 > > > > > > That sort of thing is not really the issue. I think we pretty much all > agree that pushing that out to an external data source is a win. The issue > is with cases where the rules for choosing parameter defaults are more > complex than a simple switch based on one fact. As I understand Eric, > field testing showed that users wanted to be able to perform essentially > arbitrary logic to *compute* the data provided to modules. I agree with > his conclusion that rolling such logic into the data is as bad as putting > the data into ::params classes. Thus both are needed, and ::params classes > or an equivalent serve a useful continuing role. > > > > > 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. > > > > > > We agree on most of what you said, but it doesn't seem very responsive to > the comments to which they ostensibly reply. I am in no way arguing > against the idea of the data in modules subsystem. It is a fantastic idea, > and long past due. I *am* concerned, however, about the new approach Eric > proposed. I suggested a more general approach than (my understanding of) > the one he described, one not tied specifically to ::params classes. > Inasmuch as you disfavor ::params classes, I would think that you would > find much to like about my counterproposal. Indeed, I think my proposal is > very much like the original prototype you floated.
Your comments are good and addressed in later replies, especially related to data mangling. This is a common problem in all languages, data almost never arrives in the final form and all programming languages have patterns for retrieving data, validating and mangling it. We just need to introduce similar patterns. I, obviously, share your concern with the current round of proposals. Data in module querying only params.pp is literally the worst possible suggestion one can make in this regard. It would be a massive step backward. Might as well just go ahead and unmerge hiera if the goal is to not learn anything from its design and incredibly wide adoption. > I do think it is a mistake to focus on eliminating all need for ::params > classes as a goal of the initiative, however. Likely *most* need for them > can be redirected to a relatively simple data-in-modules subsystem, and > that would be well, but the initiative does not fail if some need for the > ::params class pattern remains. yeah, as per the other replies - eliminate *storing data* in params.pp but validate/mangle in something like params.pp. That is in the event that no-one delivers a layer of data validation around data bindings and hiera. -- 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.
