[DevOps:///OpsCode.Chef]
ate a weird meal last evening, chef was angry I think.....
When I created an AWS instance in same way (by swiss-
'knife ec2 server create...' toolset) using same old boot-up script to get that insance auto-configured as chef-client; instance
got created and was visible in the instance list but not available to my recipes trying
to search for it using its applied role and other tags.
The same
procedure has worked successfully for all previous time, and with no change it suddenly started failing.
I
logged-in to the freshly created instance and exec '
chef-client --once' again, it had a
successful run but
still the
recipe failed to grab the node by its role and tags.
So it was a
perfectly performing instance according to its run_list, but
not available to other features trying to grab its information over
Chef Search mechanism.
What could be the problem?
The answer to it is hidden in knowing how Chef Search function.
Chef Search
uses Solr Indexing service, which an enterprise-grade OpenSource search server based upon Apache Lucene.
It has a system service '
chef-solr' which acts as a wrapper around Solr to be run for Chef.
Though, this
service was fine as I was able to search all earlier created nodes..... just the new additions were escaping the act.
Now, if Chef-Solr was working fine then we need to look its source for data. Obviously, it was
working fine for already indexed data but didn't happen to index anything newly added.
Chef-Solr gets data passed on from the message queue of RabbitMQ, placed before to ease the load of several concurrent requests for Solr.
Chef-Exapander is a system-level service that fetches data from RabbitMQ's queue and formats them before
passing on to chef-solr.
This combination of chef-exapnder and chef-solr acts as final feature of Chef Indexer.
So, I looked for
chef-expander service.
It was in failing mode, restarted the service and bam!
We are back up and the new aditions are visible in Chef Search.