If I move the # to choose the other commandname, everything works as expected, and all the files contain a "2" afterwards.
When I use that recipe in a test kitchen, the execute ressource fails, because the file content is "1", when it is run (that's the condition that causes it to fail), but it has 'action :nothing' and the file ressource above (yes, it's the same file as at the top - I know that is generally wrong but this is reduced from a testing scenario) should change the content to a "2".
So am I doing something wrong (although this looks simple, and works with another command), or is chef actually behaving erractically? If so, is it fixed in a newer chef (I can see on the homepage that although we have a 16. version in those kitchen, it's not the newest).
So this morning I realised that the problem might be related to a unexpected inheritance between the two 'file' ressources with the same name. So I looked a bit closer on chef's output, and when I enabled the "copy_a" command, it's evaluated three times:
one time (and this was the real discovery) after putting a "1" into the /tmp/a file (so the first file resource, that does not explicitly notify that "execute" resource)
second time after putting a "2" in that file - expected
third time, when getting to during evaluating the recipe sequentially, doing nothing because of 'action :nothing'
So I tried adding 'notifies :nothing, "execute[copy_a]", :immediately' to the first "file" resource. That made the "execute" resource evaluate /five/ times (the same as above, with added "skipped due to action :nothing" before the first and second evaluation). So it didn't override the 'notifies' it just added another notification - not what I was hoping for, but at least I understand what is going on a little better. (Actually I missed the double notifications at first, so I also tried overriding the "fail_on_1" notification, that didn't work)
In general you're never supposed to have a two file resources managing the same file like that, That isn't declarative, so generally either just don't do that (construct the file contents completely and use a single file resource to write out all the data to the file declaratively) or else rename one of the file resources. If you're imperatively accumulating and constructing the file contents then you'll always be making partial updates to the file and having half-written out files. Or in your case the contents will be thrashing between '1' and '2'. Which is something you never want to do on a server. The contents of your file in any real situation should be either '1' or '2'. If you really need to do this, you need to rename one of the file resources to something else and use the path propery explicitly rather than relying on it being the name.
I know that I'm not supposed to have two resources managing the same file.
But in a previous instance of the real recipe (as I said this was a reduced example) I had some flawed logic, in a "not_if" condition on the "execute" resource that prevented it from correctly updating in some cases. So to test that my flawed logic was gone I wanted the file to be updated, and as those tests run in a test kitchen (I also mentioned that), the easy way looked like just having two resources managing the file.
As long as it's only a test that relies on a deprecated feature, nothing too bad will happen if that feature is changed/removed, so I thought it acceptable in this exceptionable case. - Some years ago I actually spend some time tracking down and fixing cases like this in our production setup.
When I found out what was actually happening, I realised that I either needed to make the file to update another way, or just to trust that my flawed logic was gone and that chef actually did update the file.
Just because I'm curious: Why is this linked issue labeled "Priority: Medium" and not "Priority: Low", it seemslike the triggering condition should never happen?
I put that one at Medium because the larger issue of what to do about same-named resources is something that should be addressed, particularly when it comes to notifications (both sending like this and receiving). We tore out the old resource cloning but then never addressed these issues of multiple resources managing the same thing so its a loose end. It also comes up often enough that some kind of warning or something should be done. But its definitely not high priority because of the fact that its most of "doing the wrong thing" and there's always the workaround of just renaming the resource. It is also a core language problem, so potentially every Chef user can hit that bug. Low priority tends to be things which are bugs/features but which have a lower occurrence or affect distros that aren't tier 1 or something like that. There is no distinct line though, tomorrow I might be convinced by someone in product that should be Low priority.