Issue #19708 has been updated by Charlie Sharpsteen. Status changed from Accepted to Needs Decision
This will need a decision. As noted, the root of the problem here is that the load balancer is not allowing the puppet masters to finish handling their requests before terminating the connections. In general, this sort of situation can indicate a serious problem and throwing a rug over it by retrying until success occurs may not be the best approach. Eric, any thoughts on this one? It reminds me of the discussion that was had over retrying yum installs: https://github.com/puppetlabs/puppet/pull/1691 ---------------------------------------- Feature #19708: puppet agent retry failed http requests https://projects.puppetlabs.com/issues/19708#change-98488 * Author: Patrick Hemmer * Status: Needs Decision * Priority: Low * Assignee: Charlie Sharpsteen * Category: * Target version: * Affected Puppet version: 3.1.0 * Keywords: customer * Branch: ---------------------------------------- It would be nice if puppet agent had the ability had the ability to retry failed http requests to the puppet master. I have multiple puppet masters sitting behind a load balancer in AWS (ELB). Whenever we update a puppet master, the node is removed from the load balancer while the update occurs. Unfortunately the AWS ELB does not allow quiescent removal of nodes (such that existing connections are allowed to close gracefully). Instead it just severs the connections immediately. This causes errors for agents which are in the middle of making requests to that master. Another related scenario is when you're updating multiple puppet masters. The masters might be in the middle of updating, and so some masters have newer code than the others. A puppet agent gets a catalog from one master, which says a certain file should exist, but then when the agent goes to fetch that file, it fails because the master it tried to fetch from hasn't updated. Retrying wouldn't be an ideal solution for this scenario as a retry could just hit that same out-of-date master again, but it could possibly work. Yes the ideal solution here is session persistence, but the AWS ELB does not support it. It might be useful to even allow a configurable backoff (failure; sleep 2; failure; sleep 5; failure; abort...), though a single retry would be sufficient for the first scenario indicated above. If a backoff is implemented, I think it should only be done once in the whole puppet run. So that if you have a 100 different http requests that have to be made to the puppet master, you don't do the backoff wait thing 100+ times. -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/groups/opt_out.
