Issue #6628 has been updated by Paul Berry.
Here's what's happening: * When the client receives the catalog from the master, it reconstitutes it by creating "host" resources and their associated parsed provider objects. In the Puppet::Provider::ParsedFile#initialize() method, we attempt to create a @property_hash based on prefetched file contents (in this case, the contents of the "/tmp/hosts" file). However, at this point in execution, the file contents have not been prefetched yet, so the @property_hash is created based on old inaccurate information. * Later, when Puppet::Provider::ParsedFile.prefetch() is called, it attempts to fix the inaccurate information by rebuilding the existing ParsedFile objects. However, it only rebuilds the ParsedFile objects associated with records that were actually prefetched; any ParsedFile objects associated with records that were _not_ present don't get rebuilt. * So, in the repro steps described above, when the client runs for the second time, it builds the @property_hash for the "foo" resource based on the _old_ state of /tmp/hosts. When it later actually gets around to reading /tmp/hosts, it doesn't find a line for the "foo" resource so it doesn't rebuild it. Thus, when applying the catalog, it incorrectly concludes that the "foo" resource is still in the old correct state, so it doesn't update it. IMHO, we should fix this bug by restructuring the ParsedFile base class so that it never stores incorrect data in memory in the first place. Since this bug is produced by code in Puppet::Provider::ParsedFile, it probably exists in all providers based on ParsedFile. ---------------------------------------- Bug #6628: Parsed file providers fail to replace missing entries on first run where they are missing https://projects.puppetlabs.com/issues/6628 Author: Paul Berry Status: Accepted Priority: Normal Assignee: Category: Target version: Affected Puppet version: Keywords: Branch: I discovered this bug while trying to write integration tests for the mount provider. Thanks to Nick Lewis for helping me narrow it down to a reproducible test case. Steps to reproduce: * Start a master running this manifest: host { "foo": ip => '1.2.3.4', target => "/tmp/hosts" } * Start a client using the options `--verbose --no-daemonize --runinterval 60 --no-onetime` so that the client runs every 60 seconds. * After the client runs for the first time, open `/tmp/hosts` and delete the line 1.2.3.4 foo * After the client runs for the second time, reload the file `/tmp/hosts`. Expected behavior: the missing line should be back. Observed behavior: it isn't. * After the client runs for the third time, reload the file `/tmp/hosts`. The missing line is now back. -- 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.
