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

[Dylan Northrup < >]

Big thanks to Julian, Adam and Sean for the discussion and follow up.

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

On Tue, Jul 8, 2014 at 4:38 PM, Dylan Northrup < "> > wrote:
> On Tue, Jul 8, 2014 at 1:53 PM, Julian C. Dunn < "> > wrote:

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

Interesting. I'm not saying you're wrong here, it's a matter of
opinion, but my experience is that enterprise customers prefer the
information flow to go in the other direction: that they expect
ChefCo's consultants to show up armed with a filtered list of what OSS
people are doing, and what tends to work & what tends not to.

I don't think the information should flow in a single direction, but be bi-directional with the smart folks from ChefCo as pseudo traffic engineers helping guide people in the right direction to avoid possible traffic jams based on their higher level view of what's going on.  Open source learns what works in larger environments from enterprise and enterprise learns new (and possibly better) workflows from open source.

We've therefore been reluctant to clamp down on the OSS creativity --
some may call it chaos -- because the chaos leads to, and has led to,
interesting ideas, tools, and approaches. Perhaps I'm incorrect and
this community's expectations are different? I just think ChefCo has
explicitly NOT done that in the OSS space and we're unlikely to.

I'll give you an example: Jeremy Bingham has written a fully-fledged
Chef server in Go. Should ChefCo nip that in the bud because our
recommended Chef server is erchef? No, because it's an interesting
project and who knows, someone may find it useful, and anything that
contributes to the Chef ecosystem ultimately makes Chef stronger.

I don't think it would ever be the job/place of anyone to tell others "STOP DOING OPEN SOURCE" :-)  I like the previous statement about "moderating the crazy".  Some OSS stuff is crazy, whacky and completely inappropriate for children, animals and those with heart conditions.  However, some of it is interesting, brilliant and innovative.  I don't have time to keep an eye on the larger chef community and know what's good and what to keep away from my dog with a heart condition.  I've mostly relied on things bubbling up on the chef list (specifically looking for stuff Seth Vargo talks about/references since he seems to be a good bellwether for this sort of thing), hearing about cool things on the Food Fight Show and local DevOps meetups to become aware of new ideas.  Getting more of this is good for me (since it helps me save time on this so it can be used elsewhere).

I guess what I'm arguing is that if you participate in the OSS

ecosystem, you're likely to get better information about the state of
that ecosystem by asking on this mailing list & other OSS Chef fora
than by asking ChefCo employees directly about that. Then make up your
own mind.

And that's a completely valid response.  The more I put in, the more I get out.  Now, to convince my boss that reading e-mail lists is more important than feature X rolled out or updating service Y that's acting a bit wonky.  DevOpsLife!

 

I think we are discovering a number of things as the ecosystem evolves:

* The distribution of LWRPs (custom types) as part of cookbooks is not
optimal and maybe we should consider ingesting more of them into core
or distributing them as some other artifact type (this also addresses
some of the 'Ansible is easier to get started with' criticism that we
get)
* There are ways to write Chef cookbooks without them devolving into
total spaghetti recipe code by putting more things in LWRPs, HWRPs and
libraries to abstract them from recipe context.

To give you a sense of what a cookbook like that looks like, check out
the 'jenkins' or 'mysql' cookbooks. But we've also traded off the
reality that the code in there is not easily digestible by beginners.

Thanks for the pointers.  I'll take a look at those, see if I can digest them and also use them as exemplars for other folks internal to my organization.  Also, having learned through doing, I'll also say I've been remiss in not checking out learn.getchef.com to fill in whatever gaps might have cropped up for myself.

I'll probably go back into lurk mode after this, but much appreciation again for the exchange of ideas.