RE: Re: RE: Re: Docker_container dependency hell

I love your workaround, although for a somewhat different purpose! That’s pure genius.

If I use action :nothing, then everything works as expected, but if the image or container are missing, they won’t be rebuilt.

Your workaround might come in handy to trigger a notification if the image or container are missing.

So thank you!

Kevin Keane

The NetTech

http://www.4nettech.com

Our values: Privacy, Liberty, Justice

See https://www.4nettech.com/corp/the-nettech-values.html

-----Original message-----
From: Tensibai tensibai@iabis.net
Sent: Tuesday 8th September 2015 0:53
To: chef@lists.opscode.com
Subject: [chef] Re: RE: Re: Docker_container dependency hell

Re reading your recipe, why does it not deploy with action :nothing ? as the subscription are done to the images where you say there’s a build by notification already, you should already have the full notification path building things in the correct order at end of chef run.

My workaround when I wish to control a chain of notification on a first pass is something like this:

if !node.tagged?(‘first_pass’) {

log “First pass notifications” do

notifies :run,"execute[Y]"

notifies :start,"service[Z]"

end

node.tag(‘first_pass’)

}

This is not ideal as it leave dead code on the long term run, but it’s useful in some of my cases (db creations, initial replication, etc.)

Le 2015-09-07 23:17, Kevin Keane Subscription a écrit :

Thank you! Wouldn’t this solution do the action the first time the resource is encountered? At that point, the prerequisites aren’t necessarily all met yet.

What I’d need is the action to be run after the last notification. Thus using delayed vs immediate.

Kevin Keane

The NetTech

http://www.4nettech.com

Our values: Privacy, Liberty, Justice

See https://www.4nettech.com/corp/the-nettech-values.html

-----Original message-----
From: Tensibai tensibai@iabis.net
Sent: Monday 7th September 2015 1:18
To: chef@lists.opscode.com
Subject: [chef] Re: Docker_container dependency hell

Remarks inline

Here is what I am currently doing (simplified for readability)

docker_image image1 do

action :nothing

built only based on notifications

end

docker_container container2 do

action :run_if_missing

subscribe :redeploy, “docker_image[image2]”

end

And in another cookbook:

docker_image image2 do

action :nothing

built only based on notifications

end

docker_container container1 do

action :run_if_missing

subscribe :redeploy, "docker_image[image1]

subscribe :redeploy, "docker_container[container2]

end

Problems with this approach:

  • The containers are often built twice, first by the run_if_missing action, and then again by the redeploy action

  • The run_if_missing action does not observe dependencies, so container1’s run_if_missing action is actually invoked before container2 even exists, causing a build failure.

Don’t you have a problem in your recipes order ? Out of notifications, you should ensure the run_list is coherent with the timeline of your provisionning, if the container2 was before container1 in the resource appearance order, it will be built before.

Another option could be to set a flag ‘already_run’ to define the subscribe attributes’ only after first run, something along:

docker_container container1 do

action :run_if_missing

subscribe :redeploy, "docker_image[image1] if node.tagged?(‘flag’)

subscribe :redeploy, "docker_container[container2] if node.tagged?(‘flag’)

end

At end of recipe (could be improved to handle failure by doing it in a ruby_block and using notifications.)

node.tag(‘flag’) # Flag could be generic or something named by container for a more precise approch

Obviously, I could circumvent this by changing the default action to :nothing, but then the containers aren’t built at all if they are missing.

Also, using :immediate for the subscriptions is not an option (because then the redeploy action may get invoked too early and multiple times, and various other problems).

What is the best way to resolve this?