Hey all,
How do you think why we meet the node.save command in many recipes? For
example, I’ve seen it in the mysql recipe.
As far as I understand any attributes that are set in recipes are
automatically persisted.
So what for is the ‘node.save’ command then?
Thanks for any ideas
Denis
its saved at the end of the run automatically. If you are setting an
attribute in the recipe and trying to reuse it in the same recipe afterwards
u make an explicit node.save call.
On Fri, Sep 9, 2011 at 4:16 PM, Denis Barishev denis.barishev@gmail.comwrote:
Hey all,
How do you think why we meet the node.save command in many recipes? For
example, I've seen it in the mysql recipe.
As far as I understand any attributes that are set in recipes are
automatically persisted.
So what for is the 'node.save' command then?Thanks for any ideas
Denis
Yeah. I suspected this. What if run fails will be the attribute saved
then?
Talking about reusing the attribute in the same recipe during the same
run. I sure the attribute is available as soon as it set. There's no a
particular need to do node.save.
So I don't quite understand that what you mean by this, Ranjib.
Denis
On Fri 09 Sep 2011 03:16:15 PM MSD, Ranjib Dey wrote:
its saved at the end of the run automatically. If you are setting an
attribute in the recipe and trying to reuse it in the same recipe
afterwards u make an explicit node.save call.On Fri, Sep 9, 2011 at 4:16 PM, Denis Barishev
<denis.barishev@gmail.com mailto:denis.barishev@gmail.com> wrote:Hey all, How do you think why we meet the node.save command in many recipes? For example, I've seen it in the mysql recipe. As far as I understand any attributes that are set in recipes are automatically persisted. So what for is the 'node.save' command then? Thanks for any ideas Denis
On Sep 9, 2011, at 7:16 AM, Ranjib Dey wrote:
its saved at the end of the run automatically. If you are setting an attribute in the recipe and trying to reuse it in the same recipe afterwards u make an explicit node.save call.
No, you don't have to save to use later in the same run. node.save persists it on the chef-server. This is useful to do if you know other nodes may need this node's attributes "right away." One case in mysql master/slave configurations that was discussed on the list in the last few days.
Also, correct me if I am wrong, if a chef-client run fails, then node.save is not automatically called at the end.
--Brian
On 09/09/2011 03:31 PM, Brian Akins wrote:
On Sep 9, 2011, at 7:16 AM, Ranjib Dey wrote:
its saved at the end of the run automatically. If you are setting an attribute in the recipe and trying to reuse it in the same recipe afterwards u make an explicit node.save call.
No, you don't have to save to use later in the same run. node.save persists it on the chef-server. This is useful to do if you know other nodes may need this node's attributes "right away." One case in mysql master/slave configurations that was discussed on the list in the last few days.
Thanks for clarification, Brian!
Also, correct me if I am wrong, if a chef-client run fails, then node.save is not automatically called at the end.
Yeah, this moment is still of interest, right.
Denis
node.save is not invoked if the run fails, but i guess we can hack it inside
a report handler and save it there.
On Fri, Sep 9, 2011 at 5:03 PM, Denis Barishev denis.barishev@gmail.comwrote:
On 09/09/2011 03:31 PM, Brian Akins wrote:
On Sep 9, 2011, at 7:16 AM, Ranjib Dey wrote:
its saved at the end of the run automatically. If you are setting an
attribute in the recipe and trying to reuse it in the same recipe afterwards
u make an explicit node.save call.No, you don't have to save to use later in the same run. node.save
persists it on the chef-server. This is useful to do if you know other
nodes may need this node's attributes "right away." One case in mysql
master/slave configurations that was discussed on the list in the last few
days.Thanks for clarification, Brian!
Also, correct me if I am wrong, if a chef-client run fails, then node.save
is not automatically called at the end.
Yeah, this moment is still of interest, right.
Denis
On 09/09/2011 03:55 PM, Ranjib Dey wrote:
node.save is not invoked if the run fails, but i guess we can hack it
inside a report handler and save it there.
Okay good. But I think we'd better explicitly call node.save inside a
recipe (as others do it) if we expect fails latter in recipe... It's not
good a good practice to persist data of a node failed to run.
Denis
Hi,
node.save is used explicitly when information must be save even if the chef
run fails.
A good example is when a random password (e.g. for MySQL) has been generated
and applied to the database. If you don't call node.save and the run fails,
then the next run will generate a new password which doesn't match the
password in the database so access to the database will fail.
By calling node.save right after generating the password but before applying
it to the database you ensure that even when the chef run fails lateron, the
same password will be used in subsequent chef runs.
Regards,
Klaas Jan Wierenga
2011/9/9 Denis Barishev denis.barishev@gmail.com
On 09/09/2011 03:55 PM, Ranjib Dey wrote:
node.save is not invoked if the run fails, but i guess we can hack it
inside a report handler and save it there.Okay good. But I think we'd better explicitly call node.save inside a
recipe (as others do it) if we expect fails latter in recipe... It's not
good a good practice to persist data of a node failed to run.Denis
--
Groeten,
Klaas Jan
k.j.wierenga@gmail.com
On Fri, Sep 9, 2011 at 8:04 AM, Denis Barishev denis.barishev@gmail.com wrote:
On 09/09/2011 03:55 PM, Ranjib Dey wrote:
node.save is not invoked if the run fails, but i guess we can hack it
inside a report handler and save it there.Okay good. But I think we'd better explicitly call node.save inside a recipe
(as others do it) if we expect fails latter in recipe... It's not good a
good practice to persist data of a node failed to run.Denis
It's probably worth noting that this behavior is different from 0.9 to
0.10. In 0.9, nodes were saved at the beginning of the run. In 0.10,
nodes are not saved unless a run is successful.
If you absolutely need the node saved (so that it's available as a
search result on another node for instance) then, yes, calling
node.save is warranted. As you said though, it's important that you
only call node.save at the point where the system is in a state where
it's can perform whatever function is needed that makes it usable as a
search result. This can get annoying because it means, in something
like the case of MySQL, you need to ensure that services are starting
immediately as opposed to delayed till the end of the run.
It's much better, imho, those more advanced sort of interactions
outside of Chef or to employ some sort of blocking in another client's
run.
I believe the conversation following answers the primary part of the query.
An unanswered question may be "So why doesn't Chef save the node when
the run fails?"
The answer is, that by default, Chef would have no way of knowing
whether that is a desirable thing to do. There may be something in
your recipes that you wouldn't want saved until the full convergence
finished. Chef doesn't make the assumption of doing so because it is
easier for you to explicitly save in a recipe, or to call node.save in
a report / exception handler than to try and undo that kind of
behavior down in the core of Chef.
And to clarify, the attribute behavior in the mysql::server recipe is
specifically because we're generating a random password so there's
something to use in preseeding the mysql installation, AND so the
password is persisted as an attribute, so you don't have to do
additional work in setting a password somewhere to use it.
Hope this helps.
On Fri, Sep 9, 2011 at 4:46 AM, Denis Barishev denis.barishev@gmail.com wrote:
Hey all,
How do you think why we meet the node.save command in many recipes? For
example, I've seen it in the mysql recipe.
As far as I understand any attributes that are set in recipes are
automatically persisted.
So what for is the 'node.save' command then?Thanks for any ideas
Denis
--
Opscode, Inc
Joshua Timberman, Director of Training and Services
IRC, Skype, Twitter, Github: jtimberman