On Wed, Aug 15, 2012 at 11:00 PM, Steve Bennett stevage@gmail.com wrote:
But apparently it doesn't. In that case:
- what is the purpose of the "restart_command" etc parameters? How are
they used, if not to write to a script in init.d/?
It is important to understand that there is a one to many relationship
between resources and providers. Resources define something you want
to manage, and then providers take the action of managing that
resource on the system.
http://wiki.opscode.com/display/chef/Resources+and+Providers
There's a bit of presumption in wondering why something is not done in
init.d as that is part of a particular service management system,
albeit a historical one that is an ancestor of many newer
implementations.
Based on your platform and platform version, Chef makes default
guesses as to what provider you want for each resource based on what
it the default or most popular on that platform. For example, the
package resource on Debian uses apt and on Redhat it uses yum. You can
override these if you're using a different provider than the default
using the provider meta attribute. [1]
The init.d script is actually part of the init system. Other service
providers may have configuration files instead of scripts that you can
run by hand, such as upstart. The service resource has a number of
actions that are quite concrete in meaning, start, enable, etc, and we
try to avoid overloading those actions. If you imagine a
start_and_create_unless_exists action, then you've mixed two
resources; you're creating a file, and managing an service. Thus, Chef
operates at a level where if you need the file to be created, you use
a file resource or subclass such as remote_file or template. Then you
use the service resource to manage the service alone.
- what's the purpose of "supports" parameter - what does Chef do with it?
This is most commonly needed with the traditional SysVinit system.
There's no requirement as to what actions this system can perform, but
start and stop are the defacto requirement. Some init scripts have a
restart or status function, but there's no concise way to tell if they
do so we depend on the user defining the service resource to be clear
about that functionality. If the script has a restart function, it's
likely the best way to restart the daemon. If it doesn't, we'll just
try to stop and start the daemon. If it has a status function, that's
likely to be much more accurate than chef having to run ps and trying
to find the daemon, which could result in something else being
inadvertently affected.
http://wiki.opscode.com/display/chef/Resources#Resources-Service
- what's the best way to create services? Foreman? A template as
suggested in that thread?
Usually a cookbook_file, unless you need to make any dynamic choices
in it like configuring where the configuration file is, in which case
a template [2].
- any plans to make the service resource do this?
No, because that would overload the service resource by making it
manage both files and services.
Consider configuring an apt repository. You need to put a file in
there, run apt-get update, and then install the package. These are
three separate distinct actions. While we could modify the apt
provider to take a new repository as an attribute and do all this in a
single provider, it is a much cleaner (maintainable, understandable,
less magic) design to use another mechanism to do all three of these
together when needed. The example of this is the apt_repository LWRP.
https://github.com/opscode-cookbooks/apt/blob/master/providers/repository.rb
Parts of this concept of primitives are discussed in a recent video
Opscode put up talking about the history of Chef:
If you think about unix commands and the ability to chain small
commands that do one distinct thing well together to perform many more
complex tasks, you'll see the example we're following.
Another relevant and more humorous example is Zawinski's law: "Every
program attempts to expand until it can read mail. Those programs
which cannot so expand are replaced by ones which can."
- could the docs be made a bit more explicit?
Maybe. The devil is in the details of the actions; there is no create
action, just start, manage, etc. I suppose you could add a note along
the lines of "The service resource will not create a resource, it must
already exist to be managed." The trick is putting this note somewhere
everyone will see.
Bryan
[1] http://wiki.opscode.com/display/chef/Resources#Resources-CommonAttributes
[2] https://github.com/opscode-cookbooks/nagios/blob/master/templates/default/nagios-nrpe-server.erb#L33
