converged_if_changed triggered on empty property

[chasebolt]

working_dir says it is being set to an empty string, though it is not defined as a property, causing converge_if_changed to run and updating the container. interesting bit is docker inspect shows the working_dir was not actually set to an empty string. expected result is docker run to immediately return with no action needed after the redeploy.

docker_image 'uchiwa/uchiwa' do
  notifies :redeploy, 'docker_container[uchiwa]', :immediately
end

docker_container 'uchiwa' do
  repo 'uchiwa/uchiwa'
  tag 'latest'
  port '3000:3000'
end

  * docker_image[uchiwa/uchiwa] action pull
    - Pull image uchiwa/uchiwa:latest
  * docker_container[uchiwa] action redeploy
    - create uchiwa
    -   set container_name              to "uchiwa" (default value)
    -   set repo                        to "uchiwa/uchiwa"
    -   set tag                         to "latest"
    -   set command                     to nil (default value)
    -   set cap_add                     to nil (default value)
    -   set cap_drop                    to nil (default value)
    -   set cgroup_parent               to "" (default value)
    -   set cpu_shares                  to 0 (default value)
    -   set cpuset_cpus                 to "" (default value)
    -   set devices                     to [] (default value)
    -   set dns                         to [] (default value)
    -   set dns_search                  to [] (default value)
    -   set domain_name                 to "" (default value)
    -   set entrypoint                  to nil (default value)
    -   set env                         to [] (default value)
    -   set extra_hosts                 to nil (default value)
    -   set exposed_ports               to {"3000/tcp"=>{}}
    -   set hostname                    to nil (default value)
    -   set ipc_mode                    to "" (default value)
    -   set labels                      to {} (default value)
    -   set links                       to nil (default value)
    -   set ip_address                  to nil (default value)
    -   set mac_address                 to nil (default value)
    -   set memory                      to 0 (default value)
    -   set memory_swap                 to 0 (default value)
    -   set network_disabled            to false (default value)
    -   set network_mode                to "bridge"
    -   set outfile                     to nil (default value)
    -   set port_bindings               to {"3000/tcp"=>[{"HostIp"=>"0.0.0.0", "HostPort"=>"3000"}]}
    -   set pid_mode                    to "" (default value)
    -   set privileged                  to false (default value)
    -   set publish_all_ports           to false (default value)
    -   set remove_volumes              to false (default value)
    -   set restart_maximum_retry_count to 0 (default value)
    -   set restart_policy              to nil (default value)
    -   set ro_rootfs                   to false (default value)
    -   set security_opts               to nil (default value)
    -   set signal                      to "SIGTERM" (default value)
    -   set sysctls                     to {} (default value)
    -   set tty                         to false (default value)
    -   set ulimits                     to nil (default value)
    -   set user                        to "" (default value)
    -   set userns_mode                 to "" (default value)
    -   set uts_mode                    to "" (default value)
    -   set volumes                     to {} (default value)
    -   set volumes_from                to nil (default value)
    -   set volume_driver               to nil (default value)
    -   set working_dir                 to "" (default value)
    -   set volumes_binds               to nil (default value)
    - starting uchiwa
  * docker_container[uchiwa] action run
    - deleting uchiwa
    - update uchiwa
    -   set working_dir to "" (was "/go/src/github.com/sensu/uchiwa")
    - starting uchiwa

[jondoe1337]

Can confirm this for the case that an ip_address is set.

In the recipe docker_container.rb there is already a workaround mentioned in line 151: # these are a special case for us because our names differ from theirs

We fixed it by adding the following lines after 155:

ip_address container.info['NetworkSettings']['Networks'][network_mode]['IPAMConfig']['IPv4Address'] if
  container.info['NetworkSettings'] &&
  container.info['NetworkSettings']['Networks'] &&
  container.info['NetworkSettings']['Networks'][network_mode] &&
  container.info['NetworkSettings']['Networks'][network_mode]['IPAMConfig']  &&
  container.info['NetworkSettings']['Networks'][network_mode]['IPAMConfig']['IPv4Address']

[s-bernard]

I confirm the ip_address bug which is very annoying.

[chasebolt]

ip_address bug should be resolved in v2.16.2

[jondoe1337]

Still happening with ip_address in version 4.2.0.

[vorezal]

Just in case anyone else finds this, it looks like the ip_address issue is due to the docker-api gem using a version of the docker Engine API that is too old and does not return anything for container.info['NetworkSettings']['Networks']. Until that is updated to at least 1.21 or different logic is included here to bypass the limitation setting a static ip address for docker containers will not be recognized on subsequent chef-client runs.

[rmoriz]

This also affects memory_swap and user when using chef-client v16. Interestingly it worked with chef 14 for unknown reasons (no re-creation of containers on each converge).