Hi all, let me reply to this old thread to announce the release of Tiny Puppet, a module that allows installation and configuration of virtually any application on any OS.
This post was originally started to find a way to solve a problem at the core of Tiny Puppet working concept (based on defines and not classes). I then followed another approach, based on a custom function, as suggested by John in one of the replies, which mimics Hiera behaviour and gets inspiration from the data in module concept. For more details on Tiny Puppet refer to the post on Puppet Users and the links there: https://groups.google.com/forum/#!topic/puppet-users/_ZhYQBC8UP0 Incidentally, I'm quite proud and excited by this achievement and would be grateful to hear any feedback or comment about it (eventually directly in the Puppet Users announce post). Best regards and wishes for a great new year to everybody, Alessandro Franceschi On Saturday, May 31, 2014 7:13:38 PM UTC+2, Trevor Vaughan wrote: > > +1 Data in modules is absolutely necessary! > > > On Sat, May 31, 2014 at 10:18 AM, Daniele Sluijters <daniele....@gmail.com > <javascript:>> wrote: > >> > So, if you're willing to depend on other modules, then I think >> ripienaar/module-data >> <https://forge.puppetlabs.com/ripienaar/module_data> combined with >> explicit lookups can do a lot of what you're after. >> >> Honestly, that should just be part of Puppet core. It's such an >> incredibly useful feature and would go a long way to help people out in >> such scenario's. It might not be the utopia Alessandro is shooting for but >> it's certainly a good compromise. >> >> >> On Tuesday, 27 May 2014 17:41:11 UTC+2, John Bollinger wrote: >>> >>> >>> >>> On Monday, May 26, 2014 11:01:59 AM UTC-5, Alessandro Franceschi wrote: >>>> >>>> >>>> >>>> On Tuesday, May 20, 2014 6:25:10 PM UTC+2, John Bollinger wrote: >>>> >>> >>> [Al:] >>> >>> >>>> If you have any suggestion on how to use directly Hiera that would be >>>> welcomed, as usual. >>>> >>>> >>>>> >>>>> >>>>> > Thanks anyway for the attempt, hopefully now is clearer why I can’t >>>>> do this with existing functionalities. >>>>> >>>>> >>>>> Your requirements are clearer, yes. What's not quite clear yet is >>>>> whether you want to avoid your data binding falling back to general data >>>>> when resource parameters are not found in module-specific data. If you >>>>> do >>>>> want to avoid that then I think you're right that existing >>>>> functionalities >>>>> won't do what you want, but then I'm certain that you were wrong earlier >>>>> about what you want being achievable by a simple modification. >>>>> >>>> >>>> Well, if data binding for defines is not a possibile approach, the >>>> module will have its internal default values for parameters and accept >>>> (of >>>> course) users' overrides. >>>> I still have to figure out how to merge user provided data with >>>> internal default data ( I think it make sense to expose a parameter that >>>> let the user define the merge behaviour) >>>> >>>> >>> >>> >>> To what extent would you still have this problem if you could use hiera >>> directly? I'm thinking that the issue there might be only that there are >>> parameters that you wish to actively prevent the user from overriding. If >>> that's the only thing, then would you be willing to give up active >>> enforcement for documentation (i.e. telling users "don't do that")? >>> >>> >>> >>>> >>>>> On the other hand, I think you could put a custom function into module >>>>> 'tp' that would read data from (only) a module-specific data source, >>>>> along >>>>> lines similar to hiera. If you used such a function instead of hiera(), >>>>> then could a solution along the lines I described work for you? >>>>> >>>> >>>> Yep, the tp_lookup function mentioned earlier is expected to do what >>>> I'd have preferred to do via Hiera data bindings (on defined params) + >>>> module in data. >>>> >>> >>> >>> So, if you're willing to depend on other modules, then I think >>> ripienaar/module-data >>> <https://forge.puppetlabs.com/ripienaar/module_data> combined with >>> explicit lookups can do a lot of what you're after. It gives you an >>> always-on (doesn't depend on the user modifying hiera.yaml), in-module data >>> source from which you can look up the needed data. For defined types and >>> current Puppet, that necessarily involves explicit lookups, as we already >>> discussed. >>> >>> If that combination leaves essential features unserved, then perhaps at >>> least R.I.'s module can give you ideas for how to build your own -- maybe >>> just the same thing but defaulting to highest priority. >>> >>> >>> John >>> >>> -- >> You received this message because you are subscribed to the Google Groups >> "Puppet Developers" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to puppet-dev+...@googlegroups.com <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/puppet-dev/579481e0-f2bd-4162-b846-6602824c3c4e%40googlegroups.com >> >> <https://groups.google.com/d/msgid/puppet-dev/579481e0-f2bd-4162-b846-6602824c3c4e%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > Trevor Vaughan > Vice President, Onyx Point, Inc > (410) 541-6699 > tvau...@onyxpoint.com <javascript:> > > -- This account not approved for unencrypted proprietary information -- > -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/9f6e0b4f-7b63-4184-8235-d818ece3691f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
