Another round of thanks for the replies to this thread. I apologize that almost as soon as I posted it, I got pulled off onto another project and wasn't able to follow up until now. Replies inline below, and there are probably a couple more coming to different branches (damn I miss Usenet threading!)
John Bollinger wrote: > > 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. John I didn't see a more detailed description of what you're proposing; is this section (quoted from upthread) what you're referring to? 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? Heh, well when you put it that way... > 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? If I understand this correctly this is slightly different (and probably inadequate from RI's standpoint), because it just adds another 'category' (in the ARM-9 sense) to the end of each lookup, and what RI and others propose is to have another _complete hiera invocation_ inside the module owning a class parameter's namespace the end of each unsuccessful site-hiera lookup. Separate hiera.yaml config file with its own hierarchy defined, and a tree of data files. (params.pp does this by letting old-school puppet DSL logic determine your "hierarchy") I also talked to a user today who wants data from modules (by doing hash key merge on a parameter's class::subclass::varname) from *any* module in the modulepath to contribute, say, sudoers rules to the sudo module from other site-written modules that require particular sudoers stanzas. So I'm trying to consider how to pull all of this together without making a O(n^n) complexity explosion. > > RI replied: > 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. > This is really interesting, and not something that's come up so far AFAIK. It ties in somewhat to https://projects.puppetlabs.com/issues/20199 , needing a way to indicate the data type of something that's looked up implicitly with data bindings, but introduces another layer around retrieving and modifying data as it flows back towards puppet, which I hadn't considered. That is what the "code-in-data" people are asking for, like https://github.com/puppetlabs/hiera/pull/152 that ended up with arbitrary puppet functions inside hiera curly brace expansion. Would love thoughts on how to do that in a generally useful, lightweight way. > 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. > Oh surely there's way worse suggestions out there :) > > 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. > > So it doesn't seem helpful to get data-bindings integration via puppet code, even as a first step? I definitely agree hiera data in general needs a way to do validation, but the semantics you described of "requiring an integer between 10 and 20" would be additional complexity on top of Henrik's type system. (That work was foundational BTW, not specific to the data-in-modules binder as you said up-thread, so it can be reused independently of ARM-9) --eric0 -- 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.
