(For background, a great discussion surrounding the missing backup_dir: task option can be read here: here <https://github.com/ansible/ansible/issues/16305>. Highly recommended.)
You are absolutely correct, and yet I must respectfully disagree with practically every point. > The backup system … There is no backup system. I understand you may think there is, because you've written some incredibly impressive code that uses it in the role you cited elsewhere in this thread. But if it isn't documented it doesn't exist. I've been crawling all over Ansible documentation for the last five years, and I would never have guessed such a thing was possible. And even if I knew in my bones it could be done, I wouldn't have been able to create such a thing. And even if I had written such a thing, I wouldn't dare use it in production, because it deals with Ansible internals in a way that screams, "Subject to change without notice." The docs have improved tremendously in that time, by the way. It's not surprising that internal interfaces aren't as well documented as the user side of the bread-n-butter modules, especially as so much has changed in that time. That rapid change isn't slowing, though, which makes tying business process to those internals even less attractive. > I would not 'manage it beforehand'… No, you wouldn't, because you are as familiar with the magic behind the mirror - the internal workings of Ansible - as the rest of us who are limited to the user-facing side. But the rest of us have to build our wheels with the stick-n-stones within our reach. > …as you do not know if a backup is needed… He wants to ensure he has a copy of the file. That's not a big ask. It isn't a backup, because "backup" implies a lot of things that aren't true. They also aren't true when you say "backup: true" on a task. But that's beside the point. If the user creates and maintains a copy with the copy module, with the dest name that includes the src's mtime, and does it before potentially clobbering the live conf file, then he's effectively done what "backup: true" would do, except he hasn't trashed his conf directory. Also, the copy task wouldn't make another copy if the file hadn't changed. It would only do anything if either the contents or the mtime changed, which is really all he's asking for. On Monday, October 30, 2023 at 11:34:33 AM UTC-4 Brian Coca wrote: > The backup system returns the 'backup_file' information so you can > then operate on the built in backup, like moving it to a central > location on the target, copying it to a backup server and/or managing > the number/recency of backups. > > I would not 'manage it beforehand' as you do not know if a backup is > needed until after the task that creates the backup runs, mtime is not > the best indicator. > > -- > ---------- > Brian Coca > > -- You received this message because you are subscribed to the Google Groups "Ansible Project" group. To unsubscribe from this group and stop receiving emails from it, send an email to ansible-project+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/9feb79ed-cd9e-42a5-8093-a923a6ecd89en%40googlegroups.com.
