unfortunately separating into different sections what you have and what you
want within the node object will not help, as the way the client node
functions, it pulls down the chef server’s representation of the node,
mutates it locally, then at the end of the chef run it saves, overwriting
the entire node object, not just modified portions.
moving this to a data bag is likely the best course of action.
On Tue, Mar 12, 2013 at 8:25 PM, 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
-> 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
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 firstname.lastname@example.org wrote:
Every object in chef is last-writer-wins. There is, at this time, no way
to guard against this.
On 3/8/13 12:25 AM, “Martin Eigenbrodt” email@example.com
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?