[Puppet - Bug #18565] (Rejected) filebucket doesn't seem to inherit server
Issue #18565 has been updated by Paul Tötterman. Status changed from Needs More Information to Rejected You should use the puppetlabs registry module to configure the dns suffixes :) http://support.microsoft.com/kb/275553 seems to imply that this no longer works on Windows 7. What does your filebucket resource look like? And a file resource that is configured to backup into that filebucket? Are you sure that the filebucket resource uses a fqdn, something like: Ah, good thinking. It did not have the fqdn. Or alternatively, use the value `$servername` so that it uses the same setting as `Puppet[:server]`. $servername worked beautifully, thank you! Bug #18565: filebucket doesn't seem to inherit server https://projects.puppetlabs.com/issues/18565#change-81491 Author: Paul Tötterman Status: Rejected Priority: Normal Assignee: Category: windows Target version: Affected Puppet version: 3.0.2 Keywords: windows dns filebucket config Branch: I have a puppet master at puppet.example.com. Windows machines in the same zone, e.g. win1.example.com have been using puppet just fine. Now I installed windows machine in another zone, sub.example.com, with the machine being, e.g. win2.sub.example.com. That machine didn't find the puppet server (because windows doesn't get dns search list from dhcp, sigh) and I get the getaddrinfo: The storage control blocks were destroyed -messages referenced in the windows troubleshooting documentation. So I edit puppet.conf, and make sure that the line with server = has the fqdn, puppet.example.com. Puppet is able to start the run. I manage the puppet.conf file using puppet, so when the time comes to update that, puppet tries to make a backup into a server filebucket and fails with getaddrinfo: The storage control blocks were destroyed. I checked the effective config using puppet agent --genconfig, and didn't find a mention of a short hostname for the puppet master. The problem disappeared when I added a CNAME from puppet.sub.example.com - puppet.example.com. So it seems to me like puppet is still using the dns shortname somewhere even though the fqdn is configured in puppet.conf. -- 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 post to this group, send email to puppet-bugs@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Bug #17278] Double entry when using nagios_host
Issue #17278 has been updated by Jens Bräuer. This also happens to me with Puppet 3.0.2. Bug #17278: Double entry when using nagios_host https://projects.puppetlabs.com/issues/17278#change-81492 Author: Alexandre Angel Status: Investigating Priority: Normal Assignee: Category: nagios Target version: 3.x Affected Puppet version: 3.0.1 Keywords: nagios Branch: Hello, Since upgrade to puppet 3, i have a problem with nagios_host used in local. I have a class creating nagios_host type. At first run, it works fine, nagios config file is ok. On the second run, one of them is added a second time to the nagios confif file like puppet failed to see it's already present in the file. If i try to not add that nagios_host, another one i add is added a second time. The bugging nagios_host is always the first in file generated. I guess it miss the first element when checking for existing host. Here is log from puppet agent --debug --verbose --no-daemonize concerning nagios_host : 1st run : Debug: /Stage[main]//Node[webadmin.mydomain.com]/Nagios::Switch[sbx908.mydomain.com]/Nagios_host[sbx908.mydomain.com]/notify: subscribes to Service[nagios3] /Stage[main]//Node[webadmin.mydomain.com]/Nagios::Switch[sbx908.mydomain.com]/Nagios_host[sbx908.mydomain.com]/ensure: created Info: /Stage[main]//Node[webadmin.mydomain.com]/Nagios::Switch[sbx908.mydomain.com]/Nagios_host[sbx908.mydomain.com]: Scheduling refresh of Service[nagios3] Debug: /Stage[main]//Node[webadmin.mydomain.com]/Nagios::Switch[sbx908.mydomain.com]/Nagios_host[sbx908.mydomain.com]: The container Nagios::Switch[sbx908.mydomain.com] will propagate my refresh event Debug: Nagios::Switch[sbx908.mydomain.com]: The container Node[webadmin.mydomain.com] will propagate my refresh event 2nd run : Debug: /Stage[main]//Node[webadmin.mydomain.com]/Nagios::Switch[sbx908.mydomain.com]/Nagios_host[sbx908.mydomain.com]/notify: subscribes to Service[nagios3] /Stage[main]//Node[webadmin.mydomain.com]/Nagios::Switch[sbx908.mydomain.com]/Nagios_host[sbx908.mydomain.com]/ensure: created Info: /Stage[main]//Node[webadmin.mydomain.com]/Nagios::Switch[sbx908.mydomain.com]/Nagios_host[sbx908.mydomain.com]: Scheduling refresh of Service[nagios3] Debug: /Stage[main]//Node[webadmin.mydomain.com]/Nagios::Switch[sbx908.mydomain.com]/Nagios_host[sbx908.mydomain.com]: The container Nagios::Switch[sbx908.mydomain.com] will propagate my refresh event /Stage[main]/Nagios::Target/Nagios_host[webadmin.mydomain.com]/parents: parents changed ['sbx908.mydomain.com'] to 'sbx908.mydomain.com' Debug: Nagios::Switch[sbx908.mydomain.com]: The container Node[webadmin.mydomain.com] will propagate my refresh event -- 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 post to this group, send email to puppet-bugs@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Facter - Feature #7559] Fact for identifying Amazon VPC instances.
Issue #7559 has been updated by Martijn Heemels.
Jeff McCune wrote:
I'm curious why your instance isn't reporting physical = xen. Could you
let me know what Facter version you're running Brian?
Jeff, this sounds exactly like bug #14366 virtual = physical and is_virtual
= false on EC2 which has been open for 9 months. I'm seeing this behaviour on
all my EC2 and VPC instances. They all report as physical with the latest
facter available on Ubuntu 12.04 LTS (facter 1.6.5).
Feature #7559: Fact for identifying Amazon VPC instances.
https://projects.puppetlabs.com/issues/7559#change-81494
Author: Nigel Kersten
Status: Accepted
Priority: Normal
Assignee:
Category: library
Target version:
Keywords: vpc ec2 arp
Branch:
Affected Facter version: 1.6.10
(From the list)
I ran into a buglet in facter 1.5.9rc6 (from tmz repo). In normal AWS
instances it works great. In VPC instances if doesn't work. This seems
to be because VPC instances don't use the fe:ff:ff:... MAC addresses.
pre
/sbin/ifconfig
eth0 Link encap:Ethernet HWaddr 02:67:4E:E1:26:30
inet addr:172.17.129.24 ...
/sbin/arp
Address HWtype HWaddress Flags Mask Iface
169.254.169.253 ether 02:67:4E:C0:00:01 C eth0
172.17.128.1 ether 02:67:4E:C0:00:01 C eth0
/sbin/ifconfig
eth0 Link encap:Ethernet HWaddr 02:67:4E:DA:58:16
inet addr:172.17.128.126
/sbin/arp
Address HWtype HWaddress Flags Mask Iface
169.254.169.253 ether 02:67:4E:C0:00:01 C eth0
172.17.128.1 ether 02:67:4E:C0:00:01 C eth0
/pre
Of the two VPC EC2 instances I've seen, the MAC address always start
with 02:67:4E. I have only seen two instances, both in the same VPC, so
I don't know if this holds for every VPC instance, YMMV.
in ec2.rb , the following seemed to work:
pre
def has_euca_mac?
!!(Facter.value(:macaddress) =~ %r{^02:67:4[eE]:})
end
/pre
--
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 post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Bug #18762] (Unreviewed) behavior difference when ENC is providing list of classes versus array format
Issue #18762 has been reported by Niek Beernink. Bug #18762: behavior difference when ENC is providing list of classes versus array format https://projects.puppetlabs.com/issues/18762 Author: Niek Beernink Status: Unreviewed Priority: Normal Assignee: Category: Target version: Affected Puppet version: 3.0.2 Keywords: Branch: allowing parameterized classes in puppet provides a different output compared to disallowing parameterized classes. Using this module https://github.com/saz/puppet-ntp the statsdir variable is set to undef by default. With parameterized classes enabled using the module results in the puppet error: Error 400 on SERVER: Received incomplete information - no value provided for parameter statsdir on node $nodename The option, Parametrized_Classes_in_ENC, is controlled by foreman. Compare the two yaml outputs. With the option enabled, the following output is produced: pre --- parameters: owner_email: emailadress foreman_env: production puppet_ca: foreman.url domainname: root_pw: $hash owner_name: Firstname Lastname puppetmaster: puppetmaster.url hostgroup: production environment: production classes: ntp: statsdir: /pre With the option disabled, no error is generated in puppet. The following yaml output is generated. pre --- parameters: owner_email: emailaddress foreman_env: production puppet_ca: foreman.url domainname: root_pw: $hash owner_name: Firstname Lastname puppetmaster: puppetmaster.url hostgroup: production environment: production classes: - ntp /pre Version info: puppet-3.0.2-1.el6.noarch foreman-1.1RC4-1.el6.noarch Centos 6.2 -- 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 post to this group, send email to puppet-bugs@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Bug #18763] (Unreviewed) find_template function in source doesn't work as documented.
Issue #18763 has been reported by Rudy Gevaert. Bug #18763: find_template function in source doesn't work as documented. https://projects.puppetlabs.com/issues/18763 Author: Rudy Gevaert Status: Unreviewed Priority: Normal Assignee: Category: Target version: Affected Puppet version: Keywords: Branch: Hello, The documentation of the find_template function (puppet/parser/files.rb, lines 30-56 (puppet v2.7.18)) states that templates are searched in modules before the templatedir config variable. The implementation is the other way around. First the templatedir is searched and only if nothing is found the template is searched in modules. Rudy -- 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 post to this group, send email to puppet-bugs@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Feature #11331] Add 'foreach' structure in manifests
Issue #11331 has been updated by Henrik Lindberg.
This was much easier to implement that I first imagined. (Pull request coming
soon).
By introducing a parameterized block (a Puppet::Parser::AST::Lambda) and some
minor improvements to the ephemeral scope support I was able to quickly make
progress on this.
The syntax for calling a method is:
pre
lhs.funcname
lhs.funcname(optional arguments)
lhs.funcname {|...| ... }
lhs.funcname(optional arguments) {|...| ... }
/pre
This is equivalent to calling the same function with the lhs as the first
parameter, and the lambda (if present) as the last argument). (This means any
existing function can be called using this syntax - e.g:
pre$a = $b.split('[.:]')
/pre
Support for foreach is then simply implemented as a function.
The syntax for the LAMBDA is:
pre
{|parameter_list| statements }
{|parameter_list| = expression }
/pre
Although the later is not required for the foreach function, it is required to
be able to support lambdas that function as predicates e.g.
pre $b = $a.reject {|$x| = $x =~ /ugly/ }
/pre
The requirement to use a syntax marker (i.e. =) is a bit unfortunate, but it is
currently not possible to support statements | expression without this marker
unless a major refactoring is done of the grammar / evaluation as there are
ambiguities between function calls with and without parentheses. It is also not
possible to implement this as an eval function, since functions invokable as
statements are not allowed to produce an rvalue. (The use of = to turn an
expression into a statement is only allowed at the opening of a lambda, and
this may later be made optional (when/if grammar is refactored).
The parameter_list supports default values, but if used, they must be at the
end of the list as call is made by position and not by name.
The foreach function allows iterating array slices of 1 or more elements (i.e.
pairs, triplets, etc). and a hash can be iterated over keys or keys and values.
e.g:
pre
$a = [1, present, 2, absent]
$a.foreach { |$x, $y| file ( /file_$x: ensure = $y}
$a = {'1' = present, '2' = absent}
$a.foreach { |$x, $y| file ( /file_$x: ensure = $y}
/pre
To produce /file_1 with ensure present, and /file_2 with ensure absent.
Other examples of iterating over hashes.
pre
# iterate over keys
$a = {'1' = present, '2' = absent}
$a.foreach { |$x| file ( /file_$x: ensure = present}
# access variable outside of lambda
$a = {'1' = present, '2' = absent}
$a.foreach { |$x| file ( /file_$x: ensure = $a[$x]}
/pre
It is not allowed to use class, define, nor node-statements in the lambda, and
variables that are assigned in the lambda are local and can not be referenced
outside of the scope of the lambda (but they are visible to any nested inner
lambdas). Lambda parameters shadow parameters with the same name in outer
scopes.
Since the implementation makes it possible to easily add custom methods (i.e.
done just like any other custom function), the implementation of lambda
evaluation is also very simple. If passed a lambda it is evaluated by:
pre
a_lambda.call(scope, *arguments)
/pre
A lambda has two additional useful methods `#parameter_count` and
´#optional_parameter_count`.
Feature #11331: Add 'foreach' structure in manifests
https://projects.puppetlabs.com/issues/11331#change-81504
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:
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
[Puppet - Feature #18764] (Unreviewed) Add support for enumerable methods/functions
Issue #18764 has been reported by Henrik Lindberg.
Feature #18764: Add support for enumerable methods/functions
https://projects.puppetlabs.com/issues/18764
Author: Henrik Lindberg
Status: Unreviewed
Priority: Normal
Assignee:
Category: functions
Target version:
Affected Puppet version:
Keywords:
Branch:
With the addition of lambdas/methods in #11331 it is very simple to also add
support for additional operations on collections (arrays and hashes).
As an example, this would select all strings in the array $a that ends in
.com:
$dot_com_strings = $a.select {|$x| = $x =~ /\.com$/ }
Propose that the following are added:
* collect
* select
* reject
* reduce
* count / length / size
* all
* any - this is a variant on the explicit in operator
--
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 post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Feature #18764] Add support for enumerable methods/functions
Issue #18764 has been updated by Henrik Lindberg.
Keywords set to collections functions language
Feature #18764: Add support for enumerable methods/functions
https://projects.puppetlabs.com/issues/18764#change-81505
Author: Henrik Lindberg
Status: Unreviewed
Priority: Normal
Assignee:
Category: functions
Target version:
Affected Puppet version:
Keywords: collections functions language
Branch:
With the addition of lambdas/methods in #11331 it is very simple to also add
support for additional operations on collections (arrays and hashes).
As an example, this would select all strings in the array $a that ends in
.com:
$dot_com_strings = $a.select {|$x| = $x =~ /\.com$/ }
Propose that the following are added:
* collect
* select
* reject
* reduce
* count / length / size
* all
* any - this is a variant on the explicit in operator
--
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 post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Feature #18764] Add support for enumerable methods/functions
Issue #18764 has been updated by Henrik Lindberg.
Description updated
Feature #18764: Add support for enumerable methods/functions
https://projects.puppetlabs.com/issues/18764#change-81506
Author: Henrik Lindberg
Status: Unreviewed
Priority: Normal
Assignee:
Category: functions
Target version:
Affected Puppet version:
Keywords: collections functions language
Branch:
With the addition of lambdas/methods in #11331 it is very simple to also add
support for additional operations on collections (arrays and hashes).
As an example, this would select all strings in the array $a that ends in
.com:
pre
$dot_com_strings = $a.select {|$x| = $x =~ /\.com$/ }
/pre
Propose that the following are added:
* collect
* select
* reject
* reduce
* count / length / size
* all
* any - this is a variant on the explicit in operator
--
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 post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-bugs?hl=en.
[Facter - Feature #7559] Fact for identifying Amazon VPC instances.
Issue #7559 has been updated by Jeff McCune.
Thanks Martijn,
I'll have a look at both this ticket and the related one on Tuesday. Sorry
this has been affecting you.
-Jeff
Feature #7559: Fact for identifying Amazon VPC instances.
https://projects.puppetlabs.com/issues/7559#change-81508
Author: Nigel Kersten
Status: Accepted
Priority: Normal
Assignee:
Category: library
Target version:
Keywords: vpc ec2 arp
Branch:
Affected Facter version: 1.6.10
(From the list)
I ran into a buglet in facter 1.5.9rc6 (from tmz repo). In normal AWS
instances it works great. In VPC instances if doesn't work. This seems
to be because VPC instances don't use the fe:ff:ff:... MAC addresses.
pre
/sbin/ifconfig
eth0 Link encap:Ethernet HWaddr 02:67:4E:E1:26:30
inet addr:172.17.129.24 ...
/sbin/arp
Address HWtype HWaddress Flags Mask Iface
169.254.169.253 ether 02:67:4E:C0:00:01 C eth0
172.17.128.1 ether 02:67:4E:C0:00:01 C eth0
/sbin/ifconfig
eth0 Link encap:Ethernet HWaddr 02:67:4E:DA:58:16
inet addr:172.17.128.126
/sbin/arp
Address HWtype HWaddress Flags Mask Iface
169.254.169.253 ether 02:67:4E:C0:00:01 C eth0
172.17.128.1 ether 02:67:4E:C0:00:01 C eth0
/pre
Of the two VPC EC2 instances I've seen, the MAC address always start
with 02:67:4E. I have only seen two instances, both in the same VPC, so
I don't know if this holds for every VPC instance, YMMV.
in ec2.rb , the following seemed to work:
pre
def has_euca_mac?
!!(Facter.value(:macaddress) =~ %r{^02:67:4[eE]:})
end
/pre
--
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 post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet] 'Generating a config file from fragments' wiki page has been updated
The 'Generating a config file from fragments' wiki page has been updated by Reid Vandewiele. Generating a config file from fragments: https://projects.puppetlabs.com/projects/puppet/wiki/Generating_a_config_file_from_fragments View differences: https://projects.puppetlabs.com/projects/puppet/wiki/Generating_a_config_file_from_fragments/diff/4 -- 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 post to this group, send email to puppet-bugs@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Feature #18769] (Unreviewed) Solaris 10 packages not versionable?
Issue #18769 has been reported by Brandon Wilson. Feature #18769: Solaris 10 packages not versionable? https://projects.puppetlabs.com/issues/18769 Author: Brandon Wilson Status: Unreviewed Priority: Normal Assignee: Category: Target version: Affected Puppet version: Keywords: solaris package versionable Branch: Created a module to ensure that openssh is up to date on all of our hosts. When executing `puppet agent -t` on the test host, it returns with: err: Failed to apply catalog: Parameter ensure failed: Provider must have features 'versionable' to set 'ensure' to '6.1p1' Are Solaris packages not versionable? Seems like a big oversight if so. -- 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 post to this group, send email to puppet-bugs@googlegroups.com. To unsubscribe from this group, send email to puppet-bugs+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Feature #11331] Add 'foreach' structure in manifests
Issue #11331 has been updated by Henrik Lindberg.
Also see #18764 for additional methods making use of lambda.
Feature #11331: Add 'foreach' structure in manifests
https://projects.puppetlabs.com/issues/11331#change-81511
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:
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 post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Feature #11331] Add 'foreach' structure in manifests
Issue #11331 has been updated by Henrik Lindberg.
Branch set to https://github.com/puppetlabs/puppet/pull/1420
The implementation is now ready for review.
There are some fixes required for Ruby 1.8.7, but what is in PL 1420 works on
1.9.3
The additional methods discussed in #18764 are currently available in
https://github.com/hlindberg/puppet/tree/18764-enumerable-methods.
Feature #11331: Add 'foreach' structure in manifests
https://projects.puppetlabs.com/issues/11331#change-81512
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 post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Feature #11331] Add 'foreach' structure in manifests
Issue #11331 has been updated by Steve Shipway.
Many thanks for your work on this feature, which will help us no end -- once we
fix our current modules to be v3.x compatible and we upgrade to v3 on our
puppet server, of course. The new syntax looks convenient and understandable,
and more Ruby-ish (I'm from a Perl background so my initial example was
perl-ish)
Feature #11331: Add 'foreach' structure in manifests
https://projects.puppetlabs.com/issues/11331#change-81513
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 post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Bug #18755] Puppet apply completely broken in 3.1rc1
Issue #18755 has been updated by Josh Cooper.
Thanks Ashley. It appears puppet on your system is loading an older version of
`lib/puppet/type/group.rb` that doesn't contain the `exists?` method, which was
added in commit 006c5def for #9862. Can try the following?
pre
# irb
# require 'puppet'
# puts Puppet::Type.type(:group).new(:name = :service).exists?
/pre
Another possibility is that the group provider on your system doesn't implement
the exists? method. Can you try the same as above, but this time call the
method on the provider directly?
pre
# puts Puppet::Type.type(:group).new(:name = :service).provider.exists?
/pre
Do you have another version of puppet installed as a gem? If the 3.0.2 version
is still installed, can you try removing it?
Do you have a pluginsync'ed module in `/var/lib/puppet/lib` that includes the
group type? To be sure can you `rm -rf /var/lib/puppet/lib` and then run
`puppet apply -e notice('') --modulepath /dev/null`
Bug #18755: Puppet apply completely broken in 3.1rc1
https://projects.puppetlabs.com/issues/18755#change-81514
Author: Ashley Penney
Status: Needs More Information
Priority: High
Assignee: Ashley Penney
Category:
Target version:
Affected Puppet version: 3.1.0-rc1
Keywords:
Branch:
I recently installed 3.1 (via a gem) to fix the rspec testing issues but
discovered a new problem:
pre
[root@arch manifests]# puppet apply test.pp
Could not retrieve macaddress: undefined method `each_line' for nil:NilClass
Could not retrieve macaddress: undefined method `each_line' for nil:NilClass
Could not retrieve macaddress: undefined method `each_line' for nil:NilClass
Could not retrieve ipaddress6: undefined method `scan' for nil:NilClass
Error: Could not create resources for managing Puppet's files and directories
in sections [:main, :ssl, :agent]: undefined method `exists?' for
Group[puppet]:Puppet::Type::Group
Error: Could not create resources for managing Puppet's files and directories
in sections [:main, :ssl, :agent]: undefined method `exists?' for
Group[puppet]:Puppet::Type::Group
undefined method `exists?' for Group[puppet]:Puppet::Type::Group
/pre
As soon as I revert to 3.0.2 this works again.
test.pp is just a quick call to a single define:
pre
json::add_file { 'env.json': }
/pre
My puppet.conf:
pre
[main]
logdir=/var/log/puppet
vardir=/var/lib/puppet
ssldir=/var/lib/puppet/ssl
rundir=/var/run/puppet
factpath=$vardir/lib/facter
templatedir=$confdir/templates
environment = production
pluginsync = true
modulepath=/home/apenney/git/configuration/modules
[master]
modulepath=/home/apenney/git/configuration/modules
[agent]
modulepath=/home/apenney/git/configuration/modules
/pre
/etc/group entry:
pre
puppet:x:1000:
/pre
/etc/passwd:
pre
puppet:x:1001:1000::/var/lib/puppet:/bin/false
/pre
This is using ruby 1.9.3p374 on arch linux. I set the priority as high only
because this seems a fairly large change in behavior that might have slipped
through the cracks and will upset users! :) If there's any other info I can
get for you just let me know.
--
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 post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-bugs?hl=en.
[Puppet - Bug #18677] Resource chain operators conflict uncleanly with inline metaparameter specification
Issue #18677 has been updated by Peter Meier.
This is quite a nasty one and happening a lot if you want to use the arrow
operators. I thought this have already been reported in another bug report. It
looks like the relevant part is in: #7422 - Could you please verify that (has
it been fixed?) and also report the affected version? Thanks!
Another candidate is: #15117
Bug #18677: Resource chain operators conflict uncleanly with inline
metaparameter specification
https://projects.puppetlabs.com/issues/18677#change-81520
Author: Reid Vandewiele
Status: Unreviewed
Priority: Normal
Assignee:
Category: language
Target version:
Affected Puppet version:
Keywords:
Branch:
Consider the following Puppet code as example1.pp:
notify { 'serenity': }
notify { 'firefly': }
notify { 'alliance':
notify = Notify['serenity']
}
Notify['alliance'] ~ Notify['firefly']
Running `puppet apply example1.pp` produces the following output:
undefined method `' for {}:Hash on node pseudonix.local
Similarly, example2.pp:
notify { 'serenity': }
notify { 'firefly': }
notify { 'alliance':
before = Notify['serenity']
}
Notify['alliance'] - Notify['firefly']
The same output is produced:
undefined method `' for {}:Hash on node pseudonix.local
This is buggy behavior. Ideally when there is a conflict the behavior should be
additive. At the end of day in example1.pp there should exist notify
relationships such that 'alliance' notifies 'serenity' AND 'alliance' notifies
'firefly'.
--
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 post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-bugs?hl=en.
