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.-MOn Tue, Sep 17, 2013 at 11:40 AM, Bryan McLellan < " target="_blank"> > wrote:
On Tue, Sep 17, 2013 at 6:49 AM, Sam Pointer < " target="_blank"> > wrote:
> So, whilst not perhaps the answer that is wanted, my reply would be "none ofChef often hands you a big hammer and asks that you handle it with
> 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.
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.
[1] https://tickets.opscode.com/browse/CHEF-2988
--
Bryan McLellan | opscode | technical program manager, open source
(c) 206.607.7108 | (t) @btmspox | (b) http://blog.loftninjas.org
[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.