As I said, other resources use that service, so it needs to be
configured immediately. If I make notifications delayed, the restart
will be after other recipes get executed and thus resources in those
other recipes won't be able to communicate with that service because
of it's misconfiguration.
Say, it's a web service and configuration files determine port and
credentials to communicate with that service. If those values will
change, but the service is not restarted, other recipes won't be able
to access it.
On Nov 7, 2011, at 22:01, Dmitry Zamaruev wrote:
Why not get rid of immediate suffix ?
In that case all :restart attempts will be grouped and service will be restarted only once. But not immediate, some where near to the end of recipe.
On Mon, 7 Nov 2011 21:58:11 +0400, Maxim Kulkin wrote:
Hi everybody,
I'm pretty new to Chef and would like assistance for the following problem.
I have a service and several configuration files for it. My other
recipes communicate with that service, so it should be configured and
ready to use before running them. I have following structure:
service 'myservice' do
action :nothing
end
template '/path/to/service/config1' do
...
notifies :restart, resources(:service => 'myservice'), :immediate
end
template '/path/to/service/config2' do
...
notifies :restart, resource(:service => 'myservice'), :immediate
end
service 'myservice' do
action [:start, :enable]
end
So, I want that if any of two configs change, the service is
restarted not later than the second "service" resource. But in
configuration that shown above, if both configs change, the service
will be restarted two times.
How would you solve this "the Chef-way" ?
After reading through Chef sources I've developed following solution.
I have a special resource -- "resource_group":
service 'myservice' do
action :nothing
end
resource_group 'myservice_configs' do
template '/path/to/service/config1' do
...
end
template '/path/to/service/config2' do
...
end
notifies :restart, resource(:service => 'myservice'), :immediate
end
service 'myservice' do
action [:start, :enable]
end
So, when it is defined, it records all resources (through
"method_missing" magic) that are created inside of it. The
resource_group resource itself is created after resources in it
(that's how Chef works). One resource_group's action triggers, it
checks embedded resources' #updated? method and if any resource was
updated, it set's it's own #updated_by_last_action to true (thus
triggering notifications).
What do you think about this solution? Maybe it could make it into Chef core?
Thanks,
Max
Archive powered by MHonArc 2.6.16.