Issue #11331 has been updated by Henrik Lindberg.
Daniel Pittman wrote:
> It would be really nasty to be limited to only a single expression in the
> loop body. That still requires writing an explicit define for any
> non-trivial case, such as needing two resource specifications.
>
The proposal allows multiple statements.
> It would be much nicer to treat the whole thing like the "use an array and a
> define" expansion trick, so that you get the same capabilities as the current
> model - just a nicer syntax.
>
With the current proposal it would look like this (implies using a defined
'my_thing') . showing both proposed equivalent styles:
<pre>
data.forearch {|$x| my_thing { 'somename_$x': param_1 => $x }}
foreach(data) {|$x| my_thing { 'somename_$x': param_1 => $x }}
</pre>
> (I think the `foreach` name is a bit ugly, too, and would prefer something
> like `expand`, but whatever. :)
"foreach" is not my favorite either, that is probably the easiest thing of them
all to change and at the same time be what will take the longest to decide :)
How would you like to see the "expand" taking place; how would you specify what
to map from LHS structure (array or hash) onto a define, what if you want/need
to make a transformation, would you have to write another define for that?
(i.e. comparable to being able to map to only named functions as opposed to
mapping to unnamed lambdas).
----------------------------------------
Feature #11331: Add 'foreach' structure in manifests
https://projects.puppetlabs.com/issues/11331#change-82166
Author: Steve Shipway
Status: Needs Decision
Priority: High
Assignee: J.D. Welch
Category: language
Target version: 3.x
Affected Puppet version:
Keywords: ux backlog
Branch: https://github.com/puppetlabs/puppet/pull/1420
I doubt this would be simple to do, but it would be very useful to be able to
do something like this:
$variable = [ 'a', 'b', 'c' ]
foreach $loop $variable {
file { "/tmp/$loop": content=>"I am file $loop"; }
}
While it is already possible to use an array as a namevar to get something
similar, it doesnt allow you to have calculated parameters as well.
This would not be expected to break the declarative nature of puppet, though it
would bring in a new variable scope in the loop.
Using a define with an array for the namevar would work provided the top level
could not be called multiple times.
We want to have something like this:
define firewall($users,$port) {
iptables::open { $users: port=>$port; }
}
node foo {
$webusers = [ 'fred', 'sid' ]
$sshusers = [ 'fred', 'joe' ]
firewall { port80: users=>$webusers, port=>80; }
firewall { port22: users=>$sshusers, port=>22; }
}
This example would fail because the iptables::open define is called with user
'fred' two times (although with a different port parameter). If we could
instead have a foreach iteration then something like this would be useable:
define firewall($users,$port) {
foreach $users {
iptables::open { "$loop:$port": user=>$loop, port=>$port; }
}
}
This would ensure a unique namevar for iptables::open. We would also be able
to do things like initialise an array of users with different metadata
parameters (eg, their full names pulled form LDAP)
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://projects.puppetlabs.com/my/account
--
You received this message because you are subscribed to the Google Groups
"Puppet Bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
