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

[Lamont Granquist < >]

OTOH, properly constructed CM should be idempotent and orthogonal.  If I need to do a software deployment, I don't generally need to touch ntp or smtp or anything outside of the cookbook that deploys the software.  In fact if I --why-run a software deployment I don't expect to see anything else change (and non-idempotent stuff that changes on every run I expect to be convergent, so that the software deployment doesn't really depend on that).  I should be able to more quickly rollout software by using an override run list to only run the software deployment cookbook, and the rest of the state of the server should be orthogonal and idempotent.  If this does not work, then you've architected some kind of a mess, and should really refactor your infrastructure.  Since it works, there's no good reason to not utilize it.

On 9/17/13 3:49 AM, Sam Pointer wrote:

" type="cite">

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