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

[Elvin Abordo < >]

I will throw my 2 pences into the fire. 

I don't think we should save the override run_list back to the node.

Here's why. I have some level 1 techs that do some fairly basic troubleshooting. They have a 24/7 shift and have administrative access to our 1k + nodes. There are times where we want to roll out some changes/upgrades/packages late night because of various reasons and want to provide them a one liner something like `chef-client -o 'recipe[dosomething::awesome]` that they and us can be confident will be idempotent and won't break because of xyz. But in our testing in doing so with the run_list getting saved back to the node, we weren't confident that this was our solution as we didn't want to disrupt the node data that may or may not affect other nodes. 

so i will toss in a vote for "don't save the run_list back to the node in an override run_list situation"

On Tue, Sep 17, 2013 at 9:19 AM, Adam Leff < " target="_blank"> > wrote:

Sam,

While I absolutely see your point, I disagree that removing the feature is the right path.

This may not be best practices, but I employ a pattern where for every recipe I write, I write an "uninstall" recipe in parallel that sort of unwinds the install.  In cases where we are running physical boxes, having the ability to use Chef to uninstall something is great, and not something I want to muck around with node run_lists to do - hence, having the override run_list feature really is helpful.  Being able to kick off that uninstall recipe in cases where the preferred "kill off the VM and recreate" path is not available and without having to jump through hoops is really awesome.

I don't necessarily see any value in saving the run_list back to the node object (or any part of the node object, actually), so I'm in the "don't bother saving in an override situation" crowd.

~Adam

On Tue, Sep 17, 2013 at 6:49 AM, Sam Pointer < " target="_blank"> > wrote:

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 Pointer

Lead Consultant

www.opsunit.com

On 17 September 2013 04:49, Bryan McLellan < " target="_blank"> > 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

--
Elvin Abordo
Mobile: (845) 475-8744