On Fri, Oct 11, 2013 at 1:09 PM, Eric Sorenson <eric.soren...@puppetlabs.com
> 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.
>
Thanks for sending a summary.
> 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.
>
Yep, in trivial cases hiera data layer can approximate conditional in
params.pp, but the I can see how the complexity ramps up rapidly.
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.
>
So this is only limited to class variables? and this is still compatible
with inherits params class (to ease migration)?
> - 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.
Totally understand the need for proof of concept, should there be
experimental branch v.s. production branch (i.e. Linux kernel)? Would
appreciate an official notice when a final pattern is decided for long term
support.
Thanks,
Nan
--
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 post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.
