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]<javascript:>>
> 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] <javascript:>
> > 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] <javascript:>!
> >
> > 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
> >>
> >> 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]<javascript:>.
>
> >> To unsubscribe from this group, send email to
> [email protected] <javascript:>.
> >> Visit this group at http://groups.google.com/group/puppet-dev?hl=en.
> >> For more options, visit 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] <javascript:>.
> > To post to this group, send email to
> > [email protected]<javascript:>.
>
> > Visit this group at http://groups.google.com/group/puppet-dev?hl=en.
> > For more options, visit 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.
