Puppet

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.

I suspect this explains some type specific tickets for types that use ParsedFile.