Bug #1499
puppetd should fail when Facter fails
| Status: | Closed | Start date: | 08/08/2008 | |
|---|---|---|---|---|
| Priority: | Normal | Due date: | ||
| Assignee: | - | % Done: | 0% |
|
| Category: | agent | |||
| Target version: | 0.24.6 | |||
| Affected Puppet version: | 0.24.4 | Branch: | ||
| Keywords: | ||||
| Votes: | 0 |
Description
Hi,
The issue I am having is a server when puppet/facter runs and the server has a high load. Based upon facter 1.5 the timeouts have been adjusted and is causing some issues. In our case we have a puppet recipe that’s using this facter.
http://reductivelabs.com/trac/puppet/wiki/Recipes/RaidFact
To determine what raid controller is installed. It has a case statement. If the raid controller is found install smartd, else remove it.
The problem is if facter timesout with this request, it should not uninstall. I would suggest facter pass something, instead of nil, like ‘timeout’ or something unique to make the puppet recipe know what happened. That way it’s a different result than than ‘nil’ and can create a case statement for it. The recipe must assume nil means no raid controller was found. Is this a modification in the RaidFact or facter itself? From what I can tell it’s a facter change.
History
Updated by Luke Kanies over 3 years ago
- Subject changed from puppetd script runs imporperly with high load server to puppetd should fail when Facter fails
- Category set to agent
- Status changed from Unreviewed to Accepted
- Target version set to 0.24.6
This is a problem on the client, not the server — if Facter can’t retrieve its full value list, then the run should probably be considered failed, rather than sending incomplete data. It’s essentially always going to be impossible to build configurations that can handle any value temporarily missing.
Even then, I’m not entirely sure this is the right approach. At the least, this would require Facter actually throwing an exception if there’s a timeout, so we catch the exception and fail, rather than just continuing.
Updated by Lawrence Ludwig over 3 years ago
luke wrote:
This is a problem on the client, not the server — if Facter can’t retrieve its full value list, then the run should probably be considered failed, rather than sending incomplete data. It’s essentially always going to be impossible to build configurations that can handle any value temporarily missing.
Even then, I’m not entirely sure this is the right approach. At the least, this would require Facter actually throwing an exception if there’s a timeout, so we catch the exception and fail, rather than just continuing.
Hi Luke,
However you see fit to solve this situation is fine by me. Is there a possible workaround? With facter 1.5 I am seeing this happen at least one every 2-3 hours on our nodes. Can facter’s timeout be increased? If so how?
Updated by Luke Kanies over 3 years ago
The only way is to modify the code. We’ll get a 1.5.1 release out with a fix ASAP, certainly early next week.
Updated by Lawrence Ludwig over 3 years ago
luke wrote:
The only way is to modify the code. We’ll get a 1.5.1 release out with a fix ASAP, certainly early next week.
Ok thanks!
Updated by Paul Nasrat over 3 years ago
- Status changed from Accepted to Closed
Facter 1.5.2 is the current release (1.5.1 fixed #1422) please update