[chef-dev] Configurable Global Resource or Provider behavior changes

[Daniel DeLeo < >]

Ohai Chefs! 

This discussion is inspired by CHEF-3115 
(http://tickets.opscode.com/browse/CHEF-3115)

There have been several instances where users have wanted the ability to 
modify resources/providers globally, such as adding a custom gem mirror to 
all gem_package resources, setting ENV variables for execute resources, or 
(as in this case) adding options to all user resources.

The two use cases for this feature (that I'm aware of) are to make community 
cookbooks work out of the box on different platforms (e.g., make NetBSD 
create a group for each user), or to reduce repetition in setting an option 
on every declaration of a given resource type (e.g., set your custom gem 
mirror in one place instead of on every gem_package resource).

We'd like feedback on a few questions:

1. How valuable is this feature? If you were using this, you'd need to look 
in several places (both the resource declaration in the recipe and wherever 
you've modified the default behaviors) to understand how Chef is going to 
change something on your system. And, of course, there would be added 
complexity in the code around defining and merging the defaults. Is the 
complexity worth it?

2. If you want this feature, where would you want to express your changes to 
the default behaviors? One similar feature we have in chef now is the ability 
to set the `ps` command used by Chef when a service provider cannot use an 
init script to determine if a service is running. The ps command would be 
modified by changing an attribute on the node itself. Personally, I think the 
node data is the wrong place to configure this sort of thing, so I'd favor 
putting it in the Chef config file, but there could be other ways.

Finally, I should note that we're busy with lots of new feature work at 
Opscode, so there's no guarantee about if or when we'd be able to commit any 
resources to implementing anything (assuming there's interest and reasonable 
consensus).

Thanks,

-- 
Dan DeLeo