On Feb 16, 2013, at 5:28 PM, Ryan Bowlby <rbowlb...@gmail.com> 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.
Which Ruby DSL? Not the current one, because it doesn't work in nearly the
cases people need. Not the one we (unfortunately) had to pull from 3.1,
because it doesn't work at all.
This is one of the major problems - we've got a theoretical ruby DSL that would
make life much better, but not an actual one people can really use. In
contrast, we have a Puppet language that people use every day and with real
success.
> 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.
Note that most of those people are purposefully setting out on some programming
project.
Don't get me wrong - we're actively trying to find ways to make the balance
between power and simplicity better, because I know it's not as good as it
could be today, but we hear every day from customers who cling desperately to
Puppet's simplicity, and we also hear from a lot of Chef users that the full
ruby support is often more trouble than it's worth.
Writing a single stand-alone application like a Rails app is a fundamentally
different, and much much easier, problem than writing what looks a lot like a
distributed application running on thousands of machines.
> 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?
Puppet doesn't actually support any iteration or looping that I know of, other
than maybe titles as arrays resulting in multiple resources. It doesn't
support monkey-patching, metaprogramming, or any number of other things.
You get portability. I actually would like to replace ruby as our runtime, but
we obviously can't do that if ruby is our input language.
Which ruby? Ruby 1.8.5 is incompatible with 1.8.7 is incompatible with 1.9.0
is incompatible with 1.9.1 is incompatible with 1.9.2.
Really, though, what you get is a language primarily built around specification
rather than procedural programming. Yes, Puppet's language has some
programming in it, but it's specification first and programming second, whereas
ruby is programming first, and maybe some data structures when you feel like it.
You can do lots of checking in Puppet that you can't easily do in other
languages because we have full control over the DSL. Part of this is because
we have a separate compile phase, where we create the catalog that gets sent to
the client, but I think most people don't just want to can the DSL, they want
to can that compile phase; I haven't heard specific discussion of that, though.
I just assume people want to do things like be able to edit files on the
remote system, which is a huge difference from the current workflow.
My ultimate goal for Puppet's language is that it be the lingua franca of the
infrastructure - that we replace package manifest formats, OVF file formats,
etc., all with a simplified version of Puppet's language. It has both syntax
and semantics, whereas something like JSON only has syntax. We're obviously
lagging in that goal, but I'm not quite ready to give up on it.
> 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?
We're trying to figure out how to remove things from Puppet, not add them.
E.g., I think the whole query/exported/virtual system has gotten out of hand
and needs to be dramatically simplified.
However, there seem to be a couple of things people can't live without, like an
easy to do something that looks like iteration. I'm fighting to not have full
iteration, for exactly this reason, but I don't really have a great
counterproposal.
> -------------- 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 <eric.s...@puppetlabs.com> wrote:
>
> > Sorry Sean, this should have gone out contemporaneously with the release --
> > here's the release note that explains the rationale.
> >
> > Eric Sorenson - eric.s...@puppetlabs.com
> > 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 puppe...@googlegroups.com!
> >
> > 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 puppe...@googlegroups.com.
> >> 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.
> >> 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 puppet-dev+...@googlegroups.com.
> > To post to this group, send email to puppe...@googlegroups.com.
> > 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 puppet-dev+unsubscr...@googlegroups.com.
> To post to this group, send email to puppet-dev@googlegroups.com.
> Visit this group at http://groups.google.com/group/puppet-dev?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
--
Luke Kanies | http://about.me/lak | http://puppetlabs.com/ | +1-615-594-8199
--
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+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-dev@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-dev?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
