Daniel,
If what you need is an abstraction, absolutely use resources & providers.
But a definition is essentially a parameterized recipe template (macro). Not an abstraction. That's why I talked about resources and providers being an abstraction, but talked about definitions being merely a grouping of related resource declarations.
An example of something suited to be a definition would be: the apache_conf definition in the apache2 cookbook. The right level of abstraction for this particular case is to call a procedure (macro) that simply declares another resource with some predefined attributes and some other parameterized attributes. Every apache config file change needs to trigger a reload or restart of the service, and there may be many such config files, so wrapping that up in a definition (macro) is useful.
But it is not useful to think of this example as an abstraction - it's better to think of this as a helper method which is not an abstraction. Attempting to force that into a resource/provider may be much more effort than it's worth; attempting to get rid of the definition and simply rewrite all the call sites seems to me to be going backwards.
Cheers,
Jay
On Tue, Mar 19, 2013 at 5:11 PM, Daniel DeLeo
<
" target="_blank">
> wrote:
On Tuesday, March 19, 2013 at 12:05 PM, Jay Feldblum wrote:
Daniel,
Lightweight resources & providers take two files which must be kept in sync. (You could do it in one file in a library, but then you lose the DSL. The fact that it's easy is not in dispute. The point is that it's unnecessary.) The interface and the implementation are forcibly separated, regardless of whether you actually need that separation.
The inline-resources feature is certainly helpful in this context. But that introduces another problem: notifications. Recipe-level resources can't notify inline-resources declared in a provider action. Sometimes what one needs is for the recipe to notify a resource declared from within a macro (or subscribe to one).
When something requires the convenience of grouping but does not require the wall of abstraction, then resources & providers do too much.
Cheers,
Jay
Thanks for the feedback.
The bit about having two files and such seems like just an interface issue. This can be solved with a little bit of design effort.
As for notifying resources that are defined by a macro, that feels a bit ugly because you're crossing the abstraction layers. Can you explain a bit more about how you're using this profitably? Would it be a huge burden to implement this in a hypothetical "extra lightweight RP" that defined the resource and provider in a single file?
--
Daniel DeLeo