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

[" " < >]

Gents & Ladies,

Where's the OSS love? I'm an avid user of *nix gentoo, openBSD, and FreeBSD are my choice OSes.  I love open source and have always taken to heart the mentality I often see preached...

If it's broken and it's opensource it's your obligation not to just complain, but to take responsibility as a devops member of a community of users and developers to contribute criticism, tickets (:P), and better code to the project.

that said, Sig Lane, I agree with what you said, there are certain operating systems that are shown more love than others in regard to chef.  FreeBSD being neglect shouldn't be anything new to ya :), I know how that goes.  I would definitely encourage you to file bugs it's the only slow and steady way to guarantee *bsd support gets better.

That and I'll even make you this guarantee, I will even take some of those tickets and supply fixes to some of the problems aforementioned as most of my servers home are FreeBSD -current.

Happy Hacking!

--sahil

On Sat, Sep 25, 2010 at 2:02 AM, Bryan McLellan < "> > wrote:

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