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 < >
Sent: Tuesday 8th September 2015 0:53
To:
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 < >
Sent: Monday 7th September 2015 1:18
To:
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?
Archive powered by MHonArc 2.6.16.