[chef] Re: Re: Re: Chef Search Again

[Sean OMeara < >]

Welcome to the wonder world of distributed systems!

If you're going to use Chef search as a service discovery mechanism,
you're going to face these limitations.

Saving the node object to the Chef Server at the end of the run is "by
design". A node that's not fully converged is likely not functional
yet. For example, if you has a load balancer searching for web server
nodes to include them in a pool, you don't want a machine that's half
configured and not serving data in your pool yet.

In the general case, I'd recommend using Real Service Discovery
protocol for your service discovery.

However, since you're attempting to do just that, (setting up
zookeeper), something gotta give.

You are, by the very nature of your problem, going to be forced to
write some error handling code, and do multiple converges in this
scenario. This is not a limitation of Chef or Chef Server. This is a
general problem.

-s


On Tue, Jun 16, 2015 at 3:58 PM, Douglas Garstang
<
 >
 wrote:
> So, let me summarise this sorry situation...
>
> 1. By default, data about nodes isn't available until after the chef client
> has run at least once.
> 2. Node.save at the start of the run list should fix this, but it does not.
> 3. Putting a 60s/90s sleep before the knife search, which should allow solr
> to complete a re-index has no effect.
> 4. Doing a dummy run of the chef-client and pointing it to a no-op recipe to
> get around (1) above requires passing the -r option which has the side
> effect of updating the run list on the chef server so that the next call to
> chef-client uses the dummy cookbook, not the cookbook this node was
> originally provisioned to use.
> 5. Even if node.save did work, it won't run on vagrant and throws an error.
>
> Did someone intentionally design chef server to induce scraping eyes out
> with a rusty razor blade? I'm pretty fed up.
>
> Doug.
>
> On Tue, Jun 16, 2015 at 12:51 PM, Douglas Garstang 
> <
 >
> wrote:
>>
>> Stephen,
>>
>> Well, I just tried using chef-client -r dummy and that worked. However,
>> that permanently replaces the run list on the chef server. If I now run
>> chef-client, hoping to use the zookeeper cookbook formerly associated with
>> the node, it's been replaced by the dummy one. I am so frustrated. :(
>>
>> Doug.
>>
>> On Tue, Jun 16, 2015 at 12:38 PM, Stephen Delano 
>> <
 >
>> wrote:
>>>
>>> > Sigh. I guess all I need is an empty cookbook that does nothing as
>>> > node.save seems to have no effect anyway. All I need is a dummy chef 
>>> > client
>>> > run.
>>>
>>> How are you running this “dummy” chef-client run? If you change the
>>> run-list to remove the role role-zookeeper, your node will be persisted
>>> without this role and without the attributes associated with it. You’ll 
>>> have
>>> a period of time where the roles attribute of the node does NOT contain 
>>> what
>>> you’re looking for and searches will fail.
>>>
>>> —
>>> Stephen Delano - Engineering Lead, Chef
>>>
>>>
>>> On Tue, Jun 16, 2015 at 11:50 AM, Douglas Garstang
>>> <
 >
>>>  wrote:
>>>>
>>>> The battle continues with chef search. I'm trying to use chef search to
>>>> discover zookeeper nodes. The very first thing in my run list is 
>>>> node.save,
>>>> which seems to cause the Chef server to immediately have access to the 
>>>> data
>>>> I need, the role and the environment.
>>>>
>>>> I just did a test, where one window had the result of "knife search node
>>>> "chef_environment:dev AND roles:role-zookeeper". I could see that the 
>>>> data
>>>> was populated immediately after the call to node.save. A few minutes 
>>>> later,
>>>> when the recipe did it's search, no nodes were found, as evidenced from 
>>>> an
>>>> empty log() statement in the recipe.
>>>>
>>>> I've run the test a few times, and basically, the result are unreliable.
>>>> On my latest test, two of the nodes discovered all three nodes, and one 
>>>> of
>>>> the nodes discovered only one node (not itself btw).
>>>>
>>>> How can I make this reliable?
>>>>
>>>> Doug
>>>>
>>>
>>
>>
>>
>> --
>> Regards,
>>
>> Douglas Garstang
>> http://www.linkedin.com/in/garstang
>> Email: 
>> 
 
>> Cell: +1-805-340-5627
>
>
>
>
> --
> Regards,
>
> Douglas Garstang
> http://www.linkedin.com/in/garstang
> Email: 
> 
 
> Cell: +1-805-340-5627