Wow, this looks promising: sane, plain and easy to use. Going to test it soon. Looking at things in perspective, how do you think this approach will go along with the one implemented in Puppet 3.3 ?
al On Sunday, December 8, 2013 11:19:37 PM UTC+1, R.I. Pienaar wrote: > > > > ----- Original Message ----- > > From: "R.I.Pienaar" <r...@devco.net <javascript:>> > > To: puppet...@googlegroups.com <javascript:> > > Sent: Tuesday, October 22, 2013 3:46:45 PM > > Subject: Re: [Puppet Users] Re: Status of Data in modules > > > > > > > > ----- Original Message ----- > > > From: "jcbollinger" <john.bollin...@stjude.org> > > > To: puppet...@googlegroups.com <javascript:> > > > 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. > > I have released a solution to this @ > http://www.devco.net/archives/2013/12/08/better-puppet-modules-using-hiera-data.php > > > Need as wide as possible feedback and testing, lets move forward. > -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/8f174903-cbfc-4d11-831a-37658008f74a%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
