Ansible Core 2.19.0b2 has been tagged and released to PyPI. It contains a number of compatibility bugfixes, especially for callbacks that attempt to perform custom serialization of object graphs passed into the callback methods.
4 Likes
@nitzmahone this is a very interesting change and the extra security is welcome. There’s just one thing I don’t understand which is only partially documented is why ansible_managed had to go. Looks like totally unrelated to the revamp and since ansible_* is ansible’s namepace that means choosing another name and updating repositories all over the world, and everyone is gonna come up with its own flavor and roles you borrows will have their own that does not match your own etc etc That seems like quite a mess to me.
@duck-rh ansible_managed is a weird case of “we lost sight of the forest for the trees” a long time ago. People kept extending it with custom grammars (duplicating things Jinja could already do) without taking a step back to say “wait, why do we need this at all?”. It’d ultimately become a tangled overlapping mess of 3 different dynamic placeholder grammars that relied on meta-templating and was subject to template injection attacks.
If you want a fancy dynamically-calculated variable to use in your templates, well, just set one in your inventory and use it! 
In general, there’s nothing special about ansible_ prefixed vars- ansible_managed can be set as a variable anywhere you like, just like anything else. Your question did remind me of a change I forgot to include, though, which is to have the template action/lookup avoid masking ansible_managed with its calculated value if the variable already exists. That should be corrected soon via this PR - once that’s merged, you can continue to use ansible_managed in existing templates without a deprecation warning if it’s been assigned a value.
@duck-rh I’ve added some additional thoughts on the PR that makes ansible_managed var-settable if you want to weigh in there.
1 Like