Wouldn't a change to the current behavior break bootstrapping? I believe it relies on being able to override the run_list, where the overridden run_list is responsible for the initial setup of the node.
Kevin Keane
The NetTech
760-721-8339
http://www.4nettech.com
Our values: Privacy, Liberty, Justice
See https://www.4nettech.com/corp/the-nettech-values.html
-----Original message-----
From: Sam Pointer < >
Sent: Tue 09-17-2013 03:49 am
Subject: [chef] Re: CHEF-3506 - Don‘t save the node object when using an override run list?
To: ;
I know the following doesn't directly answer the question at hand, but being able to override the run_list has always seemed like an anti-feature to me. It breaks a central tenet of configuration management in that you should be able to reproduce your infrastructure from the committed state of your source repository. In essence, there is nothing separating a for-loop around ssh and an override run other than the DSL. You've made a non-reproducible snowflake all the same, or you've re-introduced run books. Both poor outcomes.Whilst I am certainly not immune to practicality, a lot of the justifications for override run_lists I've attempted to make ("I want to do this one thing on this one box once to test", etc.) are simply excuses being made for poor process and an incomplete ability to test changes before they are applied against production.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.Sam PointerLead ConsultantOn 17 September 2013 04:49, Bryan McLellan < "> > wrote:
https://tickets.opscode.com/browse/CHEF-3506
This ticket proposes not saving the recipes and roles attributes when
using an override run list. Dan wondered if we should save the node
object at all. I can see being surprised in both situation; when your
node object changes on the next normal client run (or gives non-normal
search results in between) and when your node object doesn't change on
an override run, but when you're using override you're heading down
the path of someone who just asked for things to be a little sideways.
Anyone have a use case that would be upset by the node object being
not saved at the end of an override run?
--
Bryan McLellan | opscode | technical program manager, open source
(c) 206.607.7108 | (t) @btmspox | (b) http://blog.loftninjas.org
Archive powered by MHonArc 2.6.16.