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

[Jay Pipes < >]

I think there are two important things here:

* Data that describes a system, but has nothing to do with the system's
state
* "Control data" -- or data points that indicate the current state of a
node at a particular point in time

Data that describes a system might be something like "cluster name". The
value of this data doesn't change regardless of whether a node is
running chef-client, completed chef-client successfully, or whether it's
April 1st. Such data, IMHO, should not be mixed with control data, that
*would* necessarily change with the aforementioned events.

Unfortunately, this data *is* mixed together with control data points,
and by this virtue, if you try to query for the former type of data
(such as "get me all the nodes in Chef server with this cluster name"
stuff using Chef search, the results returned are determined by what
state the chef-client last run on the node was. And this is what is,
again, IMHO, a design flaw.

Finally, I'd like to note that we found the cause of our issue below,
and it actually didn't have to do with node.save or any of that. It had
to do with the environment JSON file in question having two sections
named "keystone", and the latter section was overwriting the former
samed-named section, essentially deleting the values set in the former
section.

Now if only there was a safety feature that notified us of such a problem!

-jay

On 02/04/2013 02:01 PM, Jesse Campbell wrote:
> 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 
> <
 
> <mailto:
 >>
>  wrote:
> 
>     On 02/04/2013 01:41 PM, Adam Jacob wrote:
>     > On 2/4/13 9:27 AM, "Jay Pipes" 
> <
 
>     
> <mailto:
 >>
>  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
> 
>