Run a recipe on another node

Chef Infra (archive)
1

Hi to all,
i have been searching for a way to make a recipe that is being run on one
node’s runlist trigger a recipe on another node/role runlist.

The closest thing to what I want to accomplish, according to opscode
documentation, is to “search” for all the nodes of a specific role, for
example, all nodes of role apache, and based on the nodes found execute what we
want, using an array with all of the nodenames.
The problem rises when, for example, continuing the new node configuration
requires that the other node(the one that uses the search method and creates
the array of nodes) must first be configured in order to continue the new node
configuration.
That could be accomplished either by creating a recipe that would execute
something on another node immediately (something like notify immediately
some_recipe on_another_node), or by executing immediately the runlist of the
other node before the completion of the running runlist of the new node and
returning the exit status so that it could continue configuration.
Of course there could be also more ways to do this.
But the question is: is anything like this possible? ChefServer version:10.12.0

Thanks!

2

Hi,
What about just failing in that case? With complex deployments the dependency graph will get pretty interesting and ensuring external configuration would only introduce mess all over the place.
This may not be acceptable in every case of course, but what I do is just verify whether all required information is available (via search(…)). If it isn’t, I raise an exception and stop before any resources get to run. Current node will sort itself out on the next run.

Regards,
Stanisław Pitucha
Cloud Services
Hewlett Packard

3

I'm as big a proponent of being able to do this as anyone but, as
Stanislaw said you have to be very careful about this. What you're
describing is what some folks refer to as orchestration.

One way to do it is described here -

(full disclosure: that's my presentation). Another way that might be a
bit more simple is to simply block the run until search returns a
valid result that you like and then continue.

But as much of an automation fiend as I am, I acknowledge that you
could, without very careful planning and guarding, trigger a nasty
unexpected chain of events.

On Mon, Aug 20, 2012 at 9:22 AM, jfotop ifot@forthnet.gr wrote:

Hi to all,
i have been searching for a way to make a recipe that is being run on one
node's runlist trigger a recipe on another node/role runlist.

The closest thing to what I want to accomplish, according to opscode
documentation, is to "search" for all the nodes of a specific role, for
example, all nodes of role apache, and based on the nodes found execute what we
want, using an array with all of the nodenames.
The problem rises when, for example, continuing the new node configuration
requires that the other node(the one that uses the search method and creates
the array of nodes) must first be configured in order to continue the new node
configuration.
That could be accomplished either by creating a recipe that would execute
something on another node immediately (something like notify immediately
some_recipe on_another_node), or by executing immediately the runlist of the
other node before the completion of the running runlist of the new node and
returning the exit status so that it could continue configuration.
Of course there could be also more ways to do this.
But the question is: is anything like this possible? ChefServer version:10.12.0

Thanks!

4

Hi all!

Is there a clever way to enforce the order in which service restarts get triggered on a chef-client run? Basically, I need keepalived to trigger (and complete) first before httpd reloads or restarts. Right now I have to do the restarts by hand. Any ideas would be greatly appreciated. Thanks!

Vincent Jorgensen
Operations Engineer @ Incentive Networks

5

by default the restarts are delayed until notified resource execution
happens (as specied in the recipe, run list), unless you specify
:immediately. Can you share the specific example?

On Fri, Oct 5, 2012 at 11:49 PM, Vincent Jorgensen <
vincent.jorgensen@incentivenetworks.com> wrote:

Hi all!

Is there a clever way to enforce the order in which service restarts get
triggered on a chef-client run? Basically, I need keepalived to trigger
(and complete) first before httpd reloads or restarts. Right now I have to
do the restarts by hand. Any ideas would be greatly appreciated. Thanks!

Vincent Jorgensen
Operations Engineer @ Incentive Networks

6

I meant to say that keepalived and haproxy are restarting out of order. Regardless, the problem is thus: keepalived gets a new configuration, which includes a new virtual ipaddress. haproxy gets the same ip address to add to it’s frontend listening directive. But when haproxy restarts first, the ip address interface doesn’t exist yet, so restart fails, which kills haproxy and all its running proxies. The first time I configure a new virtual ip, I have to manually restart keepalived so that haproxy can be properly restarted.

Vincent Jorgensen
Operations Engineer @ Incentive Networks
650.226.4917 PDT (GMT-0700)

On Oct 5, 2012, at 11:22 AM, Ranjib Dey wrote:

by default the restarts are delayed until notified resource execution happens (as specied in the recipe, run list), unless you specify :immediately. Can you share the specific example?

On Fri, Oct 5, 2012 at 11:49 PM, Vincent Jorgensen <vincent.jorgensen@incentivenetworks.commailto:vincent.jorgensen@incentivenetworks.com> wrote:
Hi all!

Is there a clever way to enforce the order in which service restarts get triggered on a chef-client run? Basically, I need keepalived to trigger (and complete) first before httpd reloads or restarts. Right now I have to do the restarts by hand. Any ideas would be greatly appreciated. Thanks!

Vincent Jorgensen
Operations Engineer @ Incentive Networks

7

I set keepalived to reload :immediately and that seems to solve my problem. Thanks!

Vincent Jorgensen
Operations Engineer @ Incentive Networks
650.226.4917 PDT (GMT-0700)

On Oct 5, 2012, at 11:44 AM, Vincent Jorgensen wrote:

I meant to say that keepalived and haproxy are restarting out of order. Regardless, the problem is thus: keepalived gets a new configuration, which includes a new virtual ipaddress. haproxy gets the same ip address to add to it’s frontend listening directive. But when haproxy restarts first, the ip address interface doesn’t exist yet, so restart fails, which kills haproxy and all its running proxies. The first time I configure a new virtual ip, I have to manually restart keepalived so that haproxy can be properly restarted.

Vincent Jorgensen
Operations Engineer @ Incentive Networks
650.226.4917 PDT (GMT-0700)

On Oct 5, 2012, at 11:22 AM, Ranjib Dey wrote:

by default the restarts are delayed until notified resource execution happens (as specied in the recipe, run list), unless you specify :immediately. Can you share the specific example?

On Fri, Oct 5, 2012 at 11:49 PM, Vincent Jorgensen <vincent.jorgensen@incentivenetworks.commailto:vincent.jorgensen@incentivenetworks.com> wrote:
Hi all!

Is there a clever way to enforce the order in which service restarts get triggered on a chef-client run? Basically, I need keepalived to trigger (and complete) first before httpd reloads or restarts. Right now I have to do the restarts by hand. Any ideas would be greatly appreciated. Thanks!

Vincent Jorgensen
Operations Engineer @ Incentive Networks

8

On Fri, Oct 5, 2012 at 2:44 PM, Vincent Jorgensen
vincent.jorgensen@incentivenetworks.com wrote:

I meant to say that keepalived and haproxy are restarting out of order.
Regardless, the problem is thus: keepalived gets a new configuration, which
includes a new virtual ipaddress. haproxy gets the same ip address to add to
it's frontend listening directive. But when haproxy restarts first, the ip
address interface doesn't exist yet, so restart fails, which kills haproxy
and all its running proxies. The first time I configure a new virtual ip, I
have to manually restart keepalived so that haproxy can be properly
restarted.

What's sending the notification to them to restart? You could notify
keepalived to restart and have it notify haproxy to restart.

If you every want to restart keepalived without restarting haproxy,
you could have a separate resource like this:

service "keepalived" do
service_name "keepalived"
action [ :start, :enabled]
end

service "keepalived_haproxy" do
service_name "keepalived"
notified :restart, "service[haproxy]"
end

Bryan