Hey,
Just to jump in at the end, (been following the thread) and looked at the
implementatino of data in modules, but found that the complexity
surrounding it was a bit much for people who were not experienced. Also,
troubleshooting issues with data, i.e. some form of outcome of a puppet run
that didn't match what was expected, created an extra overhead in trying to
identify where the issue lied. We also really only want to return data for
modules which are included on a host.
I therefore wrote a wrapper function which essentially utilises the
hierarchy but with an addition
- modules/%{module_name}/%{klass}
It retreives the classes from the API, using the node indirection.
%{klass} gets defined in the scope as it iterates, (ephemeral_from) and
merges the data it finds, so, if a module as a dependency on another module
i.e. 'foreman' has sudo rules it requires, you could place those within
modules/sudo/foreman.yaml so that you are containing data relating to a
module, without managing different hierarchical configurations throught
your module structure.
For defaults, we defined that as modules/%{module_name}/defaults, which is
the last in the hierarchy.
This probably would haev been nicer if the data sources could utlises the
returned classes in the hierarchy and naturally iterate over the array, to
save the wrapper functinoaity to do it.
Obviously this wouldn't solve all the problems faced with modules or the
principles of the forge modules being usable easily out of the box, but it
solved the issue we had in categorising data within modules. Thought i
would mention our use case.
Jon
On Friday, 11 October 2013 19:09:23 UTC+1, Eric Sorenson wrote:
>
>
> Thanks to everyone who kicked the tires on the experimental data in
> modules feature included in Puppet 3.3.0. We got a lot of feedback, some
> cool proof-of-concept modules, and a definitive conclusion to the
> experiment.
>
> The idea of including a module-specific hiera backend is centered around
> one primary use case: replacing the 'params class pattern', a common idiom
> in Puppet modules that's described in the [Using Parameterized
> Classes][param-classes] guide. The problem that most testers ran into
> though is that for non-trivial modules they ended up having to re-implement
> the Puppet DSL logic encoded in their params.pp in convoluted, non-obvious
> ways. The solutions to this led to more contortions until we'd ended up
> with the ability to execute parser functions in the right-hand-side of a
> yaml value. So something which started out trying to help separate data
> from code ended up putting code back into data!
>
> Additionally, even after multiple attempts to simplify the surface area
> and user experience with the bindings system (described in ARM-9) that
> underlay the data-in-modules implementation, users still found its
> complexity daunting. There are some important bits of scaffolding (like an
> actual type system for Puppet!) that will prove valuable as more of the
> future parser and evaluator work that Henrik is building makes its way into
> the product, but in the final analysis the data in modules feature was the
> wrong vehicle to introduce them.
>
> Refocusing on the problems users were trying to solve (and here I have to
> give shout-outs to Ashley Penney for his [puppetlabs-ntp][] branch and the
> dynamic duo of Spencer Krug/William van Hevelingen for their [startrek][]
> module) and the problems with the 'params' pattern lent some clarity. We've
> gotten into a situation of disparity with regard to hiera and data
> bindings, because data bindings enable module _users_ to use their
> site-wide hiera data but don't provide moduel _authors_ the same
> affordance. But rather than introduce additional complexity, we can close
> the gap for existing code patterns.
>
> So the proposed solution at this point is:
> - enable an implicit data-binding lookup against the hiera-puppet backend
> for a value of 'classname::variable' in the file
> 'modules/classname/manifests/params.pp', which simplifies class definition
> and provides consistency with other hiera backends. As a module author,
> you'd still leave your logic for variables in params.pp, but they'd be
> implicitly looked up via data bindings as the class is declared, after
> consulting site-wide hiera.
> - remove the user-facing '--binder' functionality
> - fix known problems with the hiera-puppet lookups ([Redmine
> 15746][15746], namely, but if there are others that are important to you
> please speak up!)
>
> To show how this would work, I'll rework the ['smart parameter defaults'
> example][param-classes] I linked above, with my commentary behind `##`
> comments:
>
> # /etc/puppet/modules/webserver/manifests/params.pp
>
> class webserver::params { ## nothing changes here...
> $packages = $operatingsystem ? {
> /(?i-mx:ubuntu|debian)/ => 'apache2',
> /(?i-mx:centos|fedora|redhat)/ => 'httpd',
> }
> $vhost_dir = $operatingsystem ? {
> /(?i-mx:ubuntu|debian)/ => '/etc/apache2/sites-enabled',
> /(?i-mx:centos|fedora|redhat)/ => '/etc/httpd/conf.d',
> }
> }
>
> # /etc/puppet/modules/webserver/manifests/init.pp
>
> class webserver( ## inheritance is gone, and
> $packages, ## data bindings look up the defaults
> $vhost_dir ## as webserver::params::vhost_dir
> ) {
>
> package { $packages: ensure => present }
>
> file { 'vhost_dir':
> path => $vhost_dir,
> ensure => directory,
> mode => '0750',
> owner => 'www-data',
> group => 'root',
> }
> }
>
> # /etc/puppet/manifests/site.pp
>
> node default {
> class { 'webserver': } ## no params needed, they're in hiera
>
> ## then in one of my site-wide hiera layers, I can override
> ## the value without modifying the module or class declaration
>
> # /etc/puppet/hieradata/snowflake.domain.com.yaml
> webserver::vhost_dir: '/some/other/dir'
>
> This way the module author (who probably has the most work to do and needs
> the expressiveness of the DSL) can provide default data, but site
> administrators can still override it using mechanisms they're already
> using.
>
> Note too that this is the next iteration, not necessarily the end state.
> It's super important to get this right because the whole community is going
> to have to live with it for a long time; those of you out here on the
> bleeding edge willing to risk some skin to make something awesome are
> critical to making that happen.
>
>
> Eric Sorenson - eric.s...@puppetlabs.com <javascript:> - freenode
> #puppet: eric0
> puppet platform // coffee // techno // bicycles
>
>
> [puppetlabs-ntp]:
> https://github.com/apenney/puppetlabs-ntp/tree/data-in-modules
> [startrek]: https://github.com/pro-puppet/puppet-module-startrek
> [param-classes<https://github.com/pro-puppet/puppet-module-startrek%5Bparam-classes>]:
>
>
> http://docs.puppetlabs.com/guides/parameterized_classes.html#appendix-smart-parameter-defaults
>
> [15746]: https://projects.puppetlabs.com/issues/15746
>
>
--
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/8915ebaf-6b21-400c-8967-60f55e9d8336%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
