[Puppet - Bug #3118] Default node definition should not be required when ENC returns a node definition.
Issue #3118 has been updated by Alex Harvey.
This bug has been open for a long time and the result is that our documentation
contradicts the actual behavior. I am aware of sites using this behavior (i.e.
relying on default node always being applied) as a feature as Jeff suggested
above. I would vote to update docs to match the actual behavior and close this
bug. Either way it would be good to resolve it one way or another.
Bug #3118: Default node definition should not be required when ENC returns a
node definition.
https://projects.puppetlabs.com/issues/3118#change-101185
* Author: Markus Roberts
* Status: Accepted
* Priority: Normal
* Assignee:
* Category:
* Target version:
* Affected Puppet version: 0.24.8
* Keywords:
* Branch:
This behavior is surprising, but not new.
Given the external node tool:
pre
#!/usr/bin/env ruby
print %q{
---
classes:
- foo
}
exit 0
/pre
And site.pp:
pre
class foo {
notice foo
}
class bar {
notice bar
}
node default {
include bar
}
/pre
The following results are seen:
pre
info: Caching node for host-246-104.pubnet.pdx.edu
notice: Scope(Class[bar]): bar
notice: Scope(Class[foo]): foo
notice: Compiled catalog for host-246-104.pubnet.pdx.edu in 0.01 seconds
/pre
The same results are seen with 0.24.8 and 0.25.4rc3.
This appears to break the assumption that default is only applied for nodes
that aren't otherwise defined. The same is seen with an explicit node instead
of just default in site.pp
--
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.
For more options, visit https://groups.google.com/groups/opt_out.
[Puppet - Bug #23311] (Accepted) vardir default in 3.3.2
Issue #23311 has been updated by Felix Frank. Status changed from Unreviewed to Accepted Pretty sure about this one now. Easily reproduced, and looking at the code it Should Not Happen. Bug #23311: vardir default in 3.3.2 https://projects.puppetlabs.com/issues/23311#change-101186 * Author: James Eckersall * Status: Accepted * Priority: Normal * Assignee: * Category: * Target version: * Affected Puppet version: * Keywords: * Branch: Hi, I'm suffering from what looks to be the same or related bug http://projects.puppetlabs.com/issues/16637 I have an infrastructure of approximately 500 nodes managed by Puppet. They were all running 2.7.22 and today I've come to upgrade them all to 3.3.2. The boxes are a mix of CentOS and RedHat, EL5 and EL6. We manage Puppet with Puppet, so today I updated the manifest to point to the updated rpm's in the repo and let it rip. Most of my nodes are now failing to even start Puppet with the following error: Error: Could not intialize global default settings: Error converting value for param 'factpath': Could not find value for $vardir If I add the below line to /etc/puppet/puppet.conf, all is good with the world. vardir = /var/lib/puppet That line did not previously exist in the puppet.conf file, so it looks like the upgrade to 3.3.2 has introduced this bug. Now I'm faced with the unpleasant task of manually deploying a script to each node to insert that line as Puppet now refuses to start on my nodes. I can easily replicate this. Remove that line from puppet.conf and the agent will not start (service puppet start or puppet agent --test as root). J -- 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. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet - Bug #23378] (Unreviewed) Zypper package provider needs $HOME set to access username/password-protected repos
Issue #23378 has been reported by Pieter Hollants. Bug #23378: Zypper package provider needs $HOME set to access username/password-protected repos https://projects.puppetlabs.com/issues/23378 * Author: Pieter Hollants * Status: Unreviewed * Priority: High * Assignee: * Category: provider * Target version: 3.3.2 * Affected Puppet version: 3.3.1 * Keywords: zypper package provider * Branch: zypper, the command used to install packages on SUSE distributions, supports package repositories that requires a username and a password to be accessed. Unlike other comparable utilities for other distributions, zypper stores such credentials information in a file in $HOME, $HOME/.zypp/credentials.cat to be precisely. However, this requires the environment variable $HOME to be set, which is currently not the case, rendering the zypper package provider unable to access a required password. The attached patch fixes this by explicitly defining a HOME environment variable set to /root. This is correct, because the zypper command requires root permissions for both configuring software repositories and installing software. -- 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. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet - Bug #23311] vardir default in 3.3.2
Issue #23311 has been updated by Felix Frank. OK, so this seems to fix this (specs have not run yet) pre --- a/lib/puppet.rb +++ b/lib/puppet.rb @@ -145,9 +145,9 @@ module Puppet # private helper method to provide the implementation details of initializing for a run mode, # but allowing us to control where the deprecation warning is issued def self.do_initialize_settings_for_run_mode(run_mode, args) -Puppet.settings.initialize_global_settings(args) run_mode = Puppet::Util::RunMode[run_mode] Puppet.settings.initialize_app_defaults(Puppet::Settings.app_defaults_for_run_mode(run_mode)) +Puppet.settings.initialize_global_settings(args) end private_class_method :do_initialize_settings_for_run_mode /pre There are still some weird things I don't get though: This is reproducible when running the agent as root and removing vardir= from the conf file but using $vardir there. bBut/b it's not reproducible when doing the same in a regular user's conf. Currently, the issue can be worked around by not using $vardir in puppet.conf (but at least the default one in the Debian package does just that). Bug #23311: vardir default in 3.3.2 https://projects.puppetlabs.com/issues/23311#change-101187 * Author: James Eckersall * Status: Accepted * Priority: Normal * Assignee: * Category: * Target version: * Affected Puppet version: * Keywords: * Branch: Hi, I'm suffering from what looks to be the same or related bug http://projects.puppetlabs.com/issues/16637 I have an infrastructure of approximately 500 nodes managed by Puppet. They were all running 2.7.22 and today I've come to upgrade them all to 3.3.2. The boxes are a mix of CentOS and RedHat, EL5 and EL6. We manage Puppet with Puppet, so today I updated the manifest to point to the updated rpm's in the repo and let it rip. Most of my nodes are now failing to even start Puppet with the following error: Error: Could not intialize global default settings: Error converting value for param 'factpath': Could not find value for $vardir If I add the below line to /etc/puppet/puppet.conf, all is good with the world. vardir = /var/lib/puppet That line did not previously exist in the puppet.conf file, so it looks like the upgrade to 3.3.2 has introduced this bug. Now I'm faced with the unpleasant task of manually deploying a script to each node to insert that line as Puppet now refuses to start on my nodes. I can easily replicate this. Remove that line from puppet.conf and the agent will not start (service puppet start or puppet agent --test as root). J -- 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. For more options, visit https://groups.google.com/groups/opt_out.
