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

[Jesse Campbell < >]

I would not want a new server who's deployment failed to show up in the search, and I'm confused why you would...

(I'm also using galera clusters)

if one of the new DB nodes didn't deploy properly, and it saved, the cookbook that updates the load balancer (runs somewhere else) would add this failed machine to the pool.

If the machine failed to deploy, who knows how far it got... maybe mysql is running with half of the tables and broken sync? yikes!

I would definitely call this a safety feature that I rely on (and I'm not sure what you mean by "a lot of safety features")

On Mon, Feb 4, 2013 at 1:47 PM, 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