I've looked on the mailing lists and don't see any community discussion or announcement of what is (to me) a major course change in significant Puppet features, the deprecation of the existing Ruby DSL (expected) and the decision to not replace it with the new one (not expected):
https://projects.puppetlabs.com/issues/18876
Maybe I'm the only one who was looking forward to this, but this has me pretty disappointed and somewhat concerned that this means a long-term limitation of the sophistication and expressiveness available to modules.
The ticket has an update by Andrew Parker indicating that Puppet language is going to be worked on to address the shortcomings which might cause someone to need to use the Ruby DSL. That's great news, I suppose, but there is no indication of what Puppet Labs thinks those features are or when we might see them and the new Ruby DSL felt "right around the corner".
Does anyone from PL want to comment? Personally, I'd love to see a "When the Puppet DSL has these things fixed / enhanced, we think it will be all you ever need" list.
Sean
On Saturday, January 26, 2013 6:06:55 PM UTC+1, Eric Sorenson wrote:
### Ruby DSL Deprecated, new Puppet Ruby DSL removedreply to this message on puppe...@googlegroups.com!
We introduced deprecation warnings for the (not-well-documented,
mostly-unused) Ruby DSL; if you are using the Ruby DSL in production
we want to hear from you to learn what you're doing with it -- please
Well, ok :-)We are currently using the ruby DSL in production and we're pretty dependent on it. We don't like this setup very much (mostly because it's undocumented and fragile!), but there's a few things we can't figure out how to accomplish with the puppet DSL, yet we aren't rubyist enough to write elaborate plugins.We have a custom external node classifier which is a pretty simple ruby script that reads in a set of YAML files and merges them together. These files include* config.yml with various global/default config* systems.yml defining every system* profiles.yml defining the classes for every profile* environments.yml defining all environments and customized settings per environment* apps.yml defining all apps (java webapps, ruby webapps, ...) that are installed into every profileWe then have profiles for management servers (certificate authority, syslog host, monitoring host, ...) that need to know about all the other systems (for example to open up firewalls, open up syslog for connections from other hosts, write per-app custom nagios classes, generate CRLs, ...). The fiddly solution we have for that involves some custom classes written with ruby DSL that read in one or more of the above YAML files (or in some cases, even re-invoke the external node classifier), and then call create_resources() to hand control back to puppet.For example, here's how we tell the rsyslog host about the machines it should accept connections from:hosts.rb----hostclass :"rsyslog::hosts" domanagement = scope.lookupvar("management")# for example, 'local' is not to be monitoredexclude = management['exclude_environments']nodes = YAML::load( File.open( '/etc/sys/puppet/systems.yml' ))hosts = []nodes.each do |host, params|env = params['env']# 'deleted' remembers machines that will be decomissioned soonif env == "deleted" or exclude.include? envnextendhosts.push(host)endrsyslog_clients = {"rsyslog::hosts::config" => {"rsyslog_clients" => hosts}}create_resources(['rsyslog::config', rsyslog_clients])endinit.pp----...define rsyslog::config($rsyslog_clients) {
file { "/etc/rsyslog.conf":owner => root,group => root,mode => 644,content => template("rsyslog/rsyslog.conf.erb"),require => [Class["rsyslog::packages"],Exec["rsyslog-ssl-cert"],],notify => Service["rsyslog"],}}...rsyslog.conf.erb----...<% rsyslog_clients.each do |client| %>$InputTCPServerStreamDriverPermittedPeer <%= client %><% end %>...So you can imagine my brief panic when my local test puppet VM greeted me this morning with big fat red lettersWarning: Use of the Ruby DSL is deprecated.
(at /usr/lib/ruby/vendor_ruby/puppet/parser/parser_support.rb:140:in `parse')I counted, we have only 6 such custom hostclasses, they're all less than 50 lines, and they all follow pretty much the same pattern.
I would not mind at all getting rid of the ruby DSL stuff in favor of something else, but, since I see no alternative yet, and since you asked for it, I thought I'd write about our particular flavour of iteration use case :)
Then use that response to drive create_resources :-)
Might be an easy way to do away with the dsl stuff ure doing...
Hth
Gav
Some things I'd like to see in the Puppet DSL since the Ruby DSL is deprecated:1. functions/subroutines - Currently, if I want to verify that a class or define parameter is one of a few key values then I have to do something like:if $::class::parameterized_var !~ /^(foo|bar)$/ {fail("$name expects \$parameterized_var to be one of: foo or bar.")}Then more or less to that all over again for every other parameter used in that manifest that I want to verify. What would be better is a simple refactor to a function/method.
2. access to basic ruby data type methods - Say I have a sysctl class that has a hash of values that are normal RH5 defaults (from sysctl.conf). Then another hash of company-wide defaults. Then a class parameter that takes host specific overrides. So then I want all three sets of values, with the host specific parameterized values taking priority over company-wide, which takes priority over defautls. In a ruby-dsl manifest:sysctl = redhat_defaults.merge(company_defautls.merge(host_overrides))Sure I can do it in the sysctl.conf.erb file, but that really hides the logic (skinny view); and again I'm using ruby so why not let me do so in the manifest.
Let me preface this with the fact that I use, and love, Puppet. Feel free to skip to the feature requests.----- BEGIN RANT ------Is it really worth the effort to re-implement the features already available in ruby within the puppet DSL? I'd rather see the puppet DSL deprecated and the ruby DSL promoted to first class citizen.
Tons of people can get pretty far developing a rails app without any prior knowledge of ruby. Yet, those people are coding in ruby and not a non-ruby-like DSL. I'd prefer strong conventions over a limited DSL. Both rails conventions and the puppet DSL lead you in the right direction, but with rails the convention can be broken where appropriate. The same can't be said for the Puppet DSL.
In the end the need for a Puppet DSL appears to be based off certain assumption that I believe are less true today:1. Persons doing configuration management may or may not have prior scripting/programming knowledge. This knowledge should not limit their ability to use Puppet.Yes it should, limit their ability to use puppet that is. Puppet requires at least a nascent understanding of data types, looping constructs, conditionals, subroutines, "classes", inheritance, and just about every other normal construct. This is also true for Ruby. So then, what major benefit does the Puppet DSL provide over a Ruby DSL?
2. The problem domain that configuration management addresses is small enough that it can be wholly defined within the puppet DSL.I agree, so long as we all continue to expand our definition of configuration management and Puppet continues to expand its' feature set. A feature set that now contains most of the basic programming constructs. What then, is the purpose of the puppet DSL over the ruby DSL?
What I see in these examples is a need for a way of manipulating the
data (collect,
select, reject, etc.). Once the data is manipulated correctly, then
create_resources and title expansion can take over.