Ansible yum: All packages providing ... are up to date - ansible

Question

OK, I'm trying to learn ansible and am running into a problem doing a very basic operation.
Playbook:
---
- hosts: fedtest
tasks:
- name: Install httpd package
yum: name=httpd state=latest
sudo: yes
- name: Starting http service
service: name=http state=started
sudo: yes
ansible.cfg:
[defaults]
hostfile = /home/abcd/proj/ans/hosts
remote_user = abcd
private_key_file = /home/abcd/proj/ans/.ssh/ans.priv
Ok, I run the command:
$ ansible-playbook setup_apache.yml
PLAY [fedtest]
****************************************************************
GATHERING FACTS
***************************************************************
ok: [fedtest]
TASK: [Install httpd package]
***********************************************
failed: [fedtest] => {"failed": true, "parsed": false}
BECOME-SUCCESS-ajlxizkspxrhyrqauuvywgrtojtutomb
{"msg": "", "changed": false, "results": ["All packages providing httpd are up to date"], "rc": 0}
6.719u 1.760s 0:11.33 74.7% 0+0k 0+592io 0pf+0w
OpenSSH_6.6.1, OpenSSL 1.0.1k-fips 8 Jan 2015
debug1: auto-mux: Trying existing master
debug1: mux_client_request_session: master session id: 2
Shared connection to fedserwizard closed.
FATAL: all hosts have already failed -- aborting
PLAY RECAP
********************************************************************
to retry, use: --limit #/home/abcd/setup_apache.retry
fedtest : ok=1 changed=0 unreachable=0 failed=1
Exit 2
I did do the -vvvv on the ansible-playbook command and it looks like it is failing to execute the shell command to echo the BECOME-SUCCESS string so that playbook can continue instead of erroring out. I've tried these operations on several systems both source and destination and still get the same result.
What type of problem do I need to correct.

Answer 1

After a lot of experimenting, I notice that if the shell of the client (receiver) of the ansible apparently had to be /bin/bash and NOT /bin/tcsh which is what I had.
Interesting that according to the verbose output that I could find that /bin/sh was being explicitly being called. And to cause an ssh issue was extremely troublesome.