Abstract away chef search for discovery

[josephholsten]

From edelight/chef-mongodb#215

Chef Search is used for three purposes in this cookbook:

• discovering configserver instances for mongos: recipes/mongos.rb:29
• discovering replicaset peers for mongod: definitions/mongodb.rb:203
• discovering shard instances for mongos: definitions/mongodb.rb:231

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:

• solr updates not synchronous, so an overloaded chef-server may be many seconds behind actual configuration
• node objects in the chef-server may diverge from actual running instances
• chef solo does not natively support search, requiring chef-solo-search

Additionally, our use of search has other problems:

• hard-coded search queries require nodes to match our expected attributes, which may not suit the needs of some users
• assuming the result of discovery is from chef search causes the code to assume it is receiving chef node objects, which makes it cumbersome to replace with another discovery implementation, or ever to stub for testing

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 and MongoDB::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 after search_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:

• search by role
• search by tag
• search by arbitrary query
• select fqdn attribute from each matched nodes
• select cloud.local_ipv4 attribute from each matched nodes
• select cloud. public_ipv4 attribute from each matched nodes
• select ipaddress attributes from each matched nodes

I suggest we model our use of attributes after search in the elasticsearch cookbook, which uses:

• node['elasticsearch']['discovery']['search_query'] - which defaults to roles:elasticsearch AND chef_environment:#{node.chef_environment} AND elasticsearch_cluster_name:#{node[:elasticsearch][:cluster][:name]}"
• node['elasticsearch']['discovery']['node_attribute'] - which defaults to cloud.local_ipv4 if it exists, or ipaddress

This implies the following :

• node['elasticsearch']['discovery']['search_query'] - which defaults to roles:elasticsearch AND chef_environment:#{node.chef_environment} AND elasticsearch_cluster_name:#{node[:elasticsearch][:cluster][:name]}"
• node['elasticsearch']['discovery']['node_attribute'] - which defaults to cloud.local_ipv4 if it exists, or ipaddress

[majormoses]

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.

[github-actions]

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.