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

[Bryan McLellan < >]

On Sat, Sep 25, 2010 at 1:07 AM, jon stuart 
<
 >
 wrote:
> Interestingly put, I'll bite :)

Oooh, score one for me!

> 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*

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

> 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.

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.

> It's interesting data in my ongoing, and admittedly fluffy, evaluation
> of different tools available to me as a devops-shaped FreeBSD sysadmin.
> We're certainly out there :)

So glad!

Bryan