hw-cookbooks/dpkg_autostart — pull request #4 by mpasternacki (2013-09-16 19:39:47+00:00)
Title: Fix notifications by monkey-patching Chef::ResourceCollection

The cookbooks, as of version 0.6, **breaks delayed notifications** at least for Chef client 11.4.4 and 11.6.0. This is a critical issue, and the symptom is very hard to track down: it results in Chef trying to run actions of one resource on a different resource, e.g. an `:install` action intended for a package is executed for a template, which fails horribly. This is caused by `unshift`ing our resource to front of `resource_collection`, and happens only if the `resource_collection` is not empty at the moment of `unshift`ing; possibly it also needs to have delayed notifications already queued.

This is caused by Chef's `ResourceCollection` holding not only the collection itself, but also a hash that maps resources' names to the collection indices. When the collection array is being updated without updating the mapping, the subsequent lookups fail.

Probably the approach of unshifting the resource is not the best one, but I could not think of any approach that would render the script at the end of the compile phase when we know final attributes, and before any `package` resources have had chance to run. I didn't want to do a deep refactor of your code, and I had limited time to deal with the immediate issue.

I have worked around the issue by defining a `Chef::ResourceCollection#unshift` method that updates both the array and the mapping. This fixes the issue, but a more straightforward design for the cookbook may be a good idea anyway. If I have some time, I may try to propose some solution; a good approach may be creating a directory to add a file for each package as a `DpkgAutostart` resource action, and have the script - that could be created in compile time then - test for existence of the file. This would behave as one expects from a resource. One problem with this approach would be files left over after removing a recipe from run list, but this is a very common thing anyway and much less of a problem than bombing the `chef-client` run.