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.soren...@puppetlabs.com - 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]:
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 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.
