> This avoids the biggest problem with fragile servers which is an agglomeration of config changes and ad-hoc installations over original setup scripts. The playbook becomes your server config documentation.
If you're not careful, you can do just that with Ansible pretty easily. Put a dotfile or something under ansible management, change your mind, and unless you do a complete run where you explicitly tell ansible to delete the file it will hang around and potentially cause issues.
Not that that's unique to Ansible or anything, but it's totally possible to have servers under configuration management for their whole lifetime, and have a subtly corrupt "master" config that's unable to be applied to a fresh OS install.
If you changed the file to state=delete it should store the fact that file should not exist though - that would avoid this problem wouldn't it?
Granted you're trading in a bit of convenience for having state controlled in this way -everything would have to go through your config tool (ansible in this case) - I found commenting out tasks after I was happy they were complete in order to experiment with the next part of the config was a good way to make config changes like this painless and quick though.
I'm with you on just commenting out or deleting things as you experiment up a new system config, but once you're using that config in production it's not as safe.
If you're not careful, you can do just that with Ansible pretty easily. Put a dotfile or something under ansible management, change your mind, and unless you do a complete run where you explicitly tell ansible to delete the file it will hang around and potentially cause issues.
Not that that's unique to Ansible or anything, but it's totally possible to have servers under configuration management for their whole lifetime, and have a subtly corrupt "master" config that's unable to be applied to a fresh OS install.