[chef] Re: Re: Re: Re: CHEF-3506 - Don't save the node object when using an override run list?


Chronological Thread 
  • From: "John E. Vincent (lusis)" < >
  • To: " " < >
  • Subject: [chef] Re: Re: Re: Re: CHEF-3506 - Don't save the node object when using an override run list?
  • Date: Tue, 17 Sep 2013 15:24:59 -0400

I'm torn here. I make EXTENSIVE use of overriding the run_list for one-shot tasks in our installer. Things like "recipe[foo:enable]" or "recipe[foo:disable]" but we do this all with chef-solo. 
I'm generally of the opinion that if I want to save any critical state back, I'd call node.save. I was burned by the bootstrap-failure-not-saving-back change a long time ago and I have scars. Ugly nasty scars.

The things I generally use override run_list for are things that I know have no lasting side effects. I don't intend it to blow away the state of the node. Like a one-shot.

Then again the things I use it for I'm pretty diligent about ensuring doesn't have side effects like that.


On Tue, Sep 17, 2013 at 12:03 PM, Mike < " target="_blank"> > wrote:
Let's ask this question:

What is the general use case for using an override run_list?
And during such a run, would you expect that the run_list items be available for any other purpose in your ecosystem, not just this node during this run?

These are open questions, and I think my answers are:
I barely ever use the override, and would expect it to only be "transient" state - if I wanted the stuff to be around for longer, I'd make it persistent.

-M


On Tue, Sep 17, 2013 at 11:40 AM, Bryan McLellan < " target="_blank"> > wrote:
> So, whilst not perhaps the answer that is wanted, my reply would be "none of
> the above, remove the ability to override". It smacks of enabling a rewrite
> of bash into the Chef DSL whilst missing the real point behind what we're
> all trying to do with configuration management.

Chef often hands you a big hammer and asks that you handle it with
respect. One of the fundamentals of Chef is that it doesn't force you
into configuring your systems using a fixed model. We, the Chef
developers, don't know your infrastructure and your problems. As time
goes on and those problems become more defined, we extend Chef to be
able to solve them more directly, as best we can.

A number of use cases came up in the discussion around CHEF-2988 [1],
especially on the mailing list thread. [2] Some may be solved in the
future by Push [3] or failure zones [4]. Even so, in the interim
override run lists are helping folks get work done.

--
Bryan McLellan | opscode | technical program manager, open source
(c) 206.607.7108 | (t) @btmspox | (b) http://blog.loftninjas.org

[1] https://tickets.opscode.com/browse/CHEF-2988
[2] http://lists.opscode.com/sympa/arc/chef-dev/2012-03/msg00060.html
[3] http://www.youtube.com/watch?v=yHub6E4DNvg
[4] https://tickets.opscode.com/browse/CHEF-2070





Archive powered by MHonArc 2.6.16.

§