[Puppet - Bug #18427] gem package provider updates gems even if the gem is already at the latest revision
Issue #18427 has been updated by Luke M.
Assignee set to Charlie Sharpsteen
Keywords set to gems provider
We do not have any custom written gems; all our gems originate from
rubygems.org. Our process is as follows:
o Retrieve gems from rubygems.org to gem repo:
gem fetch pupppet
o Tell repo about new gems
gem generate_index -d /path/to/gems
That is it. Hopefully that clears up any ambiguity.
More info here: http://docs.rubygems.org/read/chapter/18
Bug #18427: gem package provider updates gems even if the gem is already at the
latest revision
https://projects.puppetlabs.com/issues/18427#change-89208
* Author: Luke M
* Status: Needs More Information
* Priority: Normal
* Assignee: Charlie Sharpsteen
* Category: package
* Target version:
* Affected Puppet version: 2.7.20
* Keywords: gems provider
* Branch:
Using:
package{'facter':
ensure = latest,
provider= 'gem',
source = http://puppet:8808;,
}
Produces:
notice: /Stage[main]/Common_puppet::Hpux/Package[facter]/ensure: ensure
changed '1.6.17' to '1.6.17 ruby'
This happens on every puppet run.
--
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.
[Puppet - Bug #20221] (Unreviewed) Cannot install the latest release of a specific package version
Issue #20221 has been reported by Raul Macian.
Bug #20221: Cannot install the latest release of a specific package version
https://projects.puppetlabs.com/issues/20221
* Author: Raul Macian
* Status: Unreviewed
* Priority: Normal
* Assignee:
* Category:
* Target version:
* Affected Puppet version: 3.1.0
* Keywords:
* Branch:
With package ensure cannot select to install the latest release of a given
version.
For example, a package with version 1.0.0 and 1.0.1 on the same repo:
package { package: ensure = latest }
Install the latest release of any of both packages, installs the newer release
alternating 1.0.0 and 1.0.1
package { package-1.0.0: ensure = latest }
Does not update the package when a new release is present
package { package: ensure = 1.0.0 }
Tries to identify the version of a package including the release. This
tipically throws an error like
Error: Could not update: Failed to update to version 1.0.0, got version
1.0.0-1960.a02d20b instead
--
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.
[Puppet - Bug #20223] (Unreviewed) puppet doc fails under windows
Issue #20223 has been reported by Frederic Schaer. Bug #20223: puppet doc fails under windows https://projects.puppetlabs.com/issues/20223 * Author: Frederic Schaer * Status: Unreviewed * Priority: Normal * Assignee: * Category: documentation * Target version: * Affected Puppet version: 3.1.1 * Keywords: puppet rdoc * Branch: Hi, puppet 3.1.1 seems unable to generate documentation on windows, either under cygwin or in a plain DOS cmd. It fails with the attached error (I don't know how to paste code in here). It seems it is trying to create the files/C: dir, and all other directories using the C: part of the path. I'm not sure this is a puppet or a ruby issue, but since ruby is shipped with puppet under windows... I tried to see if I could work around that with string substitution (replace the '/' with '\', and the ':' with '_', but since I'm a ruby newbie, I've been unable for now to find out what generates the file listes used everywhere in the code. Regards -- 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.
[Puppet - Feature #11437] Add Shinken extra atrributes to Nagios types
Issue #11437 has been updated by Jason Antman. There are a few other Nagios forks as well, Icinga being (AFAIK) the most common at the moment. I see that this is already in a topic branch (but stalled for a year?) but Icinga also adds some new attributes, as well as changing some of the required attributes. Maybe there's a more generic way to implement this? The Icinga added attributes are: host: address6 failure_prediction_enabled service: failure_prediction_enabled serviceescalation: escalation_condition first_warning_notification last_warning_notification first_critical_notification last_critical_notification first_unknown_notification last_unknown_notification hostescalation: first_down_notification last_down_notification first_unreachable_notification last_unreachable_notification hostextinfo: hostgroup_name serviceextinfo: hostgroup_name Docs on the latest can be found at: http://docs.icinga.org/latest/en/objectdefinitions.html Feature #11437: Add Shinken extra atrributes to Nagios types https://projects.puppetlabs.com/issues/11437#change-89210 * Author: Bruno LEON * Status: In Topic Branch Pending Review * Priority: Normal * Assignee: * Category: nagios * Target version: * Affected Puppet version: * Keywords: nagios shinken * Branch: https://github.com/puppetlabs/puppet/pull/273 Shinken is a new player in the monitoring solutions, written in python it is a very promising software. Is is compatible with Nagios config, and thus quite easily configurable via Puppet. It also has some specific attributes that are not present in Puppet's Nagios native types. I did a pull request which adds them: [https://github.com/puppetlabs/puppet/pull/273](https://github.com/puppetlabs/puppet/pull/273) -- 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.
[Puppet - Bug #20121] (Investigating) SLES service acts different than RedHat
Issue #20121 has been updated by Charlie Sharpsteen.
Status changed from Unreviewed to Investigating
Assignee set to Charlie Sharpsteen
Bug #20121: SLES service acts different than RedHat
https://projects.puppetlabs.com/issues/20121#change-89220
* Author: Charles Dunbar
* Status: Investigating
* Priority: Normal
* Assignee: Charlie Sharpsteen
* Category:
* Target version:
* Affected Puppet version:
* Keywords: sles redhat service customer
* Branch:
On Puppet 2.7.19, when trying to manage a non-existant service in
RedHat/CentOS, puppet compiles without issue. When you use the exact same
manifest for SLES (currently testing x64 SLES 11.1), you get an error that the
service doesn't exist.
Manifest:
pre
service { 'foo':
ensure = 'false',
enable = false,
}
/pre
On CentOS 6.3, with --debug:
pre
debug: Service[foo](provider=redhat): Executing '/sbin/service foo status'
debug: Puppet::Type::Service::ProviderRedhat: Executing '/sbin/chkconfig foo'
notice: Finished catalog run in 5.04 seconds
/pre
On SLES 11.1:
pre
debug: Service[foo](provider=redhat): Executing '/sbin/service foo status'
debug: Puppet::Type::Service::ProviderRedhat: Executing '/sbin/chkconfig foo'
debug: Puppet::Type::Service::ProviderRedhat: Executing '/sbin/chkconfig foo
off'
err: /Stage[main]/Cron/Service[foo]/enable: change from true to false failed:
Could not disable foo:
notice: Finished catalog run in 1.80 seconds
/pre
Looks like trying to call the service off is the failure. Ideally would prefer
a non-existing service to be assumed to be off, as the centos machine simulates.
--
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.
[Puppet - Bug #20221] (Needs More Information) Cannot install the latest release of a specific package version
Issue #20221 has been updated by Charlie Sharpsteen.
Status changed from Unreviewed to Needs More Information
Assignee set to Raul Macian
Hi Raul,
Which operating system and package provider (apt, yum, etc.) are you getting
this behavior from?
Bug #20221: Cannot install the latest release of a specific package version
https://projects.puppetlabs.com/issues/20221#change-89217
* Author: Raul Macian
* Status: Needs More Information
* Priority: Normal
* Assignee: Raul Macian
* Category:
* Target version:
* Affected Puppet version: 3.1.0
* Keywords:
* Branch:
With package ensure cannot select to install the latest release of a given
version.
For example, a package with version 1.0.0 and 1.0.1 on the same repo:
package { package: ensure = latest }
Install the latest release of any of both packages, installs the newer release
alternating 1.0.0 and 1.0.1
package { package-1.0.0: ensure = latest }
Does not update the package when a new release is present
package { package: ensure = 1.0.0 }
Tries to identify the version of a package including the release. This
tipically throws an error like
Error: Could not update: Failed to update to version 1.0.0, got version
1.0.0-1960.a02d20b instead
--
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.
[Puppet - Bug #20221] Cannot install the latest release of a specific package version
Issue #20221 has been updated by Raul Macian.
I'm using RHEL and CentOs the yum provider. Looking the code at
https://github.com/puppetlabs/puppet/blob/master/lib/puppet/provider/package/yum.rb
I see that latest option queries for version+release and a comment
# FIXME: there could be more than one update for a package which could be my
case where I have several packages with the same version but different releases.
Bug #20221: Cannot install the latest release of a specific package version
https://projects.puppetlabs.com/issues/20221#change-89224
* Author: Raul Macian
* Status: Needs More Information
* Priority: Normal
* Assignee: Raul Macian
* Category:
* Target version:
* Affected Puppet version: 3.1.0
* Keywords:
* Branch:
With package ensure cannot select to install the latest release of a given
version.
For example, a package with version 1.0.0 and 1.0.1 on the same repo:
package { package: ensure = latest }
Install the latest release of any of both packages, installs the newer release
alternating 1.0.0 and 1.0.1
package { package-1.0.0: ensure = latest }
Does not update the package when a new release is present
package { package: ensure = 1.0.0 }
Tries to identify the version of a package including the release. This
tipically throws an error like
Error: Could not update: Failed to update to version 1.0.0, got version
1.0.0-1960.a02d20b instead
--
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.
[Naginator - Feature #4240] nagios_hostgroups should be removed
Issue #4240 has been updated by Jason Antman. I say close this. The Nagios docs (http://nagios.sourceforge.net/docs/nagioscore/3/en/objectdefinitions.html#hostgroup) specify that the hostgroup type has 5 attributes other than name and list of members: * alias * hostgroup_members (other hostgroups that are members) * notes (note_string) * notes_url * action_url If the type is removed, it will be impossible to set these other attributes. What Brian seems to want is the sort of automatic requires logic that's present in files and their owning user/group, where if a hostgroup is specified in a nagios_host resource, it will be automatically created if it doesn't exist. I'm pretty sure that would require much deeper understanding of the relationships between resources than naginator currently has, but either way, it would *not* call for the removal of nagios_hostgroup. Feature #4240: nagios_hostgroups should be removed https://projects.puppetlabs.com/issues/4240#change-89225 * Author: Brian Gallew * Status: Needs More Information * Priority: Normal * Assignee: * Category: * Target version: * Keywords: * Branch: The nagios_hostgroups type is redundant. Hostgroups are declared as elements of nagios_hosts. It should be easy enough to generate the hostgroups by scanning through the hosts and collecting all the unique entries. -- 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.
[Puppet - Feature #20149] Allow custom macro definitions in Nagios types
Issue #20149 has been updated by Jason Antman.
Maybe this logic could also be used in Feature #11437 - some sort of general
hash logic to add arbitrary lines to the nagios_* types?
Feature #20149: Allow custom macro definitions in Nagios types
https://projects.puppetlabs.com/issues/20149#change-89227
* Author: Patricia Jung
* Status: Unreviewed
* Priority: Normal
* Assignee:
* Category: nagios
* Target version:
* Affected Puppet version:
* Keywords:
* Branch:
According to the puppet type definition docs until 3.1 puppet Nagios types do
not seem to be able to handle custom macros in Nagios object definitions like
__WARN in the following example:
define service{
usetemplate
host_name host
__WARN 1
}
Please add a parameter which allows to specify custom macro/value pairs. Thank
you!
--
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.
[Puppet - Bug #7463] (Duplicate) yum package provider doesn't piece together package name with arch correctly.
Issue #7463 has been updated by Charlie Sharpsteen.
Status changed from Accepted to Duplicate
Assignee changed from Daniel Pittman to Charlie Sharpsteen
Closing as a duplicate of #2662.
Bug #7463: yum package provider doesn't piece together package name with arch
correctly.
https://projects.puppetlabs.com/issues/7463#change-89229
* Author: Ben Hughes
* Status: Duplicate
* Priority: Normal
* Assignee: Charlie Sharpsteen
* Category: package
* Target version:
* Affected Puppet version:
* Keywords: customer
* Branch:
# Overview #
If you try and specify the architecture for a package with the yum provider it
either can't find the package initially or can't find it on subsequent runs.
# Expected Behaviour #
You should be able to specify the arch in the version or package name, and yum
installs only that version once it reassembles all the information for the
package.
# Actual Behaviour #
If you specify the package/arch like:
pre
package{ 'njn-plugins-client':
name= njn-plugins-client.${architecture},
ensure = 1.4-26,
}
/pre
Yum queries for njn-plugins-client.${architecture}-1.4-26 which is the wrong
format, so will never find the package to install it.
If however you specify it via:
pre
package{ 'njn-plugins-client':
name= njn-plugins-client,
ensure = 1.4-26.${architecture},
}
/pre
It will get installed, but puppet is unaware that the .${arch} is on the
version number, so can no longer find that version installed.
--
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.
[Facter] 'Wiki' wiki page has been updated
The 'Wiki' wiki page has been updated by Matthaus Owens. Wiki: https://projects.puppetlabs.com/projects/facter/wiki/Wiki View differences: https://projects.puppetlabs.com/projects/facter/wiki/Wiki/65/diff -- 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.
[Puppet] 'Downloading Puppet' wiki page has been updated
The 'Downloading Puppet' wiki page has been updated by Matthaus Owens. Downloading Puppet: https://projects.puppetlabs.com/projects/puppet/wiki/Downloading_Puppet View differences: https://projects.puppetlabs.com/projects/puppet/wiki/Downloading_Puppet/247/diff -- 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.
[Facter - Bug #20229] (Unreviewed) facter 1.7.0 network facts not working
Issue #20229 has been reported by Niels Abspoel. Bug #20229: facter 1.7.0 network facts not working https://projects.puppetlabs.com/issues/20229 * Author: Niels Abspoel * Status: Unreviewed * Priority: Normal * Assignee: * Category: * Target version: 1.7.0 * Keywords: archlinux netmask * Branch: * Affected Facter version: 1.7.0 netmask fact doesn't work on archlinux with facter 1.7.0 sudo facter -p --debug value for ipaddress6_enp5s0 is still nil value for netmask_enp5s0 is still nil value for mtu_enp5s0 is still nil value for ipaddress_enp6s0 is still nil value for ipaddress6_enp6s0 is still nil value for netmask_enp6s0 is still nil value for mtu_enp6s0 is still nil value for ipaddress6_lo is still nil value for macaddress_lo is still nil value for netmask_lo is still nil value for mtu_lo is still nil value for ipaddress6 is still nil but if I do an ifconfig: ifconfig enp5s0: flags=4163UP,BROADCAST,RUNNING,MULTICAST mtu 1500 inet XXX.XXX.XXX.XXX netmask 255.255.255.0 broadcast XXX.XXX.XXX.XXX inet6 ::::: prefixlen 64 scopeid 0x20link ether XX:XX:XX:XX:XX:XX txqueuelen 1000 (Ethernet) RX packets 184710 bytes 210205733 (200.4 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 105984 bytes 20553531 (19.6 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 lo: flags=73UP,LOOPBACK,RUNNING mtu 65536 inet 127.0.0.1 netmask 255.0.0.0 inet6 ::1 prefixlen 128 scopeid 0x10host loop txqueuelen 0 (Local Loopback) RX packets 61 bytes 8660 (8.4 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 61 bytes 8660 (8.4 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 in util/netmask.rb and util/ip.rb some regex needs to be adjusted. -- 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.
[Puppet - Bug #18427] (Investigating) gem package provider updates gems even if the gem is already at the latest revision
Issue #18427 has been updated by Charlie Sharpsteen.
Status changed from Needs More Information to Investigating
Keywords changed from gems provider to gem server
Thanks a bunch for the clarification Luke. It looks like the gem server is
indeed deciding to append the string ruby to the version numbers it is
reporting. I was unable to re-produce this behavior with a quick test, I'll try
to dig deeper.
A couple more questions:
- Which operating system is hosting the gem server?
- What version of Ruby is the gem server using? Is there any ruby version
manager such as RVM or RBenv in use or was ruby installed through the system
package manager?
- Is the gem server from rubygems 1.4.0 or another version?
Bug #18427: gem package provider updates gems even if the gem is already at the
latest revision
https://projects.puppetlabs.com/issues/18427#change-89232
* Author: Luke M
* Status: Investigating
* Priority: Normal
* Assignee: Charlie Sharpsteen
* Category: package
* Target version:
* Affected Puppet version: 2.7.20
* Keywords: gem server
* Branch:
Using:
package{'facter':
ensure = latest,
provider= 'gem',
source = http://puppet:8808;,
}
Produces:
notice: /Stage[main]/Common_puppet::Hpux/Package[facter]/ensure: ensure
changed '1.6.17' to '1.6.17 ruby'
This happens on every puppet run.
--
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.
[Puppet - Bug #20223] puppet doc fails under windows
Issue #20223 has been updated by Frederic Schaer.
Seems I found a work around : in the shipped ruby, change the following file :
sys/ruby/lib/ruby/1.8/rdoc/generators/html_generator.rb
Change line 1291 from :
op_file = item.path
to
op_file = item.path.gsub(':','')
Et voilà, doc seems generated in windows.
This still looks like a bug in the shipped ruby, so it's still relevant I guess.
Regards
Bug #20223: puppet doc fails under windows
https://projects.puppetlabs.com/issues/20223#change-89233
* Author: Frederic Schaer
* Status: Unreviewed
* Priority: Normal
* Assignee:
* Category: documentation
* Target version:
* Affected Puppet version: 3.1.1
* Keywords: puppet rdoc
* Branch:
Hi,
puppet 3.1.1 seems unable to generate documentation on windows, either under
cygwin or in a plain DOS cmd.
It fails with the attached error (I don't know how to paste code in here).
It seems it is trying to create the files/C: dir, and all other directories
using the C: part of the path.
I'm not sure this is a puppet or a ruby issue, but since ruby is shipped with
puppet under windows...
I tried to see if I could work around that with string substitution (replace
the '/' with '\', and the ':' with '_', but since I'm a ruby newbie, I've been
unable for now to find out what generates the file listes used everywhere in
the code.
Regards
--
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.
[Facter - Bug #20236] (Accepted) Facter does not consult dmidecode if lspci is present
Issue #20236 has been reported by Jeff McCune. Bug #20236: Facter does not consult dmidecode if lspci is present https://projects.puppetlabs.com/issues/20236 * Author: Jeff McCune * Status: Accepted * Priority: Normal * Assignee: * Category: virtual * Target version: 1.7.x * Keywords: * Branch: * Affected Facter version: 1.6.18 ### Overview When Facter executes lspci and is unable to determine the virtual platform from the output, dmidecode is never consulted. This is a problem because there are situations where the information sufficient to determine the virtual platform is contained in the output of dmidecode, but not the output of lspci. ### Expected Behavior `dmidecode` is consulted when trying to determine the virtual platform, regardless of if lspci is present or not. ### Actual Behavior When `lspci` is present, `dmidecode` is never executed. Steps to reproduce: Stub out `lspci` such that it returns unrelated information and stub out `dmidecode` such that it returns relevant and useful information. Observe that `dmidecode` is never consulted. -- 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.
[Facter - Bug #20236] Facter does not consult dmidecode if lspci is present
Issue #20236 has been updated by Jeff McCune. Branch set to https://github.com/jeffmccune/facter/tree/fix/1.7.x/20236_lspci_vs_dmidecode Bug #20236: Facter does not consult dmidecode if lspci is present https://projects.puppetlabs.com/issues/20236#change-89234 * Author: Jeff McCune * Status: Accepted * Priority: Normal * Assignee: * Category: virtual * Target version: 1.7.x * Keywords: * Branch: https://github.com/jeffmccune/facter/tree/fix/1.7.x/20236_lspci_vs_dmidecode * Affected Facter version: 1.6.18 ### Overview When Facter executes lspci and is unable to determine the virtual platform from the output, dmidecode is never consulted. This is a problem because there are situations where the information sufficient to determine the virtual platform is contained in the output of dmidecode, but not the output of lspci. ### Expected Behavior `dmidecode` is consulted when trying to determine the virtual platform, regardless of if lspci is present or not. ### Actual Behavior When `lspci` is present, `dmidecode` is never executed. Steps to reproduce: Stub out `lspci` such that it returns unrelated information and stub out `dmidecode` such that it returns relevant and useful information. Observe that `dmidecode` is never consulted. -- 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.
[Puppet - Bug #18427] (Needs More Information) gem package provider updates gems even if the gem is already at the latest revision
Issue #18427 has been updated by Luke M.
Status changed from Investigating to Needs More Information
Q: Which operating system is hosting the gem server?
A: CentOS 6.3
Q: What version of Ruby is the gem server using?
A: ruby 1.8.7 (2011-06-30 patchlevel 352) [x86_64-linux]
Q: Is there any ruby version manager such as RVM or RBenv in use or was ruby
installed through the system package manager?
A: Using Yum/RPM
Q: Is the gem server from rubygems 1.4.0 or another version?
A: # rpm -qi rubygems-1.3.7-1.el6.noarch
..
URL : http://rubyforge.org/projects/rubygems/
Bug #18427: gem package provider updates gems even if the gem is already at the
latest revision
https://projects.puppetlabs.com/issues/18427#change-89246
* Author: Luke M
* Status: Needs More Information
* Priority: Normal
* Assignee: Charlie Sharpsteen
* Category: package
* Target version:
* Affected Puppet version: 2.7.20
* Keywords: gem server
* Branch:
Using:
package{'facter':
ensure = latest,
provider= 'gem',
source = http://puppet:8808;,
}
Produces:
notice: /Stage[main]/Common_puppet::Hpux/Package[facter]/ensure: ensure
changed '1.6.17' to '1.6.17 ruby'
This happens on every puppet run.
--
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.
[Facter - Bug #20236] (In Topic Branch Pending Review) Facter does not consult dmidecode if lspci is present
Issue #20236 has been updated by Jeff McCune. Status changed from Accepted to In Topic Branch Pending Review Target version changed from 1.7.x to 1.7.1 Branch changed from https://github.com/jeffmccune/facter/tree/fix/1.7.x/20236_lspci_vs_dmidecode to https://github.com/puppetlabs/facter/pull/429 Eric, I think this should be targeted at 1.7.1 since this is a bug fix that affected the 1.6 series and we just released 1.7.0. It's totally cool if we re-assign it to something else, just let me know. The impact data is that an user emailed Daniel and Kenn about this. Daniel pinged me about it this afternoon. -Jeff Bug #20236: Facter does not consult dmidecode if lspci is present https://projects.puppetlabs.com/issues/20236#change-89247 * Author: Jeff McCune * Status: In Topic Branch Pending Review * Priority: Normal * Assignee: * Category: virtual * Target version: 1.7.1 * Keywords: * Branch: https://github.com/puppetlabs/facter/pull/429 * Affected Facter version: 1.6.18 ### Overview When Facter executes lspci and is unable to determine the virtual platform from the output, dmidecode is never consulted. This is a problem because there are situations where the information sufficient to determine the virtual platform is contained in the output of dmidecode, but not the output of lspci. ### Expected Behavior `dmidecode` is consulted when trying to determine the virtual platform, regardless of if lspci is present or not. ### Actual Behavior When `lspci` is present, `dmidecode` is never executed. Steps to reproduce: Stub out `lspci` such that it returns unrelated information and stub out `dmidecode` such that it returns relevant and useful information. Observe that `dmidecode` is never consulted. -- 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.
[Puppet - Bug #17871] Nagios types creating duplicate entries
Issue #17871 has been updated by Simon Sellar.
Same issue here using puppet 3.1.1, ruby 1.9.3-p392
After some investigation I have found the following:
1) First run through, everything works properly.br/
2) Second run through, only the first resource found in the file resulting
config file (created on the first run) is repeated again.br/
3) Subsequent runs leave the configuration file as it is.br/
I enabled some debugging output in
puppet-3.1.1/lib/puppet/external/nagios/parser.rb to see what tokens are picked
up, and can confirm that each resource (contact in my case) are parsed
correctly (i.e 2 resources are parsed in on the second run through).
From the looks of it, when comparing the manifest against the parsed config,
it is skipping the comparison with the first item in the list from the parsed
config.
i.e.
pre
Manifest Parsed Config
A---.A---(parsed in, but missed in comparison with Manifest,
then written out anyway on second run)
B`--B
`---A---(created on second run)
/pre
I'm (very) new to the puppet code, so am having trouble finding the place where
the comparison is taking place to see if I can fix it. Happy to have a look if
someone can point me in the right direction.
Bug #17871: Nagios types creating duplicate entries
https://projects.puppetlabs.com/issues/17871#change-89248
* Author: Chris Mague
* Status: Investigating
* Priority: Normal
* Assignee:
* Category: nagios
* Target version:
* Affected Puppet version: 3.0.1
* Keywords: nagios
* Branch:
Actual behavior:
When creating a group of nagios resources ( nagios_contactgroups and
nagios_commands were the two types I tested ) puppet writes duplicate entries
in the configuration file.
Expected behavior:
A single entry is created for each resource
Note: I reverted to 2.7.11 and the issue stopped
Repro steps:
1) crate the manifest below
2) run puppet apply contactgroups.pp more than once
example manifest
pre
nagios_contactgroup { 'admins':
ensure = present,
alias = 'Nagios_Admins',
members = 'root, mague',
target = '/tmp/a.cfg',
}
nagios_contactgroup { 'pd_oncall':
ensure = present,
alias = 'PagerDuty_Controlled_Oncall_Group',
members = 'mague',
target = '/tmp/a.cfg',
}
nagios_contactgroup { 'icingaadmin':
ensure = present,
alias = 'Contacts_for_when_Icinga_goes_bad',
members = 'mague, pagerduty',
target = '/tmp/a.cfg',
}
nagios_contactgroup { 'org-contact-oncall':
ensure = present,
alias = 'org_contact_oncall',
members = 'mague, pagerduty',
target = '/tmp/a.cfg',
}
nagios_contactgroup { 'pd_hbase':
ensure = present,
alias = 'Contactgroup_Pagerduty_HBase',
members = 'mague',
target = '/tmp/a.cfg',
}
/pre
example output
pre
[cmague@puppet01:/dev/pts/0 ] /tmp
$ puppet apply contactgroups.pp
/dev/mem: Permission denied
racc/parser.rb:27: warning: already initialized constant Racc_Runtime_Version
racc/parser.rb:28: warning: already initialized constant Racc_Runtime_Revision
racc/parser.rb:30: warning: already initialized constant
Racc_Runtime_Core_Version_R
racc/parser.rb:31: warning: already initialized constant
Racc_Runtime_Core_Revision_R
racc/parser.rb:35: warning: already initialized constant
Racc_Runtime_Core_Revision_C
racc/parser.rb:39: warning: already initialized constant
Racc_Main_Parsing_Routine
racc/parser.rb:40: warning: already initialized constant Racc_YY_Parse_Method
racc/parser.rb:41: warning: already initialized constant
Racc_Runtime_Core_Version
racc/parser.rb:42: warning: already initialized constant
Racc_Runtime_Core_Revision
racc/parser.rb:43: warning: already initialized constant Racc_Runtime_Type
/dev/mem: Permission denied
/Stage[main]//Nagios_contactgroup[org-contact-oncall]/ensure: created
/Stage[main]//Nagios_contactgroup[admins]/ensure: created
/Stage[main]//Nagios_contactgroup[icingaadmin]/ensure: created
/Stage[main]//Nagios_contactgroup[pd_oncall]/ensure: created
/Stage[main]//Nagios_contactgroup[pd_hbase]/ensure: created
Finished catalog run in 0.65 seconds
[cmague@puppet01:/dev/pts/0 ] /tmp
$ puppet apply contactgroups.pp
/dev/mem: Permission denied
racc/parser.rb:27: warning: already initialized constant Racc_Runtime_Version
racc/parser.rb:28: warning: already initialized constant Racc_Runtime_Revision
racc/parser.rb:30: warning: already initialized constant
Racc_Runtime_Core_Version_R
racc/parser.rb:31: warning: already initialized constant
Racc_Runtime_Core_Revision_R
racc/parser.rb:35: warning: already initialized constant
Racc_Runtime_Core_Revision_C
racc/parser.rb:39: warning: already initialized constant
Racc_Main_Parsing_Routine
racc/parser.rb:40: warning: already initialized constant Racc_YY_Parse_Method
racc/parser.rb:41: warning: already initialized
