[chef] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Role Versioning?

[Sean OMeara < >]

I like this thread.

Also, don't forget that Chef has tags that you can set on nodes.

If you include_recipe a recipe that include_recipes a recipe, that
recipe can explicitly set something in the node object for other
recipes to search for.

tag("sparkly")
search( :node,  "tags:sparkly")

It's a great way for a recipe to "announce" that it provides a service.

-s

On Fri, Feb 15, 2013 at 8:29 AM, Andrea Campi
<
 >
 wrote:
> I'll second that: a search for roles looks for an interface, a search for a
> recipe looks for an implementation detail.
>
> If my app needs an SMTP server, I don't need to know whether that's sendmail
> or postfix; I want to look for a "outgoing_smtp" role or something like
> that.
> Sure, I could have a "outgoing_smtp" cookbook and know that by convention it
> has a "default" recipe that is doing whatever is necessary--but that's extra
> ceremony in my book.
>
>
> On Fri, Feb 15, 2013 at 1:01 PM, Brian Akins 
> <
 >
>  wrote:
>>
>> On Fri, Feb 15, 2013 at 12:56 AM, Torben Knerr 
>> <
 >
>>  wrote:
>> > I would even go that far and state that using search "recipe:*" is an
>> > antipattern and should not be used in community cookbooks (due to the
>> > include_recipe flaws).
>>
>> I think it's an anti-pattern, but not because of the "flaw" in
>> include_recipe.  I don't like cookbook A having to know implementation
>> details about cookbook B. That's why I like the "service registry"
>> approach: node A says I have this service with these attributes (who
>> cares from which cookbook) and node B can ask for all the nodes (and
>> service attributes) that have that service.  I can make the same
>> argument about depending on  certain roles for search, etc - it seems
>> to expose (and lock you into) certain implementation details.
>>
>> --Brian
>
>