On 06/03/13 20:40, Russ Allbery wrote: > Chris Boot <c...@tiger-computing.co.uk> writes: > >> Because people seem to think this is some obscure corner case, I thought >> I'd write up a very simple test case to trigger the problem: > > I think you've misunderstood the comments. > > Everyone understands that if you use symlinks in your Puppet manifests, > you will have this problem. However, there is absolutely no need to use > symlinks in your Puppet manifests, and I suspect most people don't. You > can point directly at the correct file with the source attribute.
I think you're right that I misunderstood the comments, and I agree in some cases you can indeed just point the source attribute at the right file. That won't work for us, though, but that's a different matter. > I realize that this doesn't help you directly, since you probably have an > existing layout scheme that uses symlinks. And I agree that symlinks > should work. But a lot of people aren't going to run into this problem > because they're not using symlinks and there really isn't any reason why > they should need to do so. > >> This time, Puppet does not produce an error at all, but the contents of >> the file remains unchanged and un-managed. In this case, this is silent >> corruption as Puppet fails to enforce the content change on the file. > > I don't agree with this definition of "corruption." I do agree that it's > a bug. But it doesn't corrupt anything. It just fails to make a change > that should be made. I wouldn't have nearly as much of a problem with it if when it failed to make the change, it made some noise about the failure. The fact is, it does nothing and *doesn't complain* about it at all. Nobody knows the change didn't take effect. Consider the following scenario: User is using Puppet on a Squeeze system with file resources pointing at symlinks, and upgrades the server and client to Wheezy. There is no problem here yet. User makes a change to the file pointed to by the symlink on the server. When puppet runs on the client, nothing happens. No error, but the file is not updated. User does not know of the error condition. If the user notices that the file should have updated, but has not, and tries to force the update by removing the file on the client and re-running Puppet by hand, they will then encounter the error about renaming temporary files. I have actually spent the afternoon looking into this issue in much more detail and have put an update on the pull request which was the first attempt at fixing the upstream issue: https://github.com/puppetlabs/puppet/pull/1476#issuecomment-14727535 To summarise my update: I still think the patch to fix the issue is correct, but the tests to validate this are broken. Best regards, Chris -- |Chris Boot |Tiger Computing Ltd |"Linux for Business" | |Tel: 033 0088 1511 |Web: http://www.tiger-computing.co.uk | |Registered in England. Company number: 3389961 |Registered address: Wyastone Business Park, | Wyastone Leys, Monmouth, NP25 3SR -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
