[chef] Re: Re: Re: Re: An deep topic

[Dylan Northrup < >]

Just to be explicit, please preface all of this with "In my opinion" and "In my experience" as appropriate.

On Tue, Jul 8, 2014 at 1:53 PM, Julian C. Dunn < " target="_blank"> > wrote:

On Tue, Jul 8, 2014 at 1:08 PM, Dylan Northrup < "> > wrote:

>
> This here is a problem and one I asked about two years ago when we were
> doing a Chef Enterprise installation.
>
> Me: "Given situation Y, how do you do X?"
> Chef Engineer: "Well, whatever works for you."
>
> Wrong answer.  Better answer?
>
> Chef Engineer: "For the situation you describe, there are a few ways to go
> about it. Let's talk through them and discuss the benefits and downsides of
> each."
>
> Every time I've talked to an Opscode/Chef employee, there's been this
> tremendous reluctance to say "This is a way that should be successful to
> you".  Every time, and I do mean EVERY TIME EVEN WHEN PRESSED, there's never
> been someone who will say anything other than "There's lots of ways to do
> it. Whatever's good for your environment should work" or something to that
> effect.

It depends in what context you are asking, though.

* If you ask us, as part of a paying services engagement for *your*
company, the answer should be along the lines of the "better answer"
you outlined above.
* If you ask us generally in a public forum, where there are many
readers, the answer we'll give is probably along the lines of "there's
more than one way to do it".

I'll say that multiple times, even in a paying service engagement, the better answer has not happened.  I'll also say that in a public forum, the "TMTOWTDI" answer should be followed by "and here's some suggested ways for typical use cases".  And those answers, scrubbed of incriminating details, should be informed by the solutions provided to enterprise customers.  This helps guide everyone in a similar direction so that the community as a whole will tend to move in the same directions.

 

I think that's totally fair. If you are hiring us for professional

services, or have an enterprise services agreement with a CSE assigned
to your account, then our job is to "wrangle the open source crazy"
into something that you can use.

But open source software and the open source community is messy, by
definition. I don't think it's really fair to ask ChefCo to impose its
will on the ecosystem when people in the community are inventing tools
around Chef all the time & it is evolving. I feel like you're
conflating the two relationships.

As an enterprise customer, I want a stable configuration management platform and work flow to push code and configuration to my systems.

As an open source software user, I want to know the best practices for common scenarios.  I want this both so I am following methods others have been successful in using and so when I submit feature requests, code fixes and changes back, I will be doing so in a way that benefits the entire community (which is also, hopefully, following the lead of ChefCo) and not just myself.

As an ops guy with a programming background, I want a map of the green field so I know where the sink holes are so I can avoid them and where the paths are that others have used successfully (but which I may not be able to easily see).

And as a Chef user, I want ChefCo, who has the most visibility into implementations across a wide variety of locations, to be able to distill that down and provide advice to the larger user base to help guide us as a community so we can all move in roughly the same direction (at least with regards to the larger trends).

 

> Chef-DK, as an omnibus client setup, was an amazing stride toward this.  No
> longer did setting up a chef workstation involve installing ruby, grabbing
> the chef gem, installing various dependencies, making sure there weren't
> conflicts in those dependencies and doing this across many, many laptops and
> workstations.  I've got a stable client to have users interact with the chef
> server.  A simple way of getting to the point I can run 'knife sandwich
> make' or whatever.  And it only took how many years?

"it only took how many years" isn't totally fair because think about
it, so many of the parts that make a useful "DK" were only invented in
the last year.

I'll concede that Chef-DK includes more than the functionality I desired.  I do not in any way mean to demean or belittle the herculean effort that went into making it (because we were working on something similar in my larger organization and it's a right pain in the ass to do) and huge props to Dan DeLeo and company on getting this done.

That being said, not having an omnibus client installer was a gaping hole in the Opscode/ChefCo offering for quite a while.  Not having a straightforward, platform independent method for installing knife has been a huge hurdle for getting folks up to speed on chef.

 

They *should* be exemplars of good code. But often they are not. Would

we like them to be? Of course, but you can't erase 5 years of tech
debt overnight, and many of them date back to the days of HJK
Solutions, when we managed customer infrastructure with them. (I'm
assuming you mean the cookbooks under "opscode-cookbooks" when you say
"Chef site")

Also, many of those cookbooks were written before today's cookbook
authoring practices & TDD were extant. It's a little unfair to measure
old work products against today's yardstick.

In deference to paying down technical debt immediately (which, I agree, is not a reasonable expectation), I'd suggest having specific exemplars out there for cookbooks, LWRPs, etc. that can be pointed to as "shining cookbooks on a hill" on the site.  These could be used by others as guideposts in their own endeavors while old, creaky code is hand-waved away saying "Ignore that, we did that before we knew better".  Not all code needs to be good, but there do need to be examples folks can use to point the way.

 

> Opscode/ChefCo is the Source of Authority for implementations and, while
> it's awesome to have y'all be so open to suggestions from the community,
> that does not absolve you of the inherent responsibility.

I'd like to know more about what you feel ChefCo's "responsibility"
should be. As I mentioned above, I'd also strongly suggest that the
"duty of care" is different for a commercial relationship versus the
open source ecosystem.

I'd think one feeds into the other.  The needs of commercial clients provides use cases and solution spaces to test ideas, cookbooks, workflows, etc.  Once those practices have been fired in the crucible of actual day-to-day use, the survivors are used as suggestions to the greater community (either directly, or via the "shining code on a hill" method).  

I am, in no way, intending to impart a legal obligation to ChefCo to make Joe McOpensource's website work if Joe didn't pay anything to ChefCo.  But, as members of the greater community, I'd expect ChefCo to provide guidance in much the same way Linus does with Linux, that Tom Christiansen and Randal Schwartz have done for Perl, that Maxim Dounin does for nginx.  Suggest good ways of doing things and warn away from bad ways.  Point out de facto standards, and even help craft them.  Point in the right direction instead of saying "Whatever works for you" or something to that effect.  That's what I'd say is the "responsibility".  Not a legal obligation, but a social one.

And, again, all of this should be suffused with a large amount of "In My Opinion" and "In My Experience" as appropriate.