Issue #10465 has been updated by Oliver Hookins.
The unfortunate reality is that providers do have bugs and the number of possible situations a provider can encounter is infinite. No amount of combinatorial testing will uncover every possibilty, nor will you be able to code the providers to test for all possible problems they might encounter (e.g. files being set immutable in the filesystem would probably cause problems for most providers, silently). Given this is the case, but we still want to be aware of the distinction between a failure of a provider to do its job versus a system in constant entropy, reporting back the success of a provider's attempted changes fills that gap in functionality. The former case might be something like acpid which cannot be started inside an OpenVZ container (even if the init script reports it has been started), and the latter might be a an angry sysadmin who logs into the system and disables acpid - before the next Puppet run. There are just too many buggy pieces of software to adequately handle, but if Puppet were to implement this feature we'd at least get a more reliable insight into bugs vs natural/unnatural system entropy. Does that make more sense? ---------------------------------------- Feature #10465: Provide a new "obsessive" mode which queries resources again after sync https://projects.puppetlabs.com/issues/10465 Author: Oliver Hookins Status: Needs More Information Priority: Normal Assignee: Oliver Hookins Category: provider Target version: Affected Puppet version: Keywords: Branch: Quite frequently there will be cases where the providers think they have done the right thing and report success even though the end result is not successful. This results in continual runs where there are successful changes but the overall outcome is the same - the system state is not what you want it to be. I would like for there to be a mode you can optionally enable that triggers a second query from the provider after the sync has occurred to see if the desired changes were actually done. If not, trigger a real error (which in fact is just reflecting more accurately the state of the machine than if we were to not perform this checking). In the case where Puppet is being used for larger orchestrated upgrades this is an essential component to figuring out if the desired changes were completed successfully and thus attention can be turned to the next machine(s) in the workflow. -- 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 post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
