Correct answer and findings:

1. In CentOS, if the action is successful and if the registered variable result is set, then a user can see these dict variables for ex: result.rc being 0, result.stdout = "something\nsomethingEsle\netc etc etc" and/or result.stdout_lines = "...same as above..." and result.results in some cases. If the action was failed, then I couldn't see result.stdout getting set in my case for using yum module if that failed due to connection reset or other reason. In that case, the only dict variable available for a failed action was result.rc != 0. Thus, in the until loop, until: result.rc == 0 condition worked for both successful/failed case for CentOS.

2. In Ubuntu, if the apt module action was successful, I got result.stdout and result.stdout_lines variables set but no result.rc dict variable set. For a failed operation, there's was no result.stdout or result.stdout_lines or result.rc dict variables set. SO, in case of Ubuntu, I couldn't use until loop using one of these dictionary variables.

The only workaround I can think of is, to wrap the apt-get install <pacakge> in a script and use until loop in BASH etc to do what Ansible is doing. At least, that'll be little easier to code and if the exit code is not 0, then I can use until.

But, I finally found a solution, which works in Ubuntu for both successful and failed cases:

Jinja2 filters may help i.e. when: result|failed therefore, if I have to use a registered variable result for a FAILED condition, then using with until, I'll use it (opposite of failed status) i.e. as:

until: result|succeeded

The good thing is that, the above until statement will work for both CentOS and Ubuntu and for both successful/failed states.

You can avoid 'dict object' has no attribute by using jinja2 selectattr() syntax as in :

when: me|selectattr("cool", "defined")|list|length >0

idea obtained from Michael Hoglan at https://groups.google.com/forum/#!topic/ansible-project/8XJkHQgttLA