On Monday, October 21, 2013 8:14:59 PM UTC-5, Eric Sorenson wrote: > > 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? >
Yes. > > 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... > > Let's also keep in mind that the purpose of the ::params class pattern is not really to serve as a per-module general data repository. Rather, it is specifically to provide a means for indirection of class parameter defaults. To the extent that ::params classes now do serve as data repositories, it is -- or should be -- in service to that purpose, not to a broader one. Data in modules is a *complementary*, but more general, approach whereby default values expressed in DSL code can in some cases be replaced by default values drawn from per-module data. Where data are consumed by a module in other ways or for other purposes, there is no particular reason why a ::params class should be involved. > 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 don't have any particular objection to implementing data-in-modules as a separate full-fledged lookup against a per-module fallback hierarchy, but the qualitative differences from what I suggested are subtle. For the most part, I think it's just a question of how many levels you can or do add to the bottom of the logical hierarchy, whether it's implemented via one call to the hiera subsystem or two. There is a difference, however, in the behavior of lookups that collected data from across the hierarchy, i.e. hiera_hash() and hiera_array(). Those aren't relevant to class parameter binding (at this point), but it is worth considering what semantics are wanted there, and whether there might be a way for the caller to choose. > 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. > I'm with R.I. in suggesting that you get something solid and fundamentally sound out soon, even if it doesn't address every user request on the first go (or ever). I understand how a confederated data source such as you now describe could be useful, but I think such a feature would require a significant effort in its own right. Furthermore, I think you are fast approaching the point where the data subsystem cannot automagically do the right thing in every case. I don't think it would be a sin to require some features to be explicitly declared or invoked by DSL code. For example, perhaps you want a data access function that allows the caller to somehow specify the scope of the data to search. Maybe a couple of releases down the line. John -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
