@renard, we need more information to resolve this issue. For that reason, we put this Issue into the 'needs_info' state.

Here are the required items we could not find in your description:

• issue type

When you have filled in the missing data, we will notify the module maintainer for further action.
click here for bot help

Hmmm..... that's complicated... The short answer is yes.

The longer answer is that it appears to only be required because we have it in setup.py as an install_requires. It is actually not required by the code unless you use the paramiko connection type.

I'll ask what the other committers want to do about it... There used to be many platforms where paramiko significantly outperformed shelling out to the ssh client to do the job so it made a ton of sense. Now there's only a handful of platforms where that's the case. keeping it in install_requires is the only way to make sure that pip installs paramiko when it installs ansible but if someone knows what they're doing, they can leave it off their system so it would be nice not to make this a runtime dependency...

!needs_info

I didn't use pip to install ansible, but a git clone. Again I don't care about installing paramiko even if I do not need it. It was just the warning message that was confusing since cryptography was installed.

bcoca's suggestion: if we can confirm the 'paramiko is best' platforms ... which i believe are OS X due to sshpass and systems with very old openssh which does not do controlpersist (centos5) then make the install_requires include paramiko only when installed on those platforms.

We'll also have to update paramiko to give 'nice errors' and suggest installing requirements if someone specifies it directly (not via 'smart' setting).

Which will probably happen when the 'target' machines have poor controlpersist support as we can only really detect issues with the 'controller' on which Ansible is installed.

again the problem is not about installing paramiko or not.

The problem here is a warning suggesting cryptography is not (or not correctly) installed.

@renard, sorry, we did hijack the thread, I for one am OK with changing this warning into a -vvvv or debug 'information', as long as the system will work and the user should not see any difference.

@renard The warning is just that, a warning. We could display more information about the exception (perhaps move the traceback from ansible.debug to a verbosity level so that -vvv shows it?) if that helps. For any library using setuptools' dependency management (unfortunately, cryptography and ansible both fall under that) there is the danger that localized problems in the overall dependency chain can affect unrelated packages in the overall chain. So a lot of times even the traceback might not be too helpful in diagnosing the problem.

I think part of the problem is that we are displaying a warning and a debug for the same thing. So you don't get full information immediately, or instruction on how to get more info:

except Exception as e:
    display.warning("Optional dependency 'cryptography' raised an exception, falling back to 'Crypto'")
    import traceback
    display.debug("Traceback from import of cryptography was {0}".format(traceback.format_exc()))

Maybe we should change that debug to something else, such as vvvv so that it is printed with higher verbosity, and indicating in the warning that running with -vvvv will provide more information.

ok do as you think it's the best solution. But please add a note somewhere that for user that used git clone to install ansible, the lack of paramiko can lead to this warning.
I am not confortable with "A warning is just a warning" since you expect your playbooks to to run properly.

If you change the warning to something like: "Optional dependency 'cryptography' raised an exception, falling back to 'Crypto' (If 'cryptography' is installed maybe 'paramiko' is not, install 'paramiko' to remove this warning)" many users would understand that warning and take adequate measure.

@sivel here is a -vvvv run output:

$ ansible-playbook -vvvv  --version
 [WARNING]: Optional dependency 'cryptography' raised an exception, falling back to 'Crypto'

ansible-playbook 2.2.0.0 (stable-2.2 3a822faeae) last updated 2016/10/10 13:52:58 (GMT +200)
  lib/ansible/modules/core: (detached HEAD cf0c652a88) last updated 2016/10/10 13:59:31 (GMT +200)
  lib/ansible/modules/extras: (detached HEAD 6979330c1d) last updated 2016/10/10 13:59:31 (GMT +200)
  config file = /Users/renard/Src/ansible-dc/ansible.cfg
  configured module search path = Default w/o overrides

and my configuration file:

[defaults]
hostfile = inventory
ansible_managed = This file is managed by ansible. Any change would be overwritten.

[ssh_connection]
pipelining=True
control_path = %(directory)s/%%h-%%p

That's why I was a bit confused at the beginning since no traceback was displayed.

Yeah -- it only displays if you use debugging currently (ANSIBLE_DEBUG=1 ansible [...]) We've been talking about whether to unify verbosity and debugging under one umbrella for a while. That's a much bigger issue though.

The PR I've submitted above will display both the warning and the traceback with verbosity 4. Otherwise it will be silent. In this case, the APIs in cryptography vs Crypto have similar security so that's not really a problem. The Cryptography using code is faster but that doesn't affect most people (and definitely doesn't affect people who aren't using vault).

We can't bake in instructions for how to fix this because there are many reasons that importing cryptography could throw an exception and all of them ultimately go down this path.

@renard PR merged. You shouldn't see the warning with low verbosity levels. With high verbosity levels you should see both the warning and the traceback that can lead you to a diagnosis.

@abadger thanks but I don't see the backtrace even if I run it with -vvvv:

(ansible-dc) renard@scrat:~/Src/ansible-dc $ ansible-playbook   --version
ansible-playbook 2.2.0.0 (stable-2.2 4cd32ee1ac) last updated 2016/10/12 21:20:06 (GMT +200)
  lib/ansible/modules/core: (detached HEAD cf0c652a88) last updated 2016/10/12 21:23:05 (GMT +200)
  lib/ansible/modules/extras: (detached HEAD 6979330c1d) last updated 2016/10/12 21:23:05 (GMT +200)
  config file = /Users/renard/Src/ansible-dc/ansible.cfg
  configured module search path = Default w/o overrides
(ansible-dc) renard@scrat:~/Src/ansible-dc $ ansible-playbook -vvvv   --version
ansible-playbook 2.2.0.0 (stable-2.2 4cd32ee1ac) last updated 2016/10/12 21:20:06 (GMT +200)
  lib/ansible/modules/core: (detached HEAD cf0c652a88) last updated 2016/10/12 21:23:05 (GMT +200)
  lib/ansible/modules/extras: (detached HEAD 6979330c1d) last updated 2016/10/12 21:23:05 (GMT +200)
  config file = /Users/renard/Src/ansible-dc/ansible.cfg
  configured module search path = Default w/o overrides
(ansible-dc) renard@scrat:~/Src/ansible-dc $

Traced this to the fact that the module is imported before the command line is parsed. Thus we don't have a verbosity level yet. So the logic in vvvv() decides it shouldn't display anything.

It doesn't look like we can parse the command line for verbosity before we get to the point which is importing the vault code. So I think we may only have a choice of on or off here.. verbosity won't work.

@abadger ok fair enough.
Thanks for the quick fix.