You should be able to have a task that delegates to localhost (if you want the CSV file local), and use a loop through the data in the variable + ansible.builtin.lineinfile to add lines
@jrglynn2 don’t use connection: local this only works if controller and targets are configured the same, but for those in heterogeneous environments that breaks, use delegate_to: localhost
(u'Thu Sep 26 18:12:43 UTC 2024', u'compute01.slc.csswx.nas.faa.gov', u'Dec 2 21:24:48 2033 GMT', u'Tue Dec 5 21:28:15 UTC 2023')
Where are the “u’” coming from? How can I get rid of them and the parens?
the u is for ‘python unicode string’, it happens when you stringify some python objects using their default representation. The parens and the u show that you are stringifying a tuple, which you are creating with the , s
Then you’ve gotten lucky (or just haven’t noticed when it failed to work.) This approach is not safe and should not be used ever. Even if it seems to work perfectly for you it is inherently a flawed pattern that relies on luck to win the race.
I´ve really only used lineinfile in conjunction with delegate_to: localhost and run_once: true as a gateway of last resort once - which should be ok if a specific module does not exist and template is unpractical. And yes, I would have noticed if it failed to work However, I can see that parallel writing to the same file is not a good idea.
I totally understand why lineinfile is not a great option. I’ve never used templating before. I tried to use the code example you gave me but failed horribly. What other options do I have? I need to run this script against 250+ VMs to collect the data I need.
We are not talking about lineinfile in the abstract, we are talking about the concrete approach of using it to update a single file on localhost for multiple hosts, since that is what you suggested doing. Specifically, this was your suggestion:
Then you have not used the construct you suggested, got incredibly lucky, or just didn’t notice when it failed. This is not about my experience, it is an inherent flaw in how that task works.
The argument arises because you provided conceptually broken tasks that should not be learned from, and will cause problems for people that can be subtle and hard to notice. I don’t know why you’re still arguing that it’s a safe thing to do when it’s demonstrably not, as shown in my immediately previous post. I didn’t have to try to break it or jump through hoops to get those results, I just ran it ten times and it failed on 4 of them.
Don’t write code with race conditions. It’s a bad idea.