docker: AttributeError: 'module' object has no attribute 'DEFAULT_DOCKER_API_VERSION'

[tehranian]

Issue Type: Bug Report

Ansible Version:

$ ansible --version
ansible 1.9.0.1
  configured module search path = None

Environment:

Running on Mac OS to manage an Ubuntu 14.04 VM.

Summary:

The new version 1.2.1 of the "docker-py" module seems to have removed the "docker.client.DEFAULT_DOCKER_API_VERSION" variable that Ansible was using.

FWIW - It looks like this 1.2.1 release of "docker-py" just came out today, 4/29/15. See: https://pypi.python.org/pypi/docker-py.

And here's a link to the diff on "docker-py" where @shin- removed "docker.client.DEFAULT_DOCKER_API_VERSION":
docker/docker-py@ae329cb

And the new "docker.constants" file where this variable was moved to:
https://github.com/docker/docker-py/blob/ae329cb3acb3ff38bd986215c99b1136a6183f78/docker/constants.py#L1

TASK: [apt-cacher-ng | Run the extellisys/apt-cacher-ng Docker container] *****
failed: [default] => {"failed": true, "parsed": false}
BECOME-SUCCESS-ldprfowyxhdsqcsgmtrqpvirszzgajwq
Traceback (most recent call last):
  File "/home/vagrant/.ansible/tmp/ansible-tmp-1430328017.67-135370415083178/docker", line 3104, in <module>
    main()
  File "/home/vagrant/.ansible/tmp/ansible-tmp-1430328017.67-135370415083178/docker", line 1449, in main
    manager = DockerManager(module)
  File "/home/vagrant/.ansible/tmp/ansible-tmp-1430328017.67-135370415083178/docker", line 558, in __init__
    docker_api_version=docker.client.DEFAULT_DOCKER_API_VERSION
AttributeError: 'module' object has no attribute 'DEFAULT_DOCKER_API_VERSION'

If I downgrade my "docker-py" to the previous 1.1.0 release, the Ansible operation completes successfully.

Steps To Reproduce:

Pretty basic use of Ansible's "docker" module:

- name: apt-cacher-ng | Run the extellisys/apt-cacher-ng Docker container
  docker:
    image=extellisys/apt-cacher-ng
    name=apt-cacher-ng
    ports="{{ apt_cache_server_port }}:3142"
    volumes="{{ apt_cache_server_dir }}:/var/cache/apt-cacher-ng"

Again, this issue occurs when "docker-py" is 1.2.1 and not when "docker-py" is 1.1.0.

Expected Results:

I expect Ansible's "docker" module to work correctly.

Actual Results:

TASK: [apt-cacher-ng | Run the extellisys/apt-cacher-ng Docker container] *****
failed: [default] => {"failed": true, "parsed": false}
BECOME-SUCCESS-ldprfowyxhdsqcsgmtrqpvirszzgajwq
Traceback (most recent call last):
  File "/home/vagrant/.ansible/tmp/ansible-tmp-1430328017.67-135370415083178/docker", line 3104, in <module>
    main()
  File "/home/vagrant/.ansible/tmp/ansible-tmp-1430328017.67-135370415083178/docker", line 1449, in main
    manager = DockerManager(module)
  File "/home/vagrant/.ansible/tmp/ansible-tmp-1430328017.67-135370415083178/docker", line 558, in __init__
    docker_api_version=docker.client.DEFAULT_DOCKER_API_VERSION
AttributeError: 'module' object has no attribute 'DEFAULT_DOCKER_API_VERSION'

[sivel]

This is a both a dupe of ansible/ansible-modules-core#1227 and reported in the wrong repository.

[diefans]

shouldn't there be a version pin - to stay safe on dependency changes?

[settinghead]

+1

[varsy]

This works as a workaround:

  tasks:
    - name: Install docker-py
      pip: name=docker-py version=1.1.0

[abadger]

@diefans: If you mean a pin as in a pip or setup.py requirement on a certain version it won't work. Those would manage the versions of packages on the local machine but the modules run on the remote machine.

@varsy thanks for posting the workaround!

Closing as a duplicate of ansible/ansible-modules-core#1227

[diefans]

@abadger I mean, since ansible and all its modules rely on certain dependencies resp. their destinct versions, there should be means to fix and ensure that relationship. IMHO all dependencies as far as it is possible should be separated from the rest of the provisioned content. When I provision my system, by installing components and they install dependencies, which are and can change ansible dependencies, you may end in a situation, where the provisioning may corrupt ansibles behaviour in terms of predictability and repeatability.

So I think the fix of ansible/ansible-modules-core#1227 solves the actual situation but does nothing about the real problem.

In a serious project (at least in my experience) you pin your dependencies to concrete versions, because that relationship went successfully through your testing, you are not able to make any statements about other versions combinations and a possible corruption of your assertions - it is just untested.

[abadger]

@diefans, I think your analysis is wrong in that it doesn't make the distinction between system-level software and in-house software (need better terms but this is the wrong place to have a discussion). If you'd like to take this to the mailing list we can discuss it further there.

[settinghead]

Thanks @varsy! Your workaround worked for me.

[stefanteixeira]

@varsy the workaround worked nicely here too. Thank you! :)

[senorsmile]

I have a linux host and a mac host BOTH still with docker-py 1.1.0 getting this same error. I could swear it worked just fine a couple of weeks ago (possibly with ansible 1.8?). I reinstalled ansible 1.8.4 and get the same error :(. Tried the same with 1.9 and got the same thing.

[bsodmike]

Thanks @varsy worked here too 👍

[senorsmile]

Finally have this working... I didn't realize that the ansible role I was using to install docker on the remote machine was ensuring it to be latest through pip... so even though I would uninstall it, and reinstall like:
pip install docker-py==1.1.0
it would always end up back at 1.2.x.