On Tue, Sep 17, 2013 at 6:49 AM, Sam Pointer < "> > 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.