I just merged in another Will Thames patch that’s been in queue for a while that reports when certain apparently trivial usage of shell/command could be better represented by using other modules.
For instance when running a playbook with:
shell: git clone https://…
The system will warn and suggest the git module be used.
This can be surpressed with:
shell: git clone https:// warn=no
If warnings are meant to be on be default in ansible.cfg.
It’s on by default but can be toggled with “command_warnings=False” in ansible.cfg
I’m open to feedback on this and whether it should be on by default or off by default.
I want to pick the right option that’s good for everyone, but I also feel there’s a huge bonus to having everyone write better playbooks.
In any case, the development branch is the right place to try it out.
Is there a list of options that are off by default, but recommended to be turned on? This would be one such option, and I think gathering=smart is another better default.
I believe all the defaults are appropriate for most people.
Smart is debateable, maybe. It depends on what kinds of facts you are relying on whether regathering is good or bad, but it’s easily to manually control with gather_facts: no, too.
pipelining is the one I’d seriously consider most people turning on, since it’s a nice performance boost, but on some SSH implementations or configurations it doesn’t always fit, so it’s off by default to avoid the “I tried ansible and it didn’t work for me” initial experience.
Out of the box working is something we definitely want.
“My thoughts are that leaving it off by default means that almost no-one will notice it, and I think that will be a shame.”
Yep, I share that same concern.
There’s a balance there.
There are perhaps ways we could make this more known, like including a note in the docs for the command module and shell web pages.
The issue I want to avoid is the one where we generate a firestorm of list questions about how to simplify a particular shell invocation, when in fact the shell invocation is non-simplifyable for whatever reason. So there will probably be a lot of folks needing to ask about warn=no who don’t normally read docs well.
Another scenario might be to reduce the frustration of someone who upgrades Ansible, doesn’t have time to change his playbooks, and then has a team hammering down on him for all the “errors”. So yes, it helps correct playbooks but may be viewed negatively because it causes some degree of hassle. I’m perhaps over-sensitive to that.
An alternative way to handle this is possibly to make the warning more verbose - and include information about how to shut it off by changing the shell line.
Such a message (for reasons of no_log and such) can’t repeat the shell command but could mention tacking warn=no onto the end of the command.
There are some options that we’ve done a VERY good job of advocating, like recent surveys seem to indicate about 50% of folks using -c ssh turn on pipelining.
I agree it’s not a total solution though, in that not everyone would learn.
Another thing we do (at least in RHEL) is ship ansible.cfg as a config file, so it’s easy to browse the available options (see also examples/ansible.cfg) in checkout.
