Thanks todd for explanation On Tuesday, October 31, 2023 at 5:47:35 PM UTC+5:30 Todd Lewis wrote:
> (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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/094b23e8-058c-4e1d-85fd-6d4292477c75n%40googlegroups.com.
