----- Original Message ----- > From: "jcbollinger" <john.bollin...@stjude.org> > To: puppet-users@googlegroups.com > Sent: Tuesday, October 22, 2013 3:13:14 PM > Subject: Re: [Puppet Users] Re: Status of Data in modules > > > > 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.
Absolutely, there will never be a single data solution that solves 100% of problems but luckily we have multiple approaches - hiera, ENC, node terminii etc. This user can also write his own hiera backend to achieve his goal. Thats the point. Aim for a solid fit for the 80% of problems, inform and educate by the solution by being prescriptive but with extension points for the 20% of users who have really complex problems who can carry the cost of the complexity solving them brings. For the rest the design of the tool informs how they approach writing manifests and for green fields even how they build infrastructures. There is no chance that a 100% solution will be found for the data problem, just give up. Sometimes it's ok - as in this use case Eric mentions - to just say no that is not in the interest of the larger % of community and we're prioritizing shipping something over pleasing 100% of people. Just say no, point to extension points. ship something - as long as that something isn't impossible to extend for mortals like the arm9 work, because then you have to solve 100% of the 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.
