On Fri, Oct 11, 2013 at 1:09 PM, Eric Sorenson <[email protected]
> 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 [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.
