[chef-dev] Re: [chef] Resource groups

[Daniel DeLeo < >]

On Monday, November 7, 2011 at 9:58 AM, 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

This is the same solution I came up with to the problem: 
http://tickets.opscode.com/browse/CHEF-2452

I think resource groups are actually useful for several things:
* better control over notifications
* failure zones: allow a group to fail without stopping the Chef run
* customizing recipes: include_recipe could be extended so that only certain 
groups from a recipe are included. Also, groups could be overridden by a user 
of the recipe. Think of replacing the "install" group with resources to 
install a package from source.

In order to accomplish all of these, resource groups would have to be 
integrated pretty deeply into Chef's resource collection. But there's no 
reason we can't add groups now and iterate. We do need to be careful not to 
accidentally leak implementation that then becomes an API that users want to 
rely on.

-- 
Dan DeLeo