New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

problems with improperly labelled containers in context #7

Closed
aeri4list opened this Issue Feb 15, 2017 · 6 comments

Comments

Projects
None yet
2 participants
@aeri4list

aeri4list commented Feb 15, 2017

Adding deck-chores on a node with several services running, one of which was an old instance of dnsmasq, resulted in the same error reported in closed issue #2.
Upon further inspection we discovered that the dnsmasq container was configured with labels:None, removing it solved the problem.
Maybe it's about how legacy stuff from the time when labels were not available is handled in Docker?

@funkyfuture

This comment has been minimized.

Owner

funkyfuture commented Feb 15, 2017

thanks for reporting.

if you can't submit a a patch, the following would be helpful:

  • a snippet of the container inspection with the labels
  • the traceback of the incident

@funkyfuture funkyfuture added the bug label Feb 15, 2017

@funkyfuture funkyfuture added this to the 0.1 milestone Feb 15, 2017

@aeri4list

This comment has been minimized.

aeri4list commented Feb 15, 2017

Ubuntu 16.04.1 LTS,
Docker version is 1.13.0, build 49bf474

Here's a bit from the logs, sorry I don't have a full traceback.
Having removed dnsmask from the node I can't do any useful inspection anymore, but I'll try and whip up some sort of proof and/or a patch this week

Feb 14 17:16:37 9b064da82fb7 annunci2013_crond_1:  2017-02-14 16:02:53,606|ERROR   |Caught unhandled exception:  
Feb 14 17:16:37 9b064da82fb7 annunci2013_crond_1:  2017-02-14 16:02:53,606|ERROR   |'NoneType' object has no attribute 'get'  
Feb 14 17:16:37 9b064da82fb7 annunci2013_crond_1:  Traceback (most recent call last):  
Feb 14 17:16:37 9b064da82fb7 annunci2013_crond_1:    File "/usr/local/lib/python3.6/site-packages/deck_chores-0.1b3-py3.6.egg/deck_chores/main.py", line 182, in main  
Feb 14 17:16:37 9b064da82fb7 annunci2013_crond_1:      if there_is_another_deck_chores_container():   
Feb 14 17:16:37 9b064da82fb7 annunci2013_crond_1:    File "/usr/local/lib/python3.6/site-packages/deck_chores-0.1b3-py3.6.egg/deck_chores/main.py", line 35, in there_is_another_deck_chores_container   
Feb 14 17:16:37 9b064da82fb7 annunci2013_crond_1:      if labels.get('org.label-schema.name', '') == 'deck-chores':   
Feb 14 17:16:37 9b064da82fb7 annunci2013_crond_1:  AttributeError: 'NoneType' object has no attribute 'get'
@funkyfuture

This comment has been minimized.

Owner

funkyfuture commented Feb 28, 2017

i added another solution to the master tree, the commit is referenced before the comment. the build is available as funkyfuture/deck-chores:dev on the docker registry. can you have a look at it?

@aeri4list

This comment has been minimized.

aeri4list commented Mar 1, 2017

Sure, I'll test with or current context and then try reintroducing the problematic value excplicitly in the .yml. Either that or using a pre 1.6 Docker (labels support) and then an up to date version on the same virtual machine. Sorry I'm taking so long to even respond, your patch looks way saner than mine btw

@aeri4list

This comment has been minimized.

aeri4list commented Mar 1, 2017

No regressions with the usual conf (Ubuntu 16.04.1 LTS, Docker 1.13.0, build 49bf474, docker-compose 1.10.0, build 4bd6f1a) building from this repo instead of pulling the image from docker hub, just saw your note about the dev tagged release...
I found what could be a useful reference in docker-compose's doc which made me skip testing with different versions of docker-compose, moved backwards with docker versions until 1.8.0, no problems yet.
Using Docker 1.5.0 breaks compatibility with docker-compose, it seems.
This is probably about a specific upgrade pattern combining some docker and docker-compose versions.

@funkyfuture

This comment has been minimized.

Owner

funkyfuture commented Mar 1, 2017

thanks a lot for your effort! that makes the 0.1 release ready. 🚀 i guess this will happen until the weekend.

as far as i investigated the docker-py code, and given i understood the circumstances correctly, i would say the issue was caused by the fact that docker-engine returns a null value for the Labels property on inspection of a container that was created with a Docker version prior to the labels feature.

an unrelated question out of curiosity: how did you become aware of this project?

@funkyfuture funkyfuture closed this Mar 1, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment