[chef] Re: Re: knife node changes and client run concurrency

[KC Braunschweig < >]

Since this is contention between the node describing itself and the CI system ostensibly trying to change the desired state of the node, one way to address this might be to set some conventions that define different parts of the node object for different intentions such as:
- node['myappfoo']... describes my apps existential state. only the node should change this as we trust him to report his own state

- node['myappbar']... describes my apps intended state. only the CI pipeline changes this as it embodies the business logic that defines the intended state

-> this allows you to leave to the node the decision about when it is safe to transition to rectify a difference between current state and intended state

I'd probably pull intended state out of the node and use a databag or something (did that at a past company) but it could work in the node too if you're consistent about enforcing the convention. 

On Fri, Mar 8, 2013 at 8:46 AM, Adam Jacob < " target="_blank"> > wrote:

Every object in chef is last-writer-wins. There is, at this time, no way
to guard against this.

Adam

On 3/8/13 12:25 AM, "Martin Eigenbrodt" < "> > wrote:

>Hi there,
>
>i experienced the following problem: A CI Job ran "knife node from file
>.." but the node attributes seemed to be unchanged later. Investigating
>erchefs Log I found out, that there had been an concurrent chef-client
>run on the relevant node.
>It looks like the client read the node data before the run, while it run
>knife has updated the data and after the run the client pushed  its old
>node - and know wrong - data back to the server.
>
>Is this a known issue? How can I guard against this?
>
>
>Regards,
>
>Martin