Ansible: docker-py version is checked incorrectly

[rcoh]

ISSUE TYPE

• Bug Report

COMPONENT NAME

docker integration (but not the docker module) (https://github.com/ansible/ansible/blob/devel/lib/ansible/module_utils/docker_common.py#L154)

ANSIBLE VERSION

ansible 2.1.1.0

CONFIGURATION

None

OS / ENVIRONMENT

OS X, El Cap

SUMMARY

docker-py just bumped its version to 1.10. This is the code that checks the version:

  154         if docker_version < MIN_DOCKER_VERSION:
  155             self.fail("Error: docker-py version is %s. Minimum version required is %s." % (docker_version,
  156      

This is how python compares strings:

>>> "1.5" < "1.7"
True
>>> "1.9" < "1.7"
False
>>> "1.10.1" < "1.7"
True
>>> "1.10.1" < "1.7.0"
True
>>> "1.10" < "1.7.0"
True

STEPS TO REPRODUCE

1. Install latest docker-py on target machine.
2. Run any docker command:

docker_service:
   ...

EXPECTED RESULTS

Run docker

ACTUAL RESULTS

fatal: [demos]: FAILED! => {"changed": false, "failed": true, "msg": "Error: docker-py version is 1.10.1. Minimum version required is 1.7.0."}

[rcoh]

See also https://github.com/docker/docker-py/issues/1200#issuecomment-246076049

[shane-axiom]

Confirmed, Debian Jessie. Seems...urgent.

[shane-axiom]

Note that docker-compose 1.8.0 requires docker-py >1.9,<2.0, so if you're specifically setting docker-py to a version lower than 1.9.0 and installing docker-compose 1.8.0 it will upgrade docker-py all the way to 1.10.1 which presently breaks the string version comparison. Set docker-py to 1.9.0 prevent this.

[rcoh]

Most people using the normal galaxy package for docker will be getting the
latest version by default -- could definitely break a lot of stuff

On Fri, Sep 9, 2016, 7:09 PM Shane StClair [email protected] wrote:

Note that docker-compose 1.8.0 requires docker-py >1.9,<2.0, so if you're
specifically setting docker-py to a version lower than 1.9.0 and installing
docker-compose 1.8.0 it will upgrade docker-py all the way to 1.10.1 which
presently breaks the string version comparison. Set docker-py to 1.9.0
prevent this.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/ansible/ansible/issues/17495#issuecomment-246081820,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAeFZ-OYb5eZHpd8TFlSrX7Z9WimPuIwks5qohE9gaJpZM4J5lx9
.

[nictuku]

FWIW, I'm not setting docker-py to any specific version and this broke me anyway.

[juanluisbaptiste]

Yup, I can confirm it on Ubuntu 16.04.

[kiview]

Does a temporary workaround exist?

[rcoh]

A downgrade of docker-py to 1.9.0 is probably the easiest

On Mon, Sep 12, 2016, 7:59 AM Kevin Wittek [email protected] wrote:

Does a temporary workaround exist?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/ansible/ansible/issues/17495#issuecomment-246375443,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAeFZ0KPLl-PYEN80CH6YRvAwuVekYq1ks5qpWjLgaJpZM4J5lx9
.

[vietbui]

@kiview
In case you use pip to install docker-py:
pip install 'docker-py==1.9.0'
Or if version 1.10.1 has already been installed:
pip install 'docker-py==1.9.0' --force-reinstall

[kiview]

@vietbui Thanks, even worked by specifying a specific docker-py version in the angstwad.docker_ubuntu role.

[jhita]

Hello guys, when are you going to release a new version with this change merged? Are you planning to do it soon? Thanks!

[trennepohl]

Facing this issue as well
fatal: [localhost]: FAILED! => {"changed": false, "failed": true, "msg": "Error: docker-py version is 1.10.3. Minimum version required is 1.7.0."}

Downgraded docker-py as suggested by @vietbui and it's working!

In case you use pip to install docker-py:
pip install 'docker-py==1.9.0'
Or if version 1.10.1 has already been installed:
pip install 'docker-py==1.9.0' --force-reinstall

[jaccoh]

I thought this would be fixed in 2.1.2.0 but I tried today:
"Error: docker-py version is 1.10.3. Minimum version required is 1.7.0."

This is, in my opinion, an urgent problem!

[dhdanno]

I received errors with various versions of docker-compose and docker-py, in the end i settled on
docker-compose(1.8.1) and docker-py(1.7.0) on my client. No more errors and my docker-compose.yml is being consumed properly. Ansible version is 2.1.2.0

[Sispheor]

+1 !!
"Error: docker-py version is 1.10.3. Minimum version required is 1.7.0."}

On Ubuntu 16.04

ansible --version
ansible 2.1.1.0

Edit: same with 2.1.2.0

[sochoa]

Why not do something like this?

(Pdb) '1.10.0' > '1.7.0'
False
(Pdb) [int(i) for i in '1.10.0'.split('.')] > [int(i) for i in '1.7.0'.split('.')]
True

That comparison works:

/usr/lib/python2.7/dist-packages/ansible/module_utils/docker_common.py

154         if [int(i) for i in docker_version.split('.')] < [int(i) for i in MIN_DOCKER_VERSION.split('.')]:
155             self.fail("Error: docker-py version is %s. Minimum version required is %s." % (docker_version,
156                                                                                            MIN_DOCKER_VERSION))

[jaccoh]

LooseVersion works fine. It's just that this single line patch wasn't committed to 2.1 branch ..

Op 6 okt. 2016 om 02:32 heeft Sean Ochoa [email protected] het volgende geschreven:

Why not do something like this?

(Pdb) '1.10.0' > '1.7.0'
False
(Pdb) [int(i) for i in '1.10.0'.split('.')] > [int(i) for i in '1.7.0'.split('.')]
True
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

{"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/ansible/ansible","title":"ansible/ansible","subtitle":"GitHub repository","main_image_url":"https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png","avatar_image_url":"https://cloud.githubusercontent.com/assets/143418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.png","action":{"name":"Open in GitHub","url":"https://github.com/ansible/ansible"}},"updates":{"snippets":[{"icon":"PERSON","message":"@sochoa in #17495: Why not do something like this? \r\n\r\n\r\n(Pdb) '1.10.0' \u003e '1.7.0'\r\nFalse\r\n(Pdb) [int(i) for i in '1.10.0'.split('.')] \u003e [int(i) for i in '1.7.0'.split('.')]\r\nTrue\r\n"}],"action":{"name":"View Issue","url":"https://github.com/ansible/ansible/issues/17495#issuecomment-251837619"}}}

[Sispheor]

@sochoa It works with your fix. I've updated the file manually.
I'll keep an eye on this issue for an official patch.

[markusthoemmes]

Facing the same issue. Any ETA on the official release this will be included in?

[lukasged]

I'm having the same issue, thought that it would be resolved in the 2.1.2 version, but it's still there. Will it be resolved in 2.2.0 ?

[burdiyan]

I still have this issue with ansible 2.1.2.0

[gfarrell]

Also having this problem in ansible 2.1.2.0 which means one of my servers was stopped and not restarted

[nvkv]

Same problem here, 2.1.2.0

[anthonyhaussman]

Will be fix on Ansible 2.2.0. :(

[anthonyhaussman]

You can manually patch the file lib/ansible/module_utils/docker_common.py :
https://github.com/ansible/ansible/pull/17496/files

[ReSearchITEng]

Due to number of people affected, looks like an issue which deserves a quick fix (as opposite to waiting for next release).
Automated systems fail and the only solution is to manually fix across the infrastructure - not what we expect from an ansible module.

[gvilarino]

Is there going to be a patch release for 2.1 with the fix soon? Seriously, this is a breaking bug, we shouldn't be waiting for a minor release =/

[lukasged]

Finally I had to force the installation of docker-py==1.9.0 in our Continous Integration pipelines for the automated deployment to work. I hope that there's a fix for 2.1 soon or a quicker release of 2.2

[gfarrell]

This is what patch versions are for, the fix should have been included in an updated release much faster! I've patched docker_common.py as per the above comment and it worked (although it's not straightforward to find in a homebrew installation).

On Fri, Oct 14, 2016 at 8:55 PM +0100, "lukasged" [email protected] wrote:

Finally I had to force the installation of docker-py==1.9.0 in our Continous Integration pipelines for the automated deployment to work. I hope that there's a fix for 2.1 soon or a quicker release of 2.2

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

[zx1986]

I got the same error too :-(

- pip: name=docker-py version=1.9.0 state=forcereinstall
  when: upgrade_pip | success

- pip: name=docker-compose state=latest
  when: upgrade_pip | success

and the docker-compose task will force to install latest docker-py ...

[lawliet89]

I believe v2.2.0.0-0.1.rc1 fixes this.

As a workaround, you can install RC1: pip install git+https://github.com/ansible/[email protected]

[xzvfinet]

I realized that devel branch is represented as 2.3.0(through pip show ansible)
This issue is fixed in that branch too.

[nitzmahone]

This change has been backported to stable-2.1 for 2.1.3RC3. Will backport to stable-2.2 if there's another 2.2.0 release candidate, otherwise, it should be in for 2.2.1.

[markusthoemmes]

nice @nitzmahone, exactly what most of us are looking for :+1:

[splitice]

👍

[nitzmahone]

... aaand there's going to be a 2.2.0RC4, so this one's been cherry-picked to go along for the ride.

[Asher256]

+1

[dbrgn]

Looks like ansible 2.2.0 is out, which fixes this issue. Right?

[lukasged]

@dbrgn Right! That's great, although switching to ansible 2.2.0 gave me another problem. It seems to break one popular ansible galaxy role for mysql . So be careful if you use that role.

[dbrgn]

Yeah, and 2.2 seems to break docker_service too :face_with_head_bandage: https://github.com/ansible/ansible-modules-core/pull/5159

[jaccoh]

Right

Op 3 nov. 2016 om 23:55 heeft lukasged [email protected] het volgende geschreven:

@dbrgn Right! That's great, although switching to ansible 2.2.0 gave me another problem. It seems to break one popular ansible galaxy role for mysql . So be careful if you use that role.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

{"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/ansible/ansible","title":"ansible/ansible","subtitle":"GitHub repository","main_image_url":"https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png","avatar_image_url":"https://cloud.githubusercontent.com/assets/143418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.png","action":{"name":"Open in GitHub","url":"https://github.com/ansible/ansible"}},"updates":{"snippets":[{"icon":"PERSON","message":"@lukasged in #17495: @dbrgn Right! That's great, although switching to ansible 2.2.0 gave me another problem. It seems to break one popular ansible galaxy role for mysql . So be careful if you use that role."}],"action":{"name":"View Issue","url":"https://github.com/ansible/ansible/issues/17495#issuecomment-258298370"}}}

[gvilarino]

It's honestly awe-striking how fragile ansible is as an environment and the amount of effort it demands its users for keeping basic functionalities working with just a minor upgrade. Remarkable.

[darkn3rd]

Not able to verify fix in Ansible 2.2 as it breaks for another reason on Mac OS X:

Traceback (most recent call last):\n  File \"/var/folders/79/4dttv20s6p30d78_yqmr3jjh0000gn/T/ansible_c_jdw536/ansible_module_docker_container.py\", line 652, in <module>\n    from ansible.module_utils.docker_common import *\n  File \"/var/folders/79/4dttv20s6p30d78_yqmr3jjh0000gn/T/ansible_c_jdw536/ansible_modlib.zip/ansible/module_utils/docker_common.py\", line 26, in <module>\nImportError: No module named 'urlparse'\n

[abadger]

Because this ticket is closed, no one is likely to see comments on it. Please open a new ticket if you are having issues.

@darkn3rd -- it looks like your problem is an incompatibility between the docker_common.py command and python3 on the managed machine. Workaround would be to run with python2. I'll look at making a PR for the python3 problem.