Here’s a quick question that I was trying to find an answer for. Maybe I am missing the obvious but I can’t find a way to control the output of the “item” variable during a loop (with_items) while the playbook is running.
This shows what the current item of the current loop iteration looks like. It might be a very large json object and could clobber the output screen with unnecessary information. I would like to be able to control exactly what is been output. Is it possible to do this?
So let’s not file a request, because the first thing I will ask is to have a discussion here. Let’s talk about what you want to do and if we can come to something.
Maybe there could be an option to simply control the total size of each output line.
the length-cut is simple to implement and I don’t see how you could smarty extract and show only the important information.
length=0 (default) means: I want to see everything
Here is how I see a feature like this.
How about if we introduce a new keyword called say "print: " similar to debug but being an auxiliary keyword rather than the main task. So with this you can control some extra output that comes after [changed] [servername] => “here’s my custom output”.If this print keyword exists in a task that has a loop then it will basically be printed on every iteration.
Now if you don’t specify print: then ansible keeps doing what it does now - it prints nothing for a regular task and the full “item” content for a task with a loop. In other words the default won’t change the current behavior.
If we do have the print keyword present though then ansible still prints the [changed] [servername] part but after it, it also adds whatever “print” says - which if in a loop might contain the whole item if the author of the playbook decided to do so or maybe only parts of it: {{item.blah}} is now {{item.changed}} or something ?
I still feel this is a little confusing, but I like it better than something that is print specific, and may also be usable in other contexts, and would also not require modifying any of the callback code.
I think of “print” exactly like “debug” - it accepts a completely arbitrary template as a parameter, with variables and plain text, but instead of being the main target/task like debug it is an auxiliary one and simply complements the main output after status and server. It is a non-mandatory keyword and if omitted we show what we show today.
With regards to the name - feel free to use any other word if more appropriate: “echo” maybe ?
I’m not looking forward to seeing the “print” parameter plumb down into the awareness of all the callbacks to do that.
I think I’d rather see it filter what gets recorded at that point, in which case, it’s really not print, it’s something like “filter_fields” or “keep_fields”.
And if provided is your idea that it would always print, or would it use -v? Debug does force -v for that step now.