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.
On Sat, Jan 26, 2013 at 9:06 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
>>
>> 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
>> [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.
>>
>>
>
> --
> 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.
>
>
--
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.
