chef_handler LWRP resources are always listed as updated

This seems to be a result of this ticket:
http://tickets.opscode.com/browse/COOK-620

My gut feeling is that there should be a good way to check and see whether
or not it needs to be reloaded, if it already has been loaded, rather than
just reloading and reenabling it on every run. I’m not sure exactly what
the best way to do that would be.

For a single file, including a version or a checksum in the filename for
the handler that gets written to /var/cache/handlers/ would be pretty
straightforward; if the version or checksum is different it will need to
load the new handler (although this would mean that we would have to be
very careful about the logic to determine what old handler to unload, if
previously active). However, I’m not sure if people are tying handlers into
gems, and if they are it’s entirely possible that the changes might not be
in the file that is being pushed out, and thus undetected when the reload
is necessary.

I’m not sure if my quest for “0 resources updated” as the result of
back-to-back runs is worthwhile or not, but it’s one of the things I’ve
been working on of late. :slight_smile:


~~ StormeRider ~~

“Every world needs its heroes […] They inspire us to be better than we
are. And they protect from the darkness that’s just around the corner.”

(from Smallville Season 6x1: “Zod”)

On why I hate the phrase “that’s so lame”… http://bit.ly/Ps3uSS

On May 28, 2013, at 4:45 PM, Morgan Blackthorne wrote:

This seems to be a result of this ticket: http://tickets.opscode.com/browse/COOK-620

My gut feeling is that there should be a good way to check and see whether or not it needs to be reloaded, if it already has been loaded, rather than just reloading and reenabling it on every run. I'm not sure exactly what the best way to do that would be.

For a single file, including a version or a checksum in the filename for the handler that gets written to /var/cache/handlers/ would be pretty straightforward; if the version or checksum is different it will need to load the new handler (although this would mean that we would have to be very careful about the logic to determine what old handler to unload, if previously active). However, I'm not sure if people are tying handlers into gems, and if they are it's entirely possible that the changes might not be in the file that is being pushed out, and thus undetected when the reload is necessary.

I'm not sure if my quest for "0 resources updated" as the result of back-to-back runs is worthwhile or not, but it's one of the things I've been working on of late. :slight_smile:

The chef_handler LWRP actually does reload on every run, so this is correct. There is otherwise not enough information about the state of the client unfortunately, and we can't really mtime/checksum a code object safely :-/

--Noah

Hi,

In many of our handlers we define a blacklist of
recipe/resource/action combos that are ignored. So we essentially
manage to remove all actions that don't represent change. For an
example see [1] where the filtering is done in the handler. It is a
bit painful to configure and manage (we essentially have one big
global blob of ignores) but it has proved to make it possible to
identify which resources are actually changing. We actually use it to
feed data into our ITIL tool to (semi) accurately track changes.

[1] chef-gelf_handler/files/default/chef_gelf_handler.rb at master · realityforge/chef-gelf_handler · GitHub

On Wed, May 29, 2013 at 9:45 AM, Morgan Blackthorne
stormerider@gmail.com wrote:

This seems to be a result of this ticket:
http://tickets.opscode.com/browse/COOK-620

My gut feeling is that there should be a good way to check and see whether
or not it needs to be reloaded, if it already has been loaded, rather than
just reloading and reenabling it on every run. I'm not sure exactly what the
best way to do that would be.

For a single file, including a version or a checksum in the filename for the
handler that gets written to /var/cache/handlers/ would be pretty
straightforward; if the version or checksum is different it will need to
load the new handler (although this would mean that we would have to be very
careful about the logic to determine what old handler to unload, if
previously active). However, I'm not sure if people are tying handlers into
gems, and if they are it's entirely possible that the changes might not be
in the file that is being pushed out, and thus undetected when the reload is
necessary.

I'm not sure if my quest for "0 resources updated" as the result of
back-to-back runs is worthwhile or not, but it's one of the things I've been
working on of late. :slight_smile:

--
~~ StormeRider ~~

"Every world needs its heroes [...] They inspire us to be better than we
are. And they protect from the darkness that's just around the corner."

(from Smallville Season 6x1: "Zod")

On why I hate the phrase "that's so lame"... http://bit.ly/Ps3uSS

--
Cheers,

Peter Donald