Issue #16856 has been updated by R.I. Pienaar.
Andrew Parker wrote: > > Aha! I think you've identified the new use case that all of the present ways > of doing this cannot handle. In the case where an organization makes a > distinction between data in the code and the code itself having this kind of > separation can be an immense help. > To be clear, there is nothing new about this. Hiera exist and is used widely for exactly the listed reasons and many more. When considering the role of for example inheritance as a means of creating data the common conclusion is that its inadequate as a means of code management and data management at a macro scale for an entire site comprising many roles/locations/environments etc. Hiera and in general code/data separation by a configurable hierarchial backend solves these problems well at a macro scale and have done so for 4 or 5 years now - extlookup being a early capable version of the same. So these benefits are well known and have become basic practice in the community to the point of being the default answer whenever data is discussed. It's how the community think by default now. What was absent was a way for the module author to reap these same benefits on a micro scale of a single module. Even with the old hiera-puppet backend the module author could not in a way that had an impedance match with hiera - which he was already using at site level: * bundle default data with his module on the forge or internal code share in the hiera way * ensure this data gets consulted when he shared his module So we forced them to use inheritance and the params.pp pattern in his module. This seems to be against the generally accepted wisdom that inheritance was a bad fit in Puppet on a macro scale and the module author already understood well the value of code and data separation but could not reap those benefits on a micro scale. So what this PR does is bring the many existing and widely realized benefits of hiera into the module space and create a suitable way to access the those even for modules he wish to share outside of his own team onto the forge etc. This enhances the overall consistency of code and allow us narrow down the way we think modules should be built to be in line with how people currently manage the other data for their site. ---------------------------------------- Feature #16856: puppet should support data in modules https://projects.puppetlabs.com/issues/16856#change-79169 Author: R.I. Pienaar Status: Needs More Information Priority: Normal Assignee: R.I. Pienaar Category: Target version: Affected Puppet version: Keywords: Branch: https://github.com/puppetlabs/puppet/pull/1217 At present there is a way to store data in modules using the puppet backend for hiera but it is optional and kind of broken. The site hierarchy impacts how the puppet backend behaves which makes it impossible for module authors to supply data in their modules they can rely on I propose a new hiera backend that loads a hierarchy of data from the 'data' directory in the module, this module must always be present in a puppet install. This ability is key to the ability to create configurable forge modules that do not have hard coded values thanks to the puppet 3 hiera integration reference the users list thread https://groups.google.com/d/topic/puppet-users/pvqzeyHkrY4/discussion -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
