Ruby DSL deprecated completely?

[Sean Millichamp]

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

[Eric Sorenson]

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.

> --
> 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.
>
>

[Andy Parker]

On Sat, Jan 26, 2013 at 4:31 AM, Sean Millichamp <se...@bruenor.org> 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

It was a fairly quick turn around on this and you are right that it didn't occur on the puppet-dev mailing list. There was some discussion that you can find in the archives of the #puppet-dev IRC channel (http://puppetlogs.com/puppetdev/%23puppet-dev-2013-01-24.log.html).

 

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".

Part of that work is figuring out what those things are. In the IRC conversation you can see that the primary one that was brought up was iteration. Are there other things that you can think of?

 

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

[Luke Kanies]

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

> 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.

[Eric Sorenson]

On Jan 28, 2013, at 2:03 AM, 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.

Sorry for the lack of clarity around this communication. I should have expanded the release note and/or sent this first to get it out early.

After holding the Puppet 3.1 release last week when exploratory testing revealed some show-stopper bugs in the Puppet Ruby DSL, the dev team focused on responding to the issues and getting patches in. Henrik Lindberg and Patrick Carlisle in particular turned in some rapid fixes, but I made the call on Thursday to revert the code entirely.

When we tried to use the new Ruby DSL to accomplish real-world tasks, things blew up in fundamental ways: ruby manifests didn't reload without a puppetmaster restart, resource requirements only worked if the dependent resources came first in the manifest, we absolutely must run on ruby 1.9 or 'exec' resources end up running Kernel.exec on the master... and this was just in a couple of hours of a couple of people testing. All of these things had eventual workarounds, but they led down a path that was so limited, expensive to support, and user-hostile I feel pretty confident Puppet is better off without it.

Ultimately, I feel it would be best to instead focus on improving the parts of the Puppet DSL which address those users' needs that drive them towards wanting Ruby manifests. We threw this out to the "target market" of advanced users via #puppet-dev[1] and got back consistent answers: it basically boils down to variable iteration/expansion and direct access to the scope-related parts of the API. Henrik has already done some interesting work on getting iteration into the Puppet DSL[2] and we'd love feedback on whether this approach works for people who would previously have turned to Ruby.


[1] http://puppetlogs.com/puppetdev/%23puppet-dev-2013-01-24.log.html
[2] http://projects.puppetlabs.com/issues/11331


Eric Sorenson - eric.s...@puppetlabs.com
#puppet irc: eric0

[Nan Liu]

On Fri, Feb 15, 2013 at 6:52 AM, Leo Simons <ma...@leosimons.com> wrote:

Hey folks,

On Saturday, January 26, 2013 6:06:55 PM UTC+1, Eric Sorenson wrote:

### 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!

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 profile

We 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" do

  management = scope.lookupvar("management")

  # for example, 'local' is not to be monitored

  exclude = 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 soon

    if env == "deleted" or exclude.include? env

      next

    end

    hosts.push(host)

  end

  rsyslog_clients = {

    "rsyslog::hosts::config" => {

      "rsyslog_clients" => hosts

    }

  }

  create_resources(['rsyslog::config', rsyslog_clients])

end

init.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 letters

  Warning: 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 :)

Since you are passing data to create_resources, how about a rvalue function?

module Puppet::Parser::Functions 

  newfunction(:rsyslog_client, :type => :rvalue)

  # copy what you have currently before the create_resource call.

  end

end

class rsyslog::hosts {

  create_resources('rsyslog::config', rsyslog_client)

} 

You might even be able to consolidate them if they use the same pattern.

Nan

[Gavin Williams]

Yeh, as nan suggests i've done something similar with an rvalue function that takes a loaded yaml file, and then parses it dependant on 2 input parameters...

Then use that response to drive create_resources :-)

Might be an easy way to do away with the dsl stuff ure doing...

Hth
Gav

[Ryan Bowlby]

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

[Trevor Vaughan]

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

--
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699
tvau...@onyxpoint.com

-- This account not approved for unencrypted proprietary information --

[Erik Dalén]

On 17 February 2013 02:28, Ryan Bowlby <rbow...@gmail.com> wrote:

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. 

You can do something like this instead:

unless $::class::parameterized_var in ['foo', 'bar'] {

  fail("$name expects \$parameterized_var to be one of: foo or bar.")

}

And you could set a varialbe to contain the list of allowed values and reuse it to build the error message using the join() function. I don't really see how this would be that much easier in ruby.

 

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.

there is a merge() function in stdlib that should let you do it.

 

--
Erik Dalén

[Luke Kanies]

On Feb 16, 2013, at 5:28 PM, Ryan Bowlby <rbow...@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.

-- 

Luke Kanies | http://about.me/lak | http://puppetlabs.com/ | +1-615-594-8199

[Ryan Bowlby]

Thanks Luke, those are great answers. Great replies all around. We
have over 60 internal puppet modules for our components, and I find
myself cringing at the occasional new puppet-user mistake during code
reviews (like an exec instead of the file type to create a symlink). I
can't imagine how often I would cringe if it had all been written in a
ruby-dsl. There are over 20 people committing at the company, so it's
easier to code-review the puppet-dsl than it would be a ruby-dsl.

If it was just me responsible for configuration management and I was
starting from scratch all over again, I'd use the fictional puppet
ruby-dsl plain and simple. At least once a day a problem presents
itself that isn't as easily solved with the puppet-dsl. Reimplementing
the merge method as a function in stdlib...still seems like
unnecessary abstraction to me. I genuinely hope your initial plan -
way back when - of having a ruby-dsl as a layer below the puppet-dsl
comes to be. I'll forever be pissed that the chef people couldn't have
just contributed to a puppet ruby-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.

Compiled catalogs have never been a problem in my experience. The
client/system shouldn't be so important as to need to "edit" a local
file. Central compilation without knowledge of client, beyond facts,
keeps people honest. Plus central partial catalog caching with
puppetdb will save cputime and trees. Systems should remain disposable
at all times; it's a paradigm shift and some likely don't get it yet
(imo).

Though, I still think better integration of the file resource type and
the file-modifiers is appropriate.
http://projects.puppetlabs.com/issues/15301 ;)

file { "/etc/sysctl.conf":
ensure => present,
content => template("sysctl/sysctl.conf.erb"),
modifiers => true,
}

file_line { 'swappiness':
path => '/etc/sysctl.conf',
line => 'vm.swappiness 10',
}

Thanks for all you guys do,
Ryan

[Andy Parker]

I met yesterday with a puppet user in London and he showed me a couple things
in his manifests that he felt weren't ideal. One of these cases is a great
candidate for iteration in the language. However, both can also be handled by
using existing structures (one already is, but could be done better).

The first case involved repeated use of "if" to decide what classes to include.

if(has_role("web")) {
class { "our_web": }
}

if(has_role("db")) {
class { "our_db": }
}

# etc.

This can be handled instead in several different forms once there is more
support for collections. The pattern that was showing was that each role
corrosponds to a different class that needs to be included. The class name
could either be constructed or looked up.

$role_classes = {
"web" => "our_web",
"db" => "our_db"
}

# possible transformations:

$roles.foreach { |$role| include $role_classes[$role] }

# or

include $roles.collect { |$role| $role_classes[$role] }

# or

include($roles | $(x) => $role_classes[$role])

# or

$roles | $role_classes[$it] | &include

This also has the possibility of being handled by a defined type, since it
really is a collection of roles being applied.

role { $roles: }

define role() {
$role_classes = {
"web" => "our_web",
"db" => "our_db"
}

class { $role_classes[$title]: }
}

Another pattern that I was shown was to use the fact that a defined type is
expanded across the elements of an array.

$data = [
{ file => "first", content => "data1" },
...
]

my_type { $data: }

define my_type() {
file { $title[file]: content => $title[content] }
}

This is an ingenious way to use the auto-expansion of resources over titles,
but it causes the problem that in logging output the title of the "iteration"
type becomes an unintelligable mess. This pattern can already be handled by
using the create_resources function if the input data is changed a little bit

$data = {
"first" => { content => "data1" },
...
}

create_resources(file, $data)

However, for whatever reason maybe the data cannot be changed. In that case the
transformation of that data is going to need to take place in the puppet
manifests.

$data = [
{ file => "first", content => "data1" },
...
]

# possible transformations:

$data | file { $it[file]: content => $it[content] }

# or

$data.foreach { |$item| file { $item[file]: content => $item[content] }

# or (assuming a function to_hash: Array<Pair> -> Hash

create_resources(file, to_hash($data | [$it[file], { content =>
$it[content] }]))

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.

> 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.

[Pieter van de Bruggen]

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.

+1

In my own (small) use of Puppet lately, I've keenly felt the lack of data transformation function, even as simple as "I've got a list of usernames, I want a list of paths to their .bashrc files".  Totally doable with a defined type, but ridiculously verbose for what most Rubyists (and JAPHs, and Pythonistas) would consider a one-line task.

[Erik Dalén]

I don't know the exact details, but it sounds like you should be able to fetch that sort of stuff using a custom function.

For example I use custom functions for fetching LDAP data, inventory system data (using a rest API) and PuppetDB data.

--
Erik Dalén


On Friday 29 March 2013 at 16:48, Michael Owings wrote:

> We use the DSL in production here as well, particularly for getting cluster metadata and configuration out of both AWS tags and Zookeeper. Deprecation would probably keep us from upgrading until we had a DSL with similar capabilities

>
> On Saturday, January 26, 2013 11:06:55 AM UTC-6, Eric Sorenson 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 (javascript:)
> > irc.freenode.net (http://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 (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 puppe...@googlegroups.com (javascript:).
> > > To unsubscribe from this group, send email to puppet-dev+...@googlegroups.com (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 puppet-dev+...@googlegroups.com (mailto:puppet-dev+...@googlegroups.com).
> To post to this group, send email to puppe...@googlegroups.com (mailto:puppe...@googlegroups.com).