I do relate to the goals of the project, however the functionality we are
discussing here (seeing the effect of changes, and more useful output)
should address 80% of the existing/new users.
I'd be surprised to see a majority of the users not being interested to
exactly see what the effect is of running a play on the system, without
doing any harm. It helps with creating playbooks, templates and
eases automation and makes changes auditable.
You're referring to dry run mode, you can totally see the effect of running a play on a system.
Dry run mode is complex (defeating the goals of ansible being minimal) and also highly misleading, which is why we aren't doing it.
The best way to test is to test in cloned/staged environments, where you really know that you can't connect to your database or your service won't start because your config file is wrong.
The effect on writing modules can be avoided if this mechanism is not
mandatory and Ansible can report that a certain module does not implement
the functionality. (For some of the modules it simply means doing nothing
at all anyway)
I value consistency to be an extremely critical value in making a project usable, and we are going
to hold all modules to the same standard, so they all work the same way.
And I want them to be short, well audited, and not subject to having a lot of corner cases that are subject to bitrot.
Doubling the size of each module is bad for that.
So I am surprised this would alienate the original audience or that
such additional functionality goes against the project's goals.
Keeping things extremely small, tight, and maintainable is a goal above many others. As is consistency. I said this when I started that this is what I would always go back to, and people didn't believe me, and thought this would grow into some giant thing. It hasn't, because I'm holding true to that. It is small, it does lots, but not everything.
People are going to disagree, and I'm telling you why I disagree. But I'm not persuadable in that regard because that's not something I want for Ansible. In fact, I want to NOT have it.
With all due respect, it's kind of a little Red Hen situation, and this is one of the things I actually dislike most of Open Source. People have lots of demands, request ponies, request other people to do a ton of work for them, and are then shocked that they were asking for a pony from an alpaca farm (for free), and they get the response that someone is not interested in breeding ponies, but wouldn't you like a nice alpaca? We sell alpacas here. And we're giving them away (YESSS!!!!), but no, we won't raise a free pony for you, and have no interest in such, and they would mean taking time away from the alpacas. There is a sense of entitlement that I want to discourage. If there were a customer relationship, this might be different, where I'd be willing to sell out and implement a lot of business features I didn't believe in, but this is not that project.
This is not directed specifically at you, but in general -- in navigating a sea of people with different opinions, different people will have different opinions, and I'm not about to let the loudest person win every time. Lots of people like our "keep it simple" philosophy, and that is why you pick Ansible. You pick competitors for other things.
Dry run is not a good safety valve for detecting errors from config change and incurs too high development cost relative to the value provided, ergo, we will not be doing it.
--Michael