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
@nitzmahone thanks for the reply.
I know I can add one myself but that’s not the point here. I had no idea you could customize it and I can understand this level of customization can cause problems and why you want to change it. I’m not opposed to that.
The problem is, customized or not, people are used to this variable and if they start adding new variable names all over the place then I’ll end-up with having to set a bunch or such variables to please all the third-party roles I’m using instead of a dedicated one.
As for the variable name I tend to respect namespaces because if it does not outright cause problems it might in the future. The simple fact you need to make this extra PR to remove the masking means that if it’s not magic there’s still parts of Ansible that treats it differently. If it saves me the trouble to update all the roles I created then I’ll surely give it a try but it feels like there’s still a risk.