Coming back after running multiples tests with core 2.19b and opening some issues
(Note : there is a limitation of 2 links per post, and had to remove the other direct links to the issues)
First things first
1)
Also, I doubt they meant to be rude, it is probably the comment born from already being tired and looking at work they don’t want nor need to do.
I will echo bcoca and say that I doubt flowerysong meant to come off as rude but I see how it could have been interpreted that way.
In my experience, is it more than being rude.
This usually happen because something was seen ticking them enough to warrant an answer, while they initially decided you are not worthy of their time.
Using “I’m not reading all this” as an excuse just to answer this small detail.
Days later and not being tired will not change this, the initial post will never be read.
2)
@bcoca
As for ‘making things an error’, I point you at our deprecation policy of 4 versions … which might not be enough for you if you are still running 2.9 but it should be if running 2.16, which we believe is reasonable. If we get enough data to say otherwise we would revisit the deprecation cycle, as we have done in the past (from 2 versions to 4). Also note that we have slowed down our release cadence, both because the project is more mature and to align with both Python and OS release cycles.
Again, it is not about deprecating the warn
parameter. It had to go, on this we agree.
Nor It is about the deprecation policy.
It is about the fact the 2 main choices to handle the removal of the warn
parameter were :
a) raising an immediate error when the parameter is found in a command or shell task.
b) ignoring the parameter, and printing a warning message in the execution (or printing nothing).
The Ansible team, if not you, choose A), without a care about the fallout. Granted, not excessive, but still breaking hard for the first time the compatibility between Ansible versions, namely 2.14 vs 2.13 and lower, with no alternative common to all versions.
The problem is that such door was opened, which shouldn’t have been. Because if done one time, it will be done again. Precisely what is happening again with the 2.19 data tagging, as a much larger scope.
I would like to point that for example, the venerable grep
command has the -y
parameter which is obsolete, but kept for compatibility as stated in the MAN. cURL has also some behavior related to certificates also kept for compatibility.
3)
As of now with core 2.19.0b6, with my way of not trusting the usual automatic type conversion from any language, a large part of the Ansible magic altered with 2.19 has a limited impact on the roles I’ve built since years.
As said, my own results must not be taken as a reference.
Point in case, some colleagues have much much more trouble, sometimes not understanding why, and far from being done.
I also didn’t see much of any speed improvement.
I’m waiting for the next beta containing the fix for the profile_tasks regression (#85331) before comparing the numbers more precisely.
But I also have some roles unable to complete at all due to errors with 2.19. Even while using the _ANSIBLE_TEMPLAR_SANDBOX_MODE
environment variable.
Another problem is, the most advanced capabilities of my roles will not survive with ansible 2.19 without this templar sandox mode parameter. Mostly, the generic “serial by group” and the special inventory parsing making it much more natural.
And that’s a serious problem, because as of now, this is a temporary workaround not here to last (for now).
4) Extremely serious question about core 2.19 changes :
When preparing the changes for core 2.19, did the Ansible team ask themselves at a time about the possibility a rollback might be required ? Or at the minimum, having to hit the brakes hard ?
Given the precedent with the warn
parameter, the evasion around it, and some borderline, if not unprofessional answers I got on the opened issues for core 2.19b, I personally don’t think so.
In fact, I’ve lost all trust and expect another ansible core release breaking again a major part hard very soon.
As I’m not one to use those words lightly :
-
issue #85336 ipv4 (and others from ansible.netcommon) not usable with the short name
I understand the fact it might not be ansible-core, but hey, not everybody is privy to the subtleties of the repo separations, Especially for a collection in the ansible.*
namespace.
Second, “not my backyard, go search somewhere in the building” is not an answer. This is not a community collection, but an ansible.*
namespace collection, a major part of Ansible itself. As stated on its readme, supported by Red Hat.
I would have gladly taken being pointed to the correct repo and asked to reopen the issue there.
-
issue #85333 --one-line
parameter deprecated ?
Unannounced change, and I’m still baffled by the answer. Especially for a module, if I’m not mistaken, less than 100 lines comments included, existing since (nearly) the start of Ansible.
-
And the madness of ansible_template
You really expect people editing all their inventories because you refuse to be bothered to keep it in a restricted form in ansible.cfg
, if not making it hard-coded internally ?
It is not to undermine the work you’ve done, Ansible has become a major player, that ticked soundly all the right cases from start.
But seriously, the situation now with core 2.19 really show the disconnect and the contempt of a dev team too much in deep, adamant to punch through the target at hand because deadlines, without a care for anybody nor the consequences, while being aware of them.
Coming from the production side, that’s sort of situation is typical. I just would have never imagined seeing this on Ansible itself.
And in this, you are also forgetting you have real customers. Notably Red Hat customers, for anything related to Ansible Tower / AAP.
I am not sure the folks at Red Hat will accept taking flak happily.
Mostly because they will have in front some people telling them to fix it, without taking no for an answer : they are paying a very hefty sum for the support.
For them, core is just one cog in the larger machine of Ansible AAP.
Being told they must rework a non-negligible part of the playbooks, roles and tasks they have built and were working correctly for years before 2.19 due to a change in a cog will not be accepted.
Wondering if some will be pissed enough to go through a fork.