[chef] Re: SCM for node definitions?

[Jeff Blaine < >]

Thanks for the helpful replies. We're getting into areas here that were 
not touched on in the previous thread, so I'm glad I asked after all 
(after it was discussed 2 days prior).

Who should be making the configuration-data changes to nodes if not devs 
and ops (and security in coordination with devs and ops)? What 
situations exist where the people who don't already have git push and 
knife upload privileges would need to be given 
out-of-change-management-control access to site-local node configuration 
data (which is just as critical to stability (et al) as cookbook code)? 
Clue me in?

It's not important to know that samsmith changed node['blah'] from X to 
Y at 7:34PM yesterday because "Explanation A B C"? How is that not 
absolutely necessary? Or you're (Lamont) saying that this should be 
gleaned back-channel via the database transaction log coupled with a 
direct question to the database user who performed the transaction? I'm 
struggling to resolve this idea you're posing that change control is 
irrelevant WRT server configuration values.

I'm eager to learn.

[Lamont]:
> I find that limiting because then you have to be a dev in order to 
> push SCM updates

"... given the current interface."

"Don't use SCM, even if it really should be used, because the UI 
provided so far is hairy for non-techies." doesn't hold water to me (as 
a gut reaction). I realize I am quoting words you didn't say, but that's 
what it seems you are saying.

[Benjamin]:
> All have their strengths and drawbacks.  We've had a hard time seeing 
> a way forward.  One issue is that we have a huge number of apps that 
> currently run on a much smaller number of servers, with many apps 
> stacked deep on each cluster.  This makes nearly every server 
> different in fundamental ways.  There is much that is common as far as 
> the larger components (weblogic, apache, jvm), but after that the 
> variation is enormous.
>
> Seems like there are as many ways to do this as there are 
> organizations using chef.

We're in that same boat, but likely to an even more disjointed level.