[Puppet - Bug #23319] (Duplicate) Unnecessary service restart when service is down and we set ensure = running and subscribe the service to some file(s) in puppet-2.7
Issue #23319 has been updated by Dominic Cleal.
Status changed from Unreviewed to Duplicate
This was #7165, fixed in 3.2.
On the off-chance you're using EPEL, I notice there's a regression between
2.6.18 and 2.7.23 where the patch wasn't carried forward. I've filed this as
https://bugzilla.redhat.com/show_bug.cgi?id=1038041.
Bug #23319: Unnecessary service restart when service is down and we set ensure
= running and subscribe the service to some file(s) in puppet-2.7
https://projects.puppetlabs.com/issues/23319#change-100988
* Author: Alex D
* Status: Duplicate
* Priority: High
* Assignee:
* Category:
* Target version:
* Affected Puppet version:
* Keywords:
* Branch:
Steps to reproduce:
1) create test.pp file:
pre
service {
nginx:
ensure = running,
enable = true,
subscribe = File[/tmp/test1];
}
file {
/tmp/test1:
ensure = file,
content = kasjakjksjjks;
}
/pre
2) Install nginx and set error_log level to info
3) Make sure nginx is down and /tmp/test1 file does not exist:
pre
service nginx stop
rm -f /tmp/test1
/pre
4) Apply the test.pp file:
pre
puppet apply test.pp
/pre
Result: puppet brings nginx service up and then restarts it.
Result in stdout:
pre
notice: /Stage[main]//File[/tmp/test1]/ensure: defined content as
'{md5}502675e3d4e9692deb2e3b2e262450c1'
notice: /Stage[main]//Service[nginx]/ensure: ensure changed 'stopped' to
'running'
notice: /Stage[main]//Service[nginx]: Triggered 'refresh' from 1 events
/pre
Result in nginx log:
pre
2013/11/29 16:44:38 [notice] 3900#0: using the epoll event method
2013/11/29 16:44:38 [notice] 3900#0: nginx/1.0.15
2013/11/29 16:44:38 [notice] 3900#0: built by gcc 4.4.7 20120313 (Red Hat
4.4.7-3) (GCC)
2013/11/29 16:44:38 [notice] 3900#0: OS: Linux
2.6.32-358.123.2.openstack.el6.x86_64
2013/11/29 16:44:38 [notice] 3900#0: getrlimit(RLIMIT_NOFILE): 1024:4096
2013/11/29 16:44:38 [notice] 3901#0: start worker processes
2013/11/29 16:44:38 [notice] 3901#0: start worker process 3904
2013/11/29 16:44:38 [notice] 3901#0: signal 15 (SIGTERM) received, exiting
2013/11/29 16:44:38 [notice] 3904#0: exiting
2013/11/29 16:44:38 [notice] 3904#0: exit
2013/11/29 16:44:38 [notice] 3901#0: signal 17 (SIGCHLD) received
2013/11/29 16:44:38 [notice] 3901#0: worker process 3904 exited with code 0
2013/11/29 16:44:38 [notice] 3901#0: exit
2013/11/29 16:44:38 [notice] 3940#0: using the epoll event method
2013/11/29 16:44:38 [notice] 3940#0: nginx/1.0.15
2013/11/29 16:44:38 [notice] 3940#0: built by gcc 4.4.7 20120313 (Red Hat
4.4.7-3) (GCC)
2013/11/29 16:44:38 [notice] 3940#0: OS: Linux
2.6.32-358.123.2.openstack.el6.x86_64
2013/11/29 16:44:38 [notice] 3940#0: getrlimit(RLIMIT_NOFILE): 1024:4096
2013/11/29 16:44:38 [notice] 3941#0: start worker processes
2013/11/29 16:44:38 [notice] 3941#0: start worker process 3943
/pre
Strace:
pre
2912 execve(/bin/env, [env, -i, PATH=/sbin:/usr/sbin:/bin:/usr/bin,
TERM=screen, /etc/init.d/nginx, status], [/* 28 vars */]) = 0
2912 execve(/etc/init.d/nginx, [/etc/init.d/nginx, status], [/* 2 vars
*/]) = 0
2926 execve(/bin/env, [env, -i, PATH=/sbin:/usr/sbin:/bin:/usr/bin,
TERM=screen, /etc/init.d/nginx, start], [/* 28 vars */]) = 0
2926 execve(/etc/init.d/nginx, [/etc/init.d/nginx, start], [/* 2 vars
*/]) = 0
2945 execve(/bin/env, [env, -i, PATH=/sbin:/usr/sbin:/bin:/usr/bin,
TERM=screen, /etc/init.d/nginx, status], [/* 28 vars */]) = 0
2945 execve(/etc/init.d/nginx, [/etc/init.d/nginx, status], [/* 2 vars
*/]) = 0
2954 execve(/bin/env, [env, -i, PATH=/sbin:/usr/sbin:/bin:/usr/bin,
TERM=screen, /etc/init.d/nginx, stop], [/* 28 vars */]) = 0
2954 execve(/etc/init.d/nginx, [/etc/init.d/nginx, stop], [/* 2 vars
*/]) = 0
2966 execve(/bin/env, [env, -i, PATH=/sbin:/usr/sbin:/bin:/usr/bin,
TERM=screen, /etc/init.d/nginx, start], [/* 28 vars */]) = 0
2966 execve(/etc/init.d/nginx, [/etc/init.d/nginx, start], [/* 2 vars
*/]) = 0
/pre
Such behavior may break some services deployment (cluster services that start
to synchronize on the first start and then get stopped/started again).
--
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 #23319] Unnecessary service restart when service is down and we set ensure = running and subscribe the service to some file(s) in puppet-2.7
Issue #23319 has been updated by Alex D.
OK, thanks for the info. I'm not using EPEL, this issue with service
refresh/restart exists in puppet-2.7.23 installed from puppetlabs repo:
pre
# puppet --version
2.7.23
/pre
pre
# rpm -qi puppet
Name: puppet Relocations: (not relocatable)
Version : 2.7.23Vendor: Puppet Labs
Release : 1.el6 Build Date: Wed 14 Aug 2013
09:44:16 PM UTC
Install Date: Wed 04 Dec 2013 11:04:08 AM UTC Build Host: rpm-builder-5
Group : System Environment/Base Source RPM:
puppet-2.7.23-1.el6.src.rpm
Size: 3357077 License: ASL 2.0
Signature : RSA/SHA1, Thu 15 Aug 2013 02:10:55 PM UTC, Key ID 1054b7a24bd6ec30
URL : http://puppetlabs.com
Summary : A network tool for managing many disparate systems
/pre
Bug #23319: Unnecessary service restart when service is down and we set ensure
= running and subscribe the service to some file(s) in puppet-2.7
https://projects.puppetlabs.com/issues/23319#change-100989
* Author: Alex D
* Status: Duplicate
* Priority: High
* Assignee:
* Category:
* Target version:
* Affected Puppet version:
* Keywords:
* Branch:
Steps to reproduce:
1) create test.pp file:
pre
service {
nginx:
ensure = running,
enable = true,
subscribe = File[/tmp/test1];
}
file {
/tmp/test1:
ensure = file,
content = kasjakjksjjks;
}
/pre
2) Install nginx and set error_log level to info
3) Make sure nginx is down and /tmp/test1 file does not exist:
pre
service nginx stop
rm -f /tmp/test1
/pre
4) Apply the test.pp file:
pre
puppet apply test.pp
/pre
Result: puppet brings nginx service up and then restarts it.
Result in stdout:
pre
notice: /Stage[main]//File[/tmp/test1]/ensure: defined content as
'{md5}502675e3d4e9692deb2e3b2e262450c1'
notice: /Stage[main]//Service[nginx]/ensure: ensure changed 'stopped' to
'running'
notice: /Stage[main]//Service[nginx]: Triggered 'refresh' from 1 events
/pre
Result in nginx log:
pre
2013/11/29 16:44:38 [notice] 3900#0: using the epoll event method
2013/11/29 16:44:38 [notice] 3900#0: nginx/1.0.15
2013/11/29 16:44:38 [notice] 3900#0: built by gcc 4.4.7 20120313 (Red Hat
4.4.7-3) (GCC)
2013/11/29 16:44:38 [notice] 3900#0: OS: Linux
2.6.32-358.123.2.openstack.el6.x86_64
2013/11/29 16:44:38 [notice] 3900#0: getrlimit(RLIMIT_NOFILE): 1024:4096
2013/11/29 16:44:38 [notice] 3901#0: start worker processes
2013/11/29 16:44:38 [notice] 3901#0: start worker process 3904
2013/11/29 16:44:38 [notice] 3901#0: signal 15 (SIGTERM) received, exiting
2013/11/29 16:44:38 [notice] 3904#0: exiting
2013/11/29 16:44:38 [notice] 3904#0: exit
2013/11/29 16:44:38 [notice] 3901#0: signal 17 (SIGCHLD) received
2013/11/29 16:44:38 [notice] 3901#0: worker process 3904 exited with code 0
2013/11/29 16:44:38 [notice] 3901#0: exit
2013/11/29 16:44:38 [notice] 3940#0: using the epoll event method
2013/11/29 16:44:38 [notice] 3940#0: nginx/1.0.15
2013/11/29 16:44:38 [notice] 3940#0: built by gcc 4.4.7 20120313 (Red Hat
4.4.7-3) (GCC)
2013/11/29 16:44:38 [notice] 3940#0: OS: Linux
2.6.32-358.123.2.openstack.el6.x86_64
2013/11/29 16:44:38 [notice] 3940#0: getrlimit(RLIMIT_NOFILE): 1024:4096
2013/11/29 16:44:38 [notice] 3941#0: start worker processes
2013/11/29 16:44:38 [notice] 3941#0: start worker process 3943
/pre
Strace:
pre
2912 execve(/bin/env, [env, -i, PATH=/sbin:/usr/sbin:/bin:/usr/bin,
TERM=screen, /etc/init.d/nginx, status], [/* 28 vars */]) = 0
2912 execve(/etc/init.d/nginx, [/etc/init.d/nginx, status], [/* 2 vars
*/]) = 0
2926 execve(/bin/env, [env, -i, PATH=/sbin:/usr/sbin:/bin:/usr/bin,
TERM=screen, /etc/init.d/nginx, start], [/* 28 vars */]) = 0
2926 execve(/etc/init.d/nginx, [/etc/init.d/nginx, start], [/* 2 vars
*/]) = 0
2945 execve(/bin/env, [env, -i, PATH=/sbin:/usr/sbin:/bin:/usr/bin,
TERM=screen, /etc/init.d/nginx, status], [/* 28 vars */]) = 0
2945 execve(/etc/init.d/nginx, [/etc/init.d/nginx, status], [/* 2 vars
*/]) = 0
2954 execve(/bin/env, [env, -i, PATH=/sbin:/usr/sbin:/bin:/usr/bin,
TERM=screen, /etc/init.d/nginx, stop], [/* 28 vars */]) = 0
2954 execve(/etc/init.d/nginx, [/etc/init.d/nginx, stop], [/* 2 vars
*/]) = 0
2966 execve(/bin/env, [env, -i, PATH=/sbin:/usr/sbin:/bin:/usr/bin,
TERM=screen, /etc/init.d/nginx, start], [/* 28 vars */]) = 0
2966 execve(/etc/init.d/nginx, [/etc/init.d/nginx, start], [/* 2 vars
*/]) = 0
/pre
Such behavior may break some services deployment (cluster services that start
to synchronize on the first start and then get stopped/started again).
--
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:
[Puppet - Bug #23349] (Unreviewed) Could not find value for $confdir regression when using $confdir in puppet.conf
Issue #23349 has been reported by Dominic Cleal. Bug #23349: Could not find value for $confdir regression when using $confdir in puppet.conf https://projects.puppetlabs.com/issues/23349 * Author: Dominic Cleal * Status: Unreviewed * Priority: Normal * Assignee: * Category: settings * Target version: 3.4.0 * Affected Puppet version: 3.4.0-rc1 * Keywords: * Branch: This is a regression from 3.3.x to 3.4.0-rc1. When puppet.conf contains the following: pre [main] autosign = $confdir/autosign.conf /pre All puppet commands fail as the $confdir can't be interpolated. pre # puppet --version 3.3.2 # puppet apply --configprint autosign /etc/puppet/autosign.conf # yum upgrade --enablerepo=puppetlabs-devel puppet [snip, updated to 3.4.0-rc1] # rpm -q puppet puppet-3.4.0-0.1rc1.el6.noarch # puppet apply --configprint autosign Error: Could not intialize global default settings: Error converting value for param 'autosign': Could not find value for $confdir # puppet --version Error: Could not intialize global default settings: Error converting value for param 'autosign': Could not find value for $confdir /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 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 #23349] Could not find value for $confdir regression when using $confdir in puppet.conf
Issue #23349 has been updated by Dominic Cleal. bitsect points to aad83a8be02bd1ceaca2115dfed1a68df33d7015: pre Author: Adrien Thebo g...@somethingsinistral.net Date: Fri Nov 1 09:15:51 2013 -0700 (maint) Ensure that the autosign setting is validated. Original patch by Patrick Hemmer patrick.hem...@gmail.com /pre Bug #23349: Could not find value for $confdir regression when using $confdir in puppet.conf https://projects.puppetlabs.com/issues/23349#change-100990 * Author: Dominic Cleal * Status: Unreviewed * Priority: Normal * Assignee: * Category: settings * Target version: 3.4.0 * Affected Puppet version: 3.4.0-rc1 * Keywords: * Branch: This is a regression from 3.3.x to 3.4.0-rc1. When puppet.conf contains the following: pre [main] autosign = $confdir/autosign.conf /pre All puppet commands fail as the $confdir can't be interpolated. pre # puppet --version 3.3.2 # puppet apply --configprint autosign /etc/puppet/autosign.conf # yum upgrade --enablerepo=puppetlabs-devel puppet [snip, updated to 3.4.0-rc1] # rpm -q puppet puppet-3.4.0-0.1rc1.el6.noarch # puppet apply --configprint autosign Error: Could not intialize global default settings: Error converting value for param 'autosign': Could not find value for $confdir # puppet --version Error: Could not intialize global default settings: Error converting value for param 'autosign': Could not find value for $confdir /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 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 #23351] (Unreviewed) systemd service provider thinks 'activating' services are inactive
Issue #23351 has been reported by Sam Morris.
Bug #23351: systemd service provider thinks 'activating' services are inactive
https://projects.puppetlabs.com/issues/23351
* Author: Sam Morris
* Status: Unreviewed
* Priority: Normal
* Assignee:
* Category: service
* Target version:
* Affected Puppet version: 2.7.23
* Keywords: systemd
* Branch:
I have a systemd service that, when started, takes a few seconds before failing
to start. Systemd is configured to restart the service when it fails to start,
so when you look at the output of 'systemctl status' you see:
vagrant@pipeline:~$ systemctl status
hadoop-hdfs-secondarynamenode.service
hadoop-hdfs-secondarynamenode.service - Hadoop secondarynamenode
Loaded: loaded
(/etc/systemd/system/hadoop-hdfs-secondarynamenode.service; disabled)
Active: activating (start) since Wed 2013-12-04 14:05:50 UTC; 3s ago
Control: 27702 (sudo)
CGroup: name=systemd:/system/hadoop-hdfs-secondarynamenode.service
├─27702 sudo -E -u hdfs /bin/bash -c cd /var/lib/hadoop-hdfs
/usr/lib/hadoop/sbin/hadoop-d...
├─27709 /bin/bash -c cd /var/lib/hadoop-hdfs
/usr/lib/hadoop/sbin/hadoop-daemon.sh --confi...
├─27710 bash /usr/lib/hadoop/sbin/hadoop-daemon.sh --config
/etc/hadoop/conf start secondaryn...
└─27767 sleep 3
In my Puppet manifest, I've got:
service{'hadoop-hdfs-secondarynamenode.service':
ensure = stopped,
enable = false,
provider = systemd,
}
However, applying the manifest does not result in the service being stopped.
This appears to be due to the following:
$ systemctl is-active hadoop-hdfs-secondarynamenode.service; echo $?
activating
3
i.e., service.rb thinks the service is stopped, because the systemctl command
'failed' (returned non-zero).
In practice, systemd units can be in any of the following states, taken from
http://cgit.freedesktop.org/systemd/systemd/tree/src/core/unit.h#n46:
enum UnitActiveState {
UNIT_ACTIVE,
UNIT_RELOADING,
UNIT_INACTIVE,
UNIT_FAILED,
UNIT_ACTIVATING,
UNIT_DEACTIVATING,
_UNIT_ACTIVE_STATE_MAX,
_UNIT_ACTIVE_STATE_INVALID = -1
};
The code for `systemctl is-active` code to look at is at
http://cgit.freedesktop.org/systemd/systemd/tree/src/systemctl/systemctl.c#n2391.
In brief, the command exits with status 0 only if the state is UNIT_ACTIVE or
UNIT_RELOADING; otherwise it exits with status 3 (to indicate that the service
is not running).
IMO puppet should look at the output of 'systemctl is-active SERVICENAME', and
if the output is 'active', 'reloading' or 'activating', it should consider the
service to be running. If you are happy with that change, I'll implement it and
send you a patch.
--
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 #23352] (Unreviewed) Revisit how facter detects GCE instances
Issue #23352 has been reported by Eric Johnson. Bug #23352: Revisit how facter detects GCE instances https://projects.puppetlabs.com/issues/23352 * Author: Eric Johnson * Status: Unreviewed * Priority: Normal * Assignee: Eric Johnson * Category: facter * Target version: * Affected Puppet version: * Keywords: * Branch: With the launch of GCE v1 API, Google has revised the recommended way of determining if the virtual machine resides within GCE. Updated instructions state to use 'sudo dmidecode -s bios-vendor | grep Google' (same URL, new instructions at https://developers.google.com/compute/docs/instances#dmi). GCE v1 no longer requires google-only kernels and we can no longer rely on the old method of checking /sys/firmware/dmi/entries/1-0/raw. The virtual utility, https://github.com/puppetlabs/facter/blob/master/lib/facter/util/virtual.rb#L160 requires an update. -- 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.
[Facter - Bug #22009] (Closed) Facter does not work with solaris zones properly.
Issue #22009 has been updated by David K.
Status changed from Needs More Information to Closed
Yes this is fixed the 1.7.3 now.
Thanks sorry for the late reply.
Bug #22009: Facter does not work with solaris zones properly.
https://projects.puppetlabs.com/issues/22009#change-101003
* Author: David K
* Status: Closed
* Priority: Normal
* Assignee: David K
* Category:
* Target version:
* Keywords:
* Branch:
* Affected Facter version: 1.7.2
is_virtual and virtual are wrong.
Issue is there are two SunOS confines. The second out does no checking for
being a zone at all so it defaults to physical.
Solution: remove SunOS from the list of..
Facter.add(virtual) do
confine :kernel = %w{Linux FreeBSD OpenBSD SunOS HP-UX GNU/kFreeBSD}
--
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 #19396] Wrong environment being saved in yaml/database when using storeconfigs
Issue #19396 has been updated by David K. Hi Eric -- I think we can close this now. I am well beyond using storeconfigs in deprecated mode and I suspect the rest of the world is as well. Bug #19396: Wrong environment being saved in yaml/database when using storeconfigs https://projects.puppetlabs.com/issues/19396#change-101004 * Author: David K * Status: Investigating * Priority: Normal * Assignee: eric sorenson * Category: * Target version: * Affected Puppet version: 3.1.0 * Keywords: yaml environment mysql activerecord * Branch: Using puppet 3.1 with multiple static environments and: reports = store storeconfigs = true thin_storeconfigs = true results in the wrong environment being stored in the mysql database as well as /var/lib/puppet/yaml/node/host.yaml file. The environment in the yaml file actually changes from the proper environment to the wrong one during the run. The yaml file and database use whatever the masters default environment = is set to under the [master] section - I can make them save whatever value I want. /var/lib/puppet/reports/host/.yaml contains the correct environment name. If I disable storeconfigs the /var/lib/puppet/yaml/node is correct. -- 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 #13475] (Closed) Filebucket HEAD returns 404
Issue #13475 has been updated by David K.
Status changed from Accepted to Closed
Closing - as indicated in my previous note this seems fixed in the 3.x branch.
Bug #13475: Filebucket HEAD returns 404
https://projects.puppetlabs.com/issues/13475#change-101005
* Author: David K
* Status: Closed
* Priority: Normal
* Assignee:
* Category: filebucket
* Target version: 3.x
* Affected Puppet version: 2.7.12
* Keywords:
* Branch:
Using mongrel 1.2.0-pre2 with puppet 2.7.12 the filebucket HEAD requests do not
work as intended.
This gives a 404 even on files which exist with the proper checksum and path,
as a result files are re-bucketed many times across our clients (not a big deal
as 2.6.x did this anyways).
I believe the issue is because in network/http/handler.rb the do_head method
does not set a status response code. It looks as if this defaults to 404 in
mongrel unless otherwise set. It looks like if the indirection request is true,
we should just return a 200 status code, and if it's not, the do_exception
throwing an 404 will handle the errors.
Something like this maybe?
def do_head(indirection_name, key, params, request, response)
result = self.model(indirection_name).indirection.head(key, params)
unless result
Puppet.info(Could not find #{indirection_name} for '#{key}')
return do_exception(response, Could not find #{indirection_name}
#{key}, 404)
end
set_response(response, result)
end
--
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 #23356] (Unreviewed) `puppet resource service` errors out, puppet 3.2.2 on ubuntu 12
Issue #23356 has been reported by victor piousbox. Bug #23356: `puppet resource service` errors out, puppet 3.2.2 on ubuntu 12 https://projects.puppetlabs.com/issues/23356 * Author: victor piousbox * Status: Unreviewed * Priority: Normal * Assignee: * Category: * Target version: * Affected Puppet version: * Keywords: * Branch: I hope this is an easy fix... I get this error: Error: Could not run: Execution of '/sbin/status bridge-network-interface' returned 1: status: Unknown parameter: INTERFACE -- 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 #19520] puppet parser validate - no output when everything's ok
Issue #19520 has been updated by Gabriel Schuyler. Plus one for the --verbose option. Fundamentals classes would be more comfortable with specific confirmation that the syntax is okay. Bug #19520: puppet parser validate - no output when everything's ok https://projects.puppetlabs.com/issues/19520#change-101015 * Author: Carthik Sharma * Status: Accepted * Priority: Normal * Assignee: * Category: usability * Target version: 3.x * Affected Puppet version: * Keywords: errors * Branch: Running `puppet parser validate init.pp` returns nothing on the command line when there are no errors. Please consider adding a message like OK or No Parse Error that indicates to the user that the file(s) passed parser validation. This comes up for discussion at almost every fundamentals class I teach, where someone asks So I see no output, is that what is supposed to happen? From a UX perspective, providing feedback on the success of a validation attempt would be nice (subjectively speaking). -- 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 #20173] Logdest cannot be set in the puppet.conf
Issue #20173 has been updated by Eddie Satterly. This is required for core functionality to build the a Splunk app for Puppet and to be able to track all changes and show the current health of the Puppet system in Splunk. This is a request from several Splunk customers. Feature #20173: Logdest cannot be set in the puppet.conf https://projects.puppetlabs.com/issues/20173#change-101020 * Author: Celia Cottle * Status: Investigating * Priority: Normal * Assignee: Charlie Sharpsteen * Category: logging * Target version: * Affected Puppet version: * Keywords: customer * Branch: This is potentially a duplicate issue of a few things floating around out there, but most focus on masterlog, so I'm opening this up separately. Currently you can use --logdest /var/log/somelogfile, but you cannot set it in the puppet.conf. This seems like an oversight, especially since there seems to be a good number of people who wish to keep all puppet logs out of /var/log/messages. There are ways around this (etc/init.d/pe-puppet), but they are purely workarounds. It looks like some of the reason for this is the old masterlog option, which it seems is no longer in use, used to be the preferred way of setting in the puppet.conf. Potentially related tickets: https://projects.puppetlabs.com/issues/5952 https://projects.puppetlabs.com/issues/4550 https://projects.puppetlabs.com/issues/12361 -- 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 #23359] (Accepted) Provide proxy support for pip latest (package)
Issue #23359 has been reported by Christophe Larsonneur.
Feature #23359: Provide proxy support for pip latest (package)
https://projects.puppetlabs.com/issues/23359
* Author: Christophe Larsonneur
* Status: Accepted
* Priority: Normal
* Assignee: Christophe Larsonneur
* Category: modules
* Target version:
* Affected Puppet version: 2.7.23
* Keywords: pip proxy
* Branch:
On a company network, usually we have proxy settings.
Following code fail with error:
package { 'virtualenv':
ensure = latest,
provider = $pip_provider,
}
Error: Timeout while contacting pypi.python.org
--
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 #22848] Encoding mis-matches cause package prefetching to fail
Issue #22848 has been updated by Charlie Sharpsteen.
Subject changed from Encoding bug in Puppet 3.3.1 when using Ruby 1.9.3 (and
above) to Encoding mis-matches cause package prefetching to fail
Bug #22848: Encoding mis-matches cause package prefetching to fail
https://projects.puppetlabs.com/issues/22848#change-101023
* Author: Jos Backus
* Status: Needs More Information
* Priority: High
* Assignee:
* Category: ruby19
* Target version:
* Affected Puppet version: 3.3.1
* Keywords: utf8 encoding package customer
* Branch:
One of our RPM packages has some UTF-8 characters in its description, leading
to an exception (Error: Could not prefetch package provider 'yum': invalid
byte sequence in US-ASCII) in rpm.rb, causing no packages to be upgraded as
the yumhelper.py invocation code raises that error.
Priority=High because it breaks file { ensure = latest; }.
--
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 #23218] (Duplicate) Fails to parse UTF-8 dpkg-query output when running on non-UTF-8 locale
Issue #23218 has been updated by Charlie Sharpsteen.
Status changed from Unreviewed to Duplicate
Keywords set to encoding utf8
Thanks a bunch for the bug report and the pointer to the Debian guidelines.
This particular issue is affecting more than just dpkg and we are tracking the
issue in ticket #22848.
Bug #23218: Fails to parse UTF-8 dpkg-query output when running on non-UTF-8
locale
https://projects.puppetlabs.com/issues/23218#change-101024
* Author: Bernhard Schmidt
* Status: Duplicate
* Priority: Normal
* Assignee:
* Category: package
* Target version:
* Affected Puppet version: 3.3.1
* Keywords: encoding utf8
* Branch:
Puppet 3.3 outputs the following error message when running with a non-UTF-8
locale (i.e. C or de_DE) while parsing dpkg-query output
Debug: Prefetching apt resources for package
Debug: Executing '[/usr/bin/dpkg-query, -W, --showformat, '${Status}
${Package} ${Version} :DESC: ${Description}\\n:DESC:\\n']'
Error: Could not prefetch package provider 'apt': invalid byte sequence in
US-ASCII
This most likely happens due to the UTF-8 quotation marks in the description of
the kbd package on Debian. UTF-8 is legal according to my understanding of
Policy 5.1, so Puppet should just cope with it.
See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=724645 for more information
--
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 #23218] Fails to parse UTF-8 dpkg-query output when running on non-UTF-8 locale
Issue #23218 has been updated by Charlie Sharpsteen.
Assignee set to Charlie Sharpsteen
Bug #23218: Fails to parse UTF-8 dpkg-query output when running on non-UTF-8
locale
https://projects.puppetlabs.com/issues/23218#change-101025
* Author: Bernhard Schmidt
* Status: Duplicate
* Priority: Normal
* Assignee: Charlie Sharpsteen
* Category: package
* Target version:
* Affected Puppet version: 3.3.1
* Keywords: encoding utf8
* Branch:
Puppet 3.3 outputs the following error message when running with a non-UTF-8
locale (i.e. C or de_DE) while parsing dpkg-query output
Debug: Prefetching apt resources for package
Debug: Executing '[/usr/bin/dpkg-query, -W, --showformat, '${Status}
${Package} ${Version} :DESC: ${Description}\\n:DESC:\\n']'
Error: Could not prefetch package provider 'apt': invalid byte sequence in
US-ASCII
This most likely happens due to the UTF-8 quotation marks in the description of
the kbd package on Debian. UTF-8 is legal according to my understanding of
Policy 5.1, so Puppet should just cope with it.
See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=724645 for more information
--
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 #19396] (Closed) Wrong environment being saved in yaml/database when using storeconfigs
Issue #19396 has been updated by eric sorenson. Status changed from Investigating to Closed Thanks for the update, closing. Bug #19396: Wrong environment being saved in yaml/database when using storeconfigs https://projects.puppetlabs.com/issues/19396#change-101026 * Author: David K * Status: Closed * Priority: Normal * Assignee: eric sorenson * Category: * Target version: * Affected Puppet version: 3.1.0 * Keywords: yaml environment mysql activerecord * Branch: Using puppet 3.1 with multiple static environments and: reports = store storeconfigs = true thin_storeconfigs = true results in the wrong environment being stored in the mysql database as well as /var/lib/puppet/yaml/node/host.yaml file. The environment in the yaml file actually changes from the proper environment to the wrong one during the run. The yaml file and database use whatever the masters default environment = is set to under the [master] section - I can make them save whatever value I want. /var/lib/puppet/reports/host/.yaml contains the correct environment name. If I disable storeconfigs the /var/lib/puppet/yaml/node is correct. -- 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 #22363] (In Topic Branch Pending Review) Implement new evaluator for future parser
Issue #22363 has been updated by Josh Partlow. Status changed from Accepted to In Topic Branch Pending Review Target version set to 3.5.0 Branch set to https://github.com/puppetlabs/puppet/pull/2123 Feature #22363: Implement new evaluator for future parser https://projects.puppetlabs.com/issues/22363#change-101028 * Author: Henrik Lindberg * Status: In Topic Branch Pending Review * Priority: Normal * Assignee: Henrik Lindberg * Category: language * Target version: 3.5.0 * Affected Puppet version: * Keywords: language parser evaluation * Branch: https://github.com/puppetlabs/puppet/pull/2123 The future parser currently performs evaluation by transforming the future (nick named pops) AST model into the old (3.x) AST and evaluates the transformed result. The purpose of this evaluator is to untangle the currently nested evaluation behavior (in AST and various other classes) to improve separation of concerns (leading to robustness and code that is easier to work with, debug and extend). Since evaluation of the pops model currently involves transformation to the current AST it is also slow and removal of this step should boost the performance. -- 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 #22365] All errors created by future parser ast_transformer lack line numbers
Issue #22365 has been updated by Josh Partlow.
Branch set to https://github.com/puppetlabs/puppet/pull/2123
Bug #22365: All errors created by future parser ast_transformer lack line
numbers
https://projects.puppetlabs.com/issues/22365#change-101029
* Author: Erik Dalén
* Status: In Topic Branch Pending Review
* Priority: Normal
* Assignee: Henrik Lindberg
* Category: parser
* Target version: 3.5.0
* Affected Puppet version: 3.2.4
* Keywords: future_parser
* Branch: https://github.com/puppetlabs/puppet/pull/2123
Errors created by the ast transformer in the future parser have the wrong type,
so they lack line numbers. An example is:
puppet apply --parser=future -e 'File|| ? {default=foo}'
--
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 #22366] The future parser validator doesn't catch using bad resource types in collection queries
Issue #22366 has been updated by Josh Partlow. Branch set to https://github.com/puppetlabs/puppet/pull/2123 Bug #22366: The future parser validator doesn't catch using bad resource types in collection queries https://projects.puppetlabs.com/issues/22366#change-101030 * Author: Erik Dalén * Status: In Topic Branch Pending Review * Priority: Normal * Assignee: Henrik Lindberg * Category: parser * Target version: 3.5.0 * Affected Puppet version: 3.2.4 * Keywords: * Branch: https://github.com/puppetlabs/puppet/pull/2123 For example: puppet apply --parser=future -e '1||' Error: Resource type #puppet::pops::model::literalnumber:0x007f822724c1c8 doesn't exist on node dalen -- 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 #22454] (In Topic Branch Pending Review) match variables are only partially shadowed
Issue #22454 has been updated by Josh Partlow.
Status changed from Accepted to In Topic Branch Pending Review
Target version set to 3.5.0
Affected Puppet version deleted (3.3.0-rc2)
Branch set to https://github.com/puppetlabs/puppet/pull/2123
Bug #22454: match variables are only partially shadowed
https://projects.puppetlabs.com/issues/22454#change-101031
* Author: Henrik Lindberg
* Status: In Topic Branch Pending Review
* Priority: Normal
* Assignee:
* Category: language
* Target version: 3.5.0
* Affected Puppet version:
* Keywords: language
* Branch: https://github.com/puppetlabs/puppet/pull/2123
Match expressions have the side effect of setting `$0`-`$n` numerical variables
to the matched, and each matched capture.
As many variables as there are captures are set.
The implementation in scope creates a new ephemeral scope-level for each match
expression. As an example:
if 'foobar' =~ /(f)(o)(o)(b)(a)(r)/ and 'foo' =~ /(f)(o)(o)/ {
notice $4
}
Outputs b since the second match did not have a $4.
This is surprising. The most nested ephemeral scope should be responsible for
returning all numeric variables (i.e. from the last successful match).
This behavior have been in place for quite some time.
--
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.
