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


Chronological Thread 
  • From: Maxime Brugidou < >
  • 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 19:28:58 +0200

We use the override run_list feature and take advantage of the fact that the run_list is not saved only if it is not empty. We run override run_list when a node is discovered or after a (long) installation process to quickly make sure that chef-client service is running.

The nice feature is that if the node discovered is "new" and has no run_list the data is saved and the run_list is permanently set. If the node is known and has a run_list we don't want to touch anything except make sure the bare minimum is set up (chef-client running).

I don't know if I'm clear but we don't mind the node not being saved only if the node already has a run_list and node data. We want it saved if it's new.

On Sep 17, 2013 6:03 PM, "Mike" < "> > 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.

§