[Puppet - Bug #21729] duplicate resource collections during catalog compilation
Issue #21729 has been updated by Andrew Parker. Yes, unfortunately this behavior is a consequence of the [semantics of the puppet language](https://github.com/puppetlabs/puppet/blob/master/lib/puppet/parser/compiler.rb#L318-337). `define` types are not eagerly evaluated and instead are deferred until all other resources have been compiled. Collections need to be re-evaluated in order to make sure they collect anything that might have been exported later, including anything from the deferred `define` types. There have been other issues reported with respect to our eager vs. lazy evaluation (#5517). This could be solved by the puppetdb terminus by having it cache queries, which would be more correct. Unfortunately it doesn't know when a new catalog is being dealt with and so can't know when to invalidate that cache. It does receive the `@scope` object, and so it could use that. Bug #21729: duplicate resource collections during catalog compilation https://projects.puppetlabs.com/issues/21729#change-98905 * Author: Patrick Hemmer * Status: Accepted * Priority: Normal * Assignee: Deepak Giridharagopal * Category: compiler * Target version: * Affected Puppet version: 3.3.0 * Keywords: puppetdb, exported resources, collection, compiler * Branch: While attempting to troubleshoot performance issues with puppetdb, I noticed that during a single catalog compilation, the same resources are trying to be collected multiple times. In my case, what is normally 4 collections turns into 28. This is potentially the source of my performance issue when multiple nodes check in and hammer puppetdb with all these duplicate collections. Here is a very simple test showing a single resource being collected twice: pre rm /tmp/testcompile; puppet apply --noop --profile --debug --logdest /tmp/testcompile -e 'Ssh_authorized_key ||'; grep Collect /tmp/testcompile 2013-07-12 00:10:08 + Scope(Class[main]) (debug): Collected 1 Ssh_authorized_key resource in 0.18 seconds 2013-07-12 00:10:08 + Scope(Class[main]) (debug): Collected 0 Ssh_authorized_key resources in 0.14 seconds /pre (attached is the full version of this log file) Catalog generation for a real node looks like this (this is from a `puppet master --compile NODENAME --profile --debug --logdest /tmp/compile`): pre # grep Collected /tmp/compile 2013-07-11 22:35:06 + Scope(Class[Common::Hosts]) (debug): Collected 1 Host resource in 0.32 seconds 2013-07-11 22:35:06 + Scope(Class[Common::Rundeck]) (debug): Collected 1 Ssh_authorized_key resource in 0.15 seconds 2013-07-11 22:35:06 + Scope(Class[Common::Rundeck]) (debug): Collected 1 File resource in 0.15 seconds 2013-07-11 22:35:06 + Scope(Class[Common::User::Root]) (debug): Collected 0 Ssh_authorized_key resources in 0.15 seconds 2013-07-11 22:35:09 + Scope(Class[Common::Hosts]) (debug): Collected 0 Host resources in 1.09 seconds 2013-07-11 22:35:10 + Scope(Class[Common::Rundeck]) (debug): Collected 0 Ssh_authorized_key resources in 1.31 seconds 2013-07-11 22:35:11 + Scope(Class[Common::Rundeck]) (debug): Collected 0 File resources in 0.84 seconds 2013-07-11 22:35:12 + Scope(Class[Common::User::Root]) (debug): Collected 0 Ssh_authorized_key resources in 0.59 seconds 2013-07-11 22:35:13 + Scope(Class[Common::Hosts]) (debug): Collected 0 Host resources in 0.35 seconds 2013-07-11 22:35:14 + Scope(Class[Common::Rundeck]) (debug): Collected 0 Ssh_authorized_key resources in 0.40 seconds 2013-07-11 22:35:14 + Scope(Class[Common::Rundeck]) (debug): Collected 0 File resources in 0.57 seconds 2013-07-11 22:35:15 + Scope(Class[Common::User::Root]) (debug): Collected 0 Ssh_authorized_key resources in 0.50 seconds 2013-07-11 22:35:16 + Scope(Class[Common::Hosts]) (debug): Collected 0 Host resources in 0.47 seconds 2013-07-11 22:35:16 + Scope(Class[Common::Rundeck]) (debug): Collected 0 Ssh_authorized_key resources in 0.76 seconds 2013-07-11 22:35:18 + Scope(Class[Common::Rundeck]) (debug): Collected 0 File resources in 1.46 seconds 2013-07-11 22:35:19 + Scope(Class[Common::User::Root]) (debug): Collected 0 Ssh_authorized_key resources in 1.20 seconds 2013-07-11 22:35:20 + Scope(Class[Common::Hosts]) (debug): Collected 0 Host resources in 0.95 seconds 2013-07-11 22:35:21 + Scope(Class[Common::Rundeck]) (debug): Collected 0 Ssh_authorized_key resources in 1.15 seconds 2013-07-11 22:35:23 + Scope(Class[Common::Rundeck]) (debug): Collected 0 File resources in 1.18 seconds 2013-07-11 22:35:24 + Scope(Class[Common::User::Root]) (debug): Collected 0 Ssh_authorized_key resources in 1.52 seconds 2013-07-11 22:35:25 + Scope(Class[Common::Hosts]) (debug): Collected 0 Host resources in 1.15 seconds 2013-07-11 22:35:26 + Scope(Class[Common::Rundeck]) (debug): Collected 0 Ssh_authorized_key resources in 0.91 seconds 2013-07-11
[Puppet - Feature #18268] Allow the windows service start type to be specified during installation
Issue #18268 has been updated by Ethan Brown. Additional fix merged into master in [101e4e5cb07fdb236601d18e6416af141baaf49e](https://github.com/puppetlabs/puppet_for_the_win/commit/101e4e5cb07fdb236601d18e6416af141baaf49e) Feature #18268: Allow the windows service start type to be specified during installation https://projects.puppetlabs.com/issues/18268#change-98906 * Author: Luis Mayorga * Status: Merged - Pending Release * Priority: Normal * Assignee: * Category: * Target version: 3.4.0 * Affected Puppet version: 2.7.12 * Keywords: windows * Branch: https://github.com/puppetlabs/puppet_for_the_win/pull/57 Hi, We are using Jenkins to automate provisioning and would like to request another installation argument for the puppet .msi package to stop starting after installation. This will give us more control on when to request provisioning on the puppet clients. Something like... msiexec /qn /i puppet.msi PUPPET_MASTER_SERVER=puppet.acme.com START_BY_DEFAULT=false -- 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 - Feature #22906] (Accepted) MSI properties that have a default value don't allow the remembered property to be applied during an upgrade
Issue #22906 has been reported by Rob Reynolds. Feature #22906: MSI properties that have a default value don't allow the remembered property to be applied during an upgrade https://projects.puppetlabs.com/issues/22906 * Author: Rob Reynolds * Status: Accepted * Priority: Normal * Assignee: Rob Reynolds * Category: * Target version: 3.4.0 * Affected Puppet version: development * Keywords: windows * Branch: If you install puppet on windows, the value is persisted in the registry. If you upgrade and don't specify a new value, the persisted value should be re-applied, but is not. Specifically: pre lt;Property Id=PUPPET_MASTER_SERVER Value=puppetgt; lt;Property Id=PUPPET_AGENT_ENVIRONMENT Value=productiongt; /pre To reproduce, install 3.3.1 (or whenever the property was introduced): pre start /w msiexec /qn /i puppet-3.3.1.msi PUPPET_MASTER_SERVER=myotherserver /pre Make sure the value is in the registry and puppet.conf: pre reg query HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Puppet Labs\PuppetInstaller /v RememberedPuppetMasterServer type c:\programdata\puppetlabs\puppet\etc\puppet.conf /pre Upgrade to the new version without specifying a new value: pre start /w msiexec /qn /i puppet-latest.msi /pre puppet.conf will revert back to the default `puppet` instead of the remembered value `myotherserver` This wasn't an issue previously, because once a value was written to puppet.conf, it was never changed, even if a new value was specified in the command line. -- 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 #22906] MSI properties that have a default value don't allow the remembered property to be applied during an upgrade
Issue #22906 has been updated by Rob Reynolds. Tracker changed from Feature to Bug Bug #22906: MSI properties that have a default value don't allow the remembered property to be applied during an upgrade https://projects.puppetlabs.com/issues/22906#change-98928 * Author: Rob Reynolds * Status: Accepted * Priority: Normal * Assignee: Rob Reynolds * Category: * Target version: 3.4.0 * Affected Puppet version: development * Keywords: windows * Branch: If you install puppet on windows, the value is persisted in the registry. If you upgrade and don't specify a new value, the persisted value should be re-applied, but is not. Specifically: pre lt;Property Id=PUPPET_MASTER_SERVER Value=puppetgt; lt;Property Id=PUPPET_AGENT_ENVIRONMENT Value=productiongt; /pre To reproduce, install 3.3.1 (or whenever the property was introduced): pre start /w msiexec /qn /i puppet-3.3.1.msi PUPPET_MASTER_SERVER=myotherserver /pre Make sure the value is in the registry and puppet.conf: pre reg query HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Puppet Labs\PuppetInstaller /v RememberedPuppetMasterServer type c:\programdata\puppetlabs\puppet\etc\puppet.conf /pre Upgrade to the new version without specifying a new value: pre start /w msiexec /qn /i puppet-latest.msi /pre puppet.conf will revert back to the default `puppet` instead of the remembered value `myotherserver` This wasn't an issue previously, because once a value was written to puppet.conf, it was never changed, even if a new value was specified in the command line. -- 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 #22906] (In Topic Branch Pending Review) MSI properties that have a default value don't allow the remembered property to be applied during an upgrade
Issue #22906 has been updated by Rob Reynolds. Status changed from Accepted to In Topic Branch Pending Review Branch set to https://github.com/puppetlabs/puppet_for_the_win/pull/61 Bug #22906: MSI properties that have a default value don't allow the remembered property to be applied during an upgrade https://projects.puppetlabs.com/issues/22906#change-98930 * Author: Rob Reynolds * Status: In Topic Branch Pending Review * Priority: Normal * Assignee: Rob Reynolds * Category: * Target version: 3.4.0 * Affected Puppet version: development * Keywords: windows * Branch: https://github.com/puppetlabs/puppet_for_the_win/pull/61 If you install puppet on windows, the value is persisted in the registry. If you upgrade and don't specify a new value, the persisted value should be re-applied, but is not. Specifically: pre lt;Property Id=PUPPET_MASTER_SERVER Value=puppetgt; lt;Property Id=PUPPET_AGENT_ENVIRONMENT Value=productiongt; /pre To reproduce, install 3.3.1 (or whenever the property was introduced): pre start /w msiexec /qn /i puppet-3.3.1.msi PUPPET_MASTER_SERVER=myotherserver /pre Make sure the value is in the registry and puppet.conf: pre reg query HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Puppet Labs\PuppetInstaller /v RememberedPuppetMasterServer type c:\programdata\puppetlabs\puppet\etc\puppet.conf /pre Upgrade to the new version without specifying a new value: pre start /w msiexec /qn /i puppet-latest.msi /pre puppet.conf will revert back to the default `puppet` instead of the remembered value `myotherserver` This wasn't an issue previously, because once a value was written to puppet.conf, it was never changed, even if a new value was specified in the command line. -- 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 - Feature #22910] (Accepted) Deprecate resource as a REST endpoint
Issue #22910 has been reported by Andrew Parker. Feature #22910: Deprecate resource as a REST endpoint https://projects.puppetlabs.com/issues/22910 * Author: Andrew Parker * Status: Accepted * Priority: Normal * Assignee: Andrew Parker * Category: * Target version: 3.4.0 * Affected Puppet version: * Keywords: * Branch: The `/environment/resource` endpoint is a risk to have on the master, and will be going away on the agent. One part of deprecating this is that `--host` on `puppet resource` should also be deprecated. Going forward users that want to have this kind of remote-resource-control functionality should use [mcollective](http://puppetlabs.com/mcollective) 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. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet - Feature #22910] (In Topic Branch Pending Review) Deprecate resource as a REST endpoint
Issue #22910 has been updated by Andrew Parker. Status changed from Accepted to In Topic Branch Pending Review Branch set to https://github.com/puppetlabs/puppet/pull/2004 https://github.com/puppetlabs/puppet/pull/2004 Feature #22910: Deprecate resource as a REST endpoint https://projects.puppetlabs.com/issues/22910#change-98937 * Author: Andrew Parker * Status: In Topic Branch Pending Review * Priority: Normal * Assignee: Andrew Parker * Category: * Target version: 3.4.0 * Affected Puppet version: * Keywords: * Branch: https://github.com/puppetlabs/puppet/pull/2004 The `/environment/resource` endpoint is a risk to have on the master, and will be going away on the agent. One part of deprecating this is that `--host` on `puppet resource` should also be deprecated. Going forward users that want to have this kind of remote-resource-control functionality should use [mcollective](http://puppetlabs.com/mcollective) 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. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet - Bug #3707] Yum provider purge target runs irrespective of package installation status
Issue #3707 has been updated by Killboy Powerhed.
I realise this is an off-the-cuff response (very little thought or testing as
well) as I only came across this issue today, but if most people just want the
yum provider to remove dependencies isn't a quick patch better than nothing ? -
this issue seems to have been ongoing for 4+ years in various tickets. Adding
an override 'uninstall' method to the yum provider seems to do what I want it
to do, then I just use 'absent' instead of 'purge' and the puppet run output is
clean.
The fact that an incorrectly validated module could wipe out most of a system
by removing all of a packages dependencies is present but isn't that what dev
environments are for? This way we can get on with our work while someone fixes
the purge issue in the background ;)
Happy to be enlightened if I've missed something major..
thanks
--- a/puppet/provider/package/yum.rb2013-10-19 00:24:40.931068196 +1100
+++ b/puppet/provider/package/yum.rb2013-10-19 00:43:43.023276312 +1100
@@ -96,5 +96,9 @@
def purge
yum -y, :erase, @resource[:name]
end
+
+ def uninstall
+yum -y, :erase, @resource[:name]
+ end
end
Bug #3707: Yum provider purge target runs irrespective of package
installation status
https://projects.puppetlabs.com/issues/3707#change-98939
* Author: Oliver Hookins
* Status: Code Insufficient
* Priority: Normal
* Assignee: Charlie Sharpsteen
* Category: package
* Target version:
* Affected Puppet version: 3.2.4
* Keywords: customer
* Branch: https://github.com/mmrobins/puppet/tree/ticket/2.7.x/3707-yum_purging
It seems the yum provider will try to purge an absent package:
pre
[root@test ~]# cat test.pp
package { logwatch: ensure = purged; }
[root@test ~]# /bin/rpm -q logwatch --nosignature --nodigest --qf '%{NAME}
%|EPOCH?{%{EPOCH}}:{0}| %{VERSION} %{RELEASE} %{ARCH}'
package logwatch is not installed
[root@test ~]# puppet -d -v test.pp
debug: Puppet::Type::Package::ProviderRpm: Executing '/bin/rpm --version'
debug: Puppet::Type::Package::ProviderUrpmi: Executing '/bin/rpm -ql rpm'
debug: Puppet::Type::Package::ProviderYum: Executing '/bin/rpm --version'
debug: Puppet::Type::Package::ProviderAptrpm: Executing '/bin/rpm -ql rpm'
debug: Puppet::Type::Package::ProviderPorts: file /usr/local/sbin/portupgrade
does not exist
debug: Puppet::Type::Package::ProviderAptitude: file /usr/bin/aptitude does not
exist
debug: Puppet::Type::Package::ProviderSunfreeware: file pkg-get does not exist
debug: Puppet::Type::Package::ProviderUp2date: file /usr/sbin/up2date-nox does
not exist
debug: Puppet::Type::Package::ProviderApt: file /usr/bin/apt-get does not exist
debug: Puppet::Type::Package::ProviderPortage: file /usr/bin/emerge does not
exist
debug: Puppet::Type::Package::ProviderRug: file /usr/bin/rug does not exist
debug: Puppet::Type::Package::ProviderDpkg: file /usr/bin/dpkg does not exist
debug: Puppet::Type::Package::ProviderSun: file /usr/sbin/pkgrm does not exist
debug: Puppet::Type::Package::ProviderAptrpm: file apt-get does not exist
debug: Puppet::Type::Package::ProviderFink: file /sw/bin/fink does not exist
debug: Puppet::Type::Package::ProviderHpux: file /usr/sbin/swremove does not
exist
debug: Puppet::Type::Package::ProviderUrpmi: file urpmi does not exist
debug: Puppet::Type::Package::ProviderFreebsd: file /usr/sbin/pkg_info does not
exist
debug: Puppet::Type::Package::ProviderOpenbsd: file pkg_info does not exist
debug: Creating default schedules
debug: Failed to load library 'selinux' for feature 'selinux'
debug: Puppet::Type::User::ProviderLdap: true value when expecting false
debug: Puppet::Type::User::ProviderUser_role_add: file roleadd does not exist
debug: Puppet::Type::User::ProviderDirectoryservice: file /usr/bin/dscl does
not exist
debug: Puppet::Type::User::ProviderPw: file pw does not exist
debug: Failed to load library 'ldap' for feature 'ldap'
debug: /File[/var/lib/puppet/ssl/private]: Autorequiring
File[/var/lib/puppet/ssl]
debug: /File[/var/lib/puppet/client_yaml]: Autorequiring File[/var/lib/puppet]
debug: /File[/var/lib/puppet/facts]: Autorequiring File[/var/lib/puppet]
debug: /File[/var/lib/puppet/ssl/public_keys]: Autorequiring
File[/var/lib/puppet/ssl]
debug: /File[/var/lib/puppet/ssl]: Autorequiring File[/var/lib/puppet]
debug: /File[/var/lib/puppet/ssl/certs/ca.pem]: Autorequiring
File[/var/lib/puppet/ssl/certs]
debug: /File[/var/lib/puppet/lib]: Autorequiring File[/var/lib/puppet]
debug: /File[/var/lib/puppet/ssl/certificate_requests]: Autorequiring
File[/var/lib/puppet/ssl]
debug: /File[/var/lib/puppet/ssl/certs]: Autorequiring File[/var/lib/puppet/ssl]
debug: /File[/var/lib/puppet/clientbucket]: Autorequiring File[/var/lib/puppet]
debug: /File[/var/lib/puppet/ssl/crl.pem]: Autorequiring
File[/var/lib/puppet/ssl]
debug: /File[/var/lib/puppet/state/graphs]: Autorequiring
File[/var/lib/puppet/state]
debug:
