On Fri, Feb 15, 2013 at 12:56 AM, Torben Knerr ukio@gmx.de 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
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 brian@akins.org wrote:
On Fri, Feb 15, 2013 at 12:56 AM, Torben Knerr ukio@gmx.de 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
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
andrea.campi@zephirworks.com 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 brian@akins.org wrote:
On Fri, Feb 15, 2013 at 12:56 AM, Torben Knerr ukio@gmx.de 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
On Fri, Feb 15, 2013 at 8:52 AM, Sean OMeara someara@gmail.com wrote:
It's a great way for a recipe to "announce" that it provides a service.
I always forget about tags.
In our case we include some data in our "announcement" and tags are
just a single string.
Something like:
#on the node "providing" the service
my_announce_thing('servicename', port: 80, key: 'baz')
#on a node "looking"
nodes = my_lookfor_thing('servicename')
and nodes is an array of hashes. each hash is the data the "providing"
node announced (we put the nodename and ipaddress in the hash as
well).
This pattern has served us well.
--Brian
Another options is node.set( somstuff )
-s
On Fri, Feb 15, 2013 at 9:01 AM, Brian Akins brian@akins.org wrote:
On Fri, Feb 15, 2013 at 8:52 AM, Sean OMeara someara@gmail.com wrote:
It's a great way for a recipe to "announce" that it provides a service.
I always forget about tags.
In our case we include some data in our "announcement" and tags are
just a single string.
Something like:
#on the node "providing" the service
my_announce_thing('servicename', port: 80, key: 'baz')
#on a node "looking"
nodes = my_lookfor_thing('servicename')
and nodes is an array of hashes. each hash is the data the "providing"
node announced (we put the nodename and ipaddress in the hash as
well).
This pattern has served us well.
--Brian
On Fri, Feb 15, 2013 at 9:14 AM, Sean OMeara someara@gmail.com wrote:
Another options is node.set( somstuff )
That's really all our "announce" does. And the "find" is just a
wrapper around search with some hackery to work on solo.