Stop service / config file change / start service

Sorry if this is covered elsewhere, but I’m wondering if there is/shouldn’t be a way to stop a service before making config file changes, rather than restarting afterwards.

An example is networking: I want to stop it using the old config and then start it with the new config. Otherwise, it gets confused because the number of interfaces may have changed. Doing a stop with the new config file is not the same thing as doing a stop with the old config.

Unless there’s another/better way to do this …

Hello!

On Thu, Jul 14, 2011 at 12:22 PM, Steven Parkes smparkes@smparkes.net wrote:

Sorry if this is covered elsewhere, but I'm wondering if there is/shouldn't be a way to stop a service before making config file changes, rather than restarting afterwards.

An example is networking: I want to stop it using the old config and then start it with the new config. Otherwise, it gets confused because the number of interfaces may have changed. Doing a stop with the new config file is not the same thing as doing a stop with the old config.

Unless there's another/better way to do this ...

Sure, you can reuse the same named resource and send it multiple
actions. You'll want a conditional that wraps the recipe so it doesn't
occur (stop networking) unless necessary). For example, we do this in
the mysql::server_ec2 recipe to move the data directory of MySQL to
ephemeral storage (or an EBS volume depending on the attribute
setting)

Though for networking I'd want to be very careful about how this is
handled as it may be ...problematic if there's an error.

--
Opscode, Inc
Joshua Timberman, Director of Training and Services
IRC, Skype, Twitter, Github: jtimberman

Thanks for the reply.

Two comments:

First and foremost, as you mention, the networking case is problematic in other ways. Thinking about it a little bit more, the issue seems to be more about correlating the existing interfaces in the kernel with the config as chef sees it. The config comes from multiple places, primarily /etc/networking/interfaces but also heartbeat. That correlation seems pretty complex and I'm not sure how to address it with chef, if it's possible. A configuration change can cause removal/creation of virtual interfaces. Adding an interfaces doesn't seem too hard but removing one does, since I'd have to have code that knew how many interfaces there were in the old config. Or am I missing something?

Second, as to the example you gave, the part that differs from what I was looking for is that I was hoping for a mechanism that would use the built-in file diffing to determine/coordinate the shutdown/restart.

On Jul 14, 2011, at 11:26 PM, Joshua Timberman wrote:

Hello!

On Thu, Jul 14, 2011 at 12:22 PM, Steven Parkes smparkes@smparkes.net wrote:

Sorry if this is covered elsewhere, but I'm wondering if there is/shouldn't be a way to stop a service before making config file changes, rather than restarting afterwards.

An example is networking: I want to stop it using the old config and then start it with the new config. Otherwise, it gets confused because the number of interfaces may have changed. Doing a stop with the new config file is not the same thing as doing a stop with the old config.

Unless there's another/better way to do this ...

Sure, you can reuse the same named resource and send it multiple
actions. You'll want a conditional that wraps the recipe so it doesn't
occur (stop networking) unless necessary). For example, we do this in
the mysql::server_ec2 recipe to move the data directory of MySQL to
ephemeral storage (or an EBS volume depending on the attribute
setting)

Though for networking I'd want to be very careful about how this is
handled as it may be ...problematic if there's an error.

--
Opscode, Inc
Joshua Timberman, Director of Training and Services
IRC, Skype, Twitter, Github: jtimberman

On Fri, Jul 15, 2011 at 7:12 AM, Steven Parkes smparkes@smparkes.net wrote:

Second, as to the example you gave, the part that differs from what I was looking for is that I was hoping for a mechanism that would use the built-in file diffing to determine/coordinate the shutdown/restart.

I would use notification between the resources for handling that kind
of relationship.

http://wiki.opscode.com/display/chef/Resources#Resources-Notifications

--
Opscode, Inc
Joshua Timberman, Director of Training and Services
IRC, Skype, Twitter, Github: jtimberman

I would use notification between the resources for handling that kind
of relationship.

Sorry, did I miss something? I can see how to perform an action after a change with :notifies, but I don't see how to perform an action before the change and only in the case where a change is going to occur.

Do you have a service that check configuration file on every operation
(stop/start/restart)?

I think you will need first a separate configuration file (just a copy),
and play with several resources with notifications/subscribers to
establish exact order of execution:

  • if file changed - stop service, copy file to required config, start
    service

On 7/15/11 6:33 PM, Steven Parkes wrote:

I would use notification between the resources for handling that kind
of relationship.
Sorry, did I miss something? I can see how to perform an action after a change with :notifies, but I don't see how to perform an action before the change and only in the case where a change is going to occur.

--
Vladimir Girnet
Infrastructure Engineer
Tacit Knowledge

I think you will need first a separate configuration file (just a copy),
and play with several resources with notifications/subscribers to
establish exact order of execution:

  • if file changed - stop service, copy file to required config, start
    service

I think this will break the idempotency of chef: if the "real" file gets changed but the copy doesn't, it'll think it's in sync.