"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. On Sun, Aug 24, 2014 at 4:25 AM, Will Thames <[email protected]> wrote: > 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. > > It's just a warning - Ansible doesn't fail if you use command when a > module exists. > > Could we try it in 1.8 devel before release - or will that cause too much > extra traffic on the list (or indeed too many surprises?) > > Anyway, I'll support whatever you think is best. > > Will > > > On Saturday, August 23, 2014 6:06:42 AM UTC+10, Michael DeHaan wrote: > >> I think I'm going to leave this off by default, in the "no new surprises" >> vein. >> >> It's still a very good feature that I think lots of people will turn on. >> >> >> >> >> On Fri, Aug 22, 2014 at 3:39 PM, Michael DeHaan <[email protected]> >> wrote: >> >>> 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. >>> >>> Thoughts? >>> >>> --Michael >>> >>> >>> >>> >>> >> -- > You received this message because you are subscribed to the Google Groups > "Ansible Project" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/ansible-project/bec263ed-287f-4b5f-80a0-8230d0b01040%40googlegroups.com > <https://groups.google.com/d/msgid/ansible-project/bec263ed-287f-4b5f-80a0-8230d0b01040%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Ansible Project" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/CA%2BnsWgzR5k7ktymZrWkE1miPQOddBOFRoCGSb5Y_isLfAdaPqA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
