Thanks for sending this out Eric. When will there be a release of Puppet with this functionality released? I'm excited to kick the tires on it.
Thanks, Spencer On Fri, Oct 11, 2013 at 11:50 AM, Nan Liu <[email protected]> wrote: > 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 Developers" 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-dev. > For more options, visit https://groups.google.com/groups/opt_out. > -- Spencer Krum (619)-980-7820 -- 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.
