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
In my org we avoid putting anything in the node, preferring to have
controlled attributes in roles, environments, and recipes.
This would likely be a significant change to your workflow, but it has
worked well for us thus far.
-Jesse
On Fri, Mar 8, 2013 at 3:25 AM, Martin Eigenbrodt <
martineigenbrodt@gmail.com> 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
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" martineigenbrodt@gmail.com 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
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 adam@opscode.com 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" martineigenbrodt@gmail.com
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
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
kcbraunschweig@gmail.comwrote:
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 adam@opscode.com 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" martineigenbrodt@gmail.com
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