Issue #16856 has been updated by Ryan Coleman.
R.I. Pienaar wrote: > Few comments then as it relates to the ARM - we can't comment on the ARM > itself which makes it quite pointless. > > * We should put this in the modulefile for sure, what's the next step here? > Ryan had been quite vocal that the forge team owns it, if this ticket is a > priority how do we get a proposal in from them? > * +1 to removing the plugability of the data bindings. The hiera backends > should be good enough, so what's the next step? > * The lookup policies are a legit concern, but this does not really relate > to this ticket its a larger improvement to puppet and the binding system. > Merging this ticket as is even without that point addressed would add a great > amount of ability and later once addressed this feature will simply become > better in line with the rest of the data binding system. > > So I do not see much here that's blockers or requiring a pull request to the > ARM to address. The user stories seem well catered for by the proposed > solution. > > The actions should be: > > * Get team forge to state how they wish to integrate this into the > modulefile - a PR to the arm would do that though this ticket would be a more > central source of truth as its obvious this is where everyones eyes are. TL;DR, I don't wish to integrate in-module hiera data into the modulefile. You have stated in the past that you (I'm paraphrasing) expect in-module data to allow module consumers to more easily contribute patches upstream that support additional operating systems. Cool. The Modulefile/metadata.json files are the authors expression of module metadata that allow them to publish to the Forge. It's only meant for their manipulation and it's critical to the operation of Forge and the module tool. If we store hiera data in this file, we're introducing a use-case for the consumer to manipulate this file. If they decide to carry a patch locally or their submitted patch isn't accepted upstream, now you cannot upgrade your module without resolving the conflict in the modules metadata. This doesn't seem optimal. If all we're buying is reducing the number of files that make up a module, I don't think it's worth it. Instead, I suggest that you go with another file or folder/file structure for this purpose. > * Adjust the PR to work with the module file and merge it > * Independently in an additional ticket remove the plugin ability from the > bindings > * Independently in an additional ticket rewrite hiera if the backends arent > considered to be adequate replacements for the binding backends > * Independently improve the ability to specify merge policies for keys > > Only steps 1 and 2 are really blockers here, the rest of the points would be > incremental improvements that slowly improve this feature but wouldn't change > how it functions - they would only add abilities not remove any, I do not > think there are many custom data binding backends out there that we'd block > this for those given just how many people want this feature and how many > significant problems it solves. ---------------------------------------- Feature #16856: puppet should support data in modules https://projects.puppetlabs.com/issues/16856#change-89047 * Author: R.I. Pienaar * Status: Needs More Information * Priority: Normal * Assignee: eric sorenson * 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 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-bugs?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
