[chef] Re: Re: Re: Re: Re: Re: chef support on freebsd is subpar

[jon stuart < >]

On 25/09/2010 10:02, Bryan McLellan wrote:
> On Sat, Sep 25, 2010 at 1:07 AM, jon stuart 
> <
 >
>  wrote:
>> I'm curious about the "we" in "our culture". Just as a data point: I run
>> (fsdo) large-ish amount of FreeBSD hosts with configuration management
>> at scale, and I know others who do too. I'd consider ourselves
>> devops-oriented, f'sure.
> 
> OS + distribution wars acknowledged; you tend to see trends in why
> people choose one over another. Some are maybe more stereotypes than
> others. Maybe not. Are most Gentoo users fascinated with eeking out
> performance? OpenBSD users putting security first? RHEL users sleep
> better at night with enterprise support? *shrug*

I see your point. I'd not encountered this perception about FreeBSD and
configuration management before, it surprised me.

> 
> We is us. Hi there! But, being a chef list, "we" is mostly chef users
> and "our culture" is that of users of chef.
> 

Thanks for having me as an interested lurker.

>> As much as chef appeals to me I'm still reluctant to use it owing to
>> CHEF-13 [*], and despite good intentions I've not made much progress in
>> helping address that beyond baby steps in a lab environment.
> 
> We're working on that, and it'll happen, but there are shortcomings to
> no-op. If you want chef to tell you that it would change an apache
> config file, which would cause it to restart apache, that's well
> enough and will work. It probably won't tell you that apache will fail
> to start because of a typo in your configuration file though. Sure,
> you could parse the config to verify correctness, but that'd be an
> execute, and in noop mode that wouldn't actually run, chef would only
> tell you that it would run. It would work most of the time if you kept
> everything pretty simple and stayed away from execute and other
> resources where you're modifying the state of the system directly in a
> way that chef can't track. If a system is in state X, and running
> resource A requires that it be in state Y, so you run resource B to
> move the system from state X to state Y, will noop mode be able to
> follow this state change and tell you that both A and B would occur?
> 
> Chef is a systems integration framework, which allows the system to
> dynamically changed based on external information. Noop might do
> nothing now, but in thirty seconds it might generate a completely
> different list of nodes to add to the load balancer configuration
> because you're building search-based infrastructure. Maybe you're
> hotadding physical resources to virtualized guests or spinning up EC2
> instances based on queue depth. Perhaps you're using Science to
> determine the current tuning for your application server based on
> various performance metrics.
> 

Thanks for taking the time to illustrate this. Good to hear some manner
of noop is on the cards.

> It's awesome to find security in knowing what chef would do through
> noop, but it can be dangerous to take too much solace in it.

Indeed. Personally I'm happy to take the risk that noop will necessarily
be inperfect to gain some visibility of what an automated tool might do
to systems before it actually does it.

Anyways, I conflated the FreeBSD thing with CHEF-13. Sorry about that!

Regards, jon.