Open josephholsten opened 9 years ago
my 2 cents is that just like the elasticsearch cookbook (as of the 1.x rewrite) we should convert this to a library cb and let the users do their chef search in their wrappers.
Marking stale due to inactivity. Remove stale label or comment or this will be closed in 7 days. Alternatively drop by the #sous-chefs channel on the Chef Community Slack and we'll be happy to help! Thanks, Sous-Chefs.
From https://github.com/edelight/chef-mongodb/issues/215
Chef Search is used for three purposes in this cookbook:
While chef search is great for a good out-of-the-box experience, it's actually quite poorly suited to the task of configuring a database cluster:
Additionally, our use of search has other problems:
Considering all those issues, we should strive to isolate our use of chef-search for discovery. To tackle this, we'll need to:
Improve Library, Definition & Resource APIs
Pull access to node objects out from library functions, and ultimately out of the
mongodb_instance
definition so wrapper cookbooks can provide alternative discovery methods. These should be possible while remaining backwards compatible.This should require refactoring
MongoDB::configure_replicaset
andMongoDB::configure_shards
to accept a mere array of strings as node identifiers. To do this,mongodb_instance
will need to extract the correct attributes for each node.With this done, that logic will need to be pulled up into the cookbooks which call
mongodb_instance
. At this point, it will probably be useful to create a helper library to abstract this discovery. I suggest we model this library aftersearch_for_nodes
from the elasticsearch cookbook, and the discovery cookbook from Heavywater.Improve cookbook API
Define a set of node attributes which allow overriding discovery for most use cases:
fqdn
attribute from each matched nodescloud.local_ipv4
attribute from each matched nodescloud. public_ipv4
attribute from each matched nodesipaddress
attributes from each matched nodesI suggest we model our use of attributes after search in the elasticsearch cookbook, which uses:
node['elasticsearch']['discovery']['search_query']
- which defaults toroles:elasticsearch AND chef_environment:#{node.chef_environment} AND elasticsearch_cluster_name:#{node[:elasticsearch][:cluster][:name]}"
node['elasticsearch']['discovery']['node_attribute']
- which defaults tocloud.local_ipv4
if it exists, oripaddress
This implies the following :
node['elasticsearch']['discovery']['search_query']
- which defaults toroles:elasticsearch AND chef_environment:#{node.chef_environment} AND elasticsearch_cluster_name:#{node[:elasticsearch][:cluster][:name]}"
node['elasticsearch']['discovery']['node_attribute']
- which defaults tocloud.local_ipv4
if it exists, oripaddress