[chef] Re: Re: Re: Re: Re: Why an environment's override_attributes are not set until chef-client completes successfully?

[Ranjib Dey < >]

But if you do that(post a node's data back to server even if the convergence fail), you are making a failed node's data available to other nodes, and they might use it to build further configs, which is wrong, its a wrong assumption. When I query chef server for an attribute (say mysql_server_version) i assume that the node has successfully converged. The fact that this attribute is available, proves this (unless you do something fishy). But if we follow your logic, we have to do an additional check other than search just to ensure if its actually a working node,

isn't it

On Mon, Feb 4, 2013 at 10:47 AM, Jay Pipes < " target="_blank"> > wrote:

On 02/04/2013 01:41 PM, Adam Jacob wrote:
> On 2/4/13 9:27 AM, "Jay Pipes" < "> > wrote:
>> Yes, we ended up having to use node.save in a Galera cluster cookbook
>> were were using when we saw that Chef searches were entirely
>> non-deterministic if you were relying on attributes that would only be
>> set if the chef-client run had succeeeded. It's a major design flaw, IMHO.
>
> One man's design flaw is another mans safety feature. :)

Chef seems to have a lot of safety features.

> (ie: if chef didn't succeed, how do you know the system is correct, and
> that you should rely on it?)

This is a silly statement. The purpose of an environment override
attribute is to describe the intended state of a system belonging to
that environment. Why on Earth would chef-client succeeding or not
succeeding change anything related to the intended state of a system
belonging to an environment?

It just doesn't make sense.

-jay