This has been an interesting conversation so far. I'm noticing that most of the things that people seem to want can be currently achieved without touching the Ruby DSL and I find the Puppet DSL to be valuable for the average admin as opposed to digging through "human readable" pure Ruby.
That said: >> 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.... I would suggest using a server side function to implement this if you want to take more of an MVC approach. For define/class foo::bar, you would have function validate_foo_bar() and it would take care of validating your parameters for you with one call. It's not perfect but it keeps your manifests quite a bit less cluttered. >> 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: Isn't this what Hiera is for? Even with extlookup, you could stack data however you liked based on node-specific data. It was clunky and hopefully Hiera does it more cleanly. If you don't like those, you can implement your own ENC and feed Puppet your data in whatever way you like (though the indirector still gives me a headache). If you want to get fancy/insane about the whole thing, you can loop, spawn, and connect different Puppet resources from the 'initialize' define of your own custom types. This may give the Puppet Labs guys fits, but it certainly functions and works around the need for a Ruby DSL. Trevor On Sat, Feb 16, 2013 at 8:28 PM, Ryan Bowlby <[email protected]> wrote: > 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? > > -------------- END RANT --------------- > > 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. > > Who's to say what else I will want to do in the future. It's all likely > supported in Ruby already...seems silly to synthetically limit a manifest. > I look forward to the new ruby-dsl manifest and hope that it gets more love > this time around. > > > Thanks, > Ryan Bowlby > > On Sunday, January 27, 2013 5:03:21 PM UTC-8, Luke Kanies wrote: > >> It's not completely clear from this email, but the point is that we >> will still be adding the new dsl, but not unto 1) users realize there >> will be a new, incompatible dsl, and 2) that new dal is stable. >> >> I think the new dsl was pulled because of these concerns, and since we >> don't know how many people actually use the current one, we don't know >> how big of a problem this is. >> >> -- >> http://puppetlabs.com/ | http://about.me/lak | +1-615-594-8199 >> >> On Jan 26, 2013, at 9:07 AM, Eric Sorenson <[email protected]> >> wrote: >> >> > Sorry Sean, this should have gone out contemporaneously with the >> release -- here's the release note that explains the rationale. >> > >> > Eric Sorenson - [email protected] >> > irc.freenode.net #puppet: eric0 >> > >> > >> > ### Ruby DSL Deprecated, new Puppet Ruby DSL removed >> > >> > 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 >> > reply to this message on [email protected]! >> > >> > Additionally, after testing the revamped Ruby DSL that was in RC1, >> > we made the call not to ship it. This was a tough decision, but the >> > number and severity of issues that came up in exploratory testing >> > led us to the conclusion that it was not supportable code. Again, >> > if there are issues you run into with the Puppet DSL that you wanted >> > to solve with the Ruby DSL, we want to hear about this on the >> > puppet-dev mailing list. >> > >> > >> > On Jan 26, 2013, at 4:31 AM, Sean Millichamp wrote: >> > >> >> 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<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 >> >> >> >> >> >> -- >> >> You received this message because you are subscribed to the Google >> Groups "Puppet Developers" group. >> >> To post to this group, send email to [email protected]. >> >> To unsubscribe from this group, send email to puppet-dev+...@** >> googlegroups.com. >> >> Visit this group at >> >> http://groups.google.com/**group/puppet-dev?hl=en<http://groups.google.com/group/puppet-dev?hl=en>. >> >> >> For more options, visit >> >> https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out>. >> >> > >> > -- >> > 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 puppet-dev+...@**googlegroups.com. >> > To post to this group, send email to [email protected]. >> > Visit this group at >> > http://groups.google.com/**group/puppet-dev?hl=en<http://groups.google.com/group/puppet-dev?hl=en>. >> >> > For more options, visit >> > https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out>. >> >> > >> > >> > -- > 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?hl=en. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 [email protected] -- This account not approved for unencrypted proprietary information -- -- 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?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
