Okay so I'm afraid I'm going to regret doing this but Dan was right that this is the best place for it. I thought about doing it on the dev list but figured there would be more (appropriate?) feedback here.
I don't think this fits with a blog post because (Dan is right here as well) that's dictation not discussion. I realize I'm an overly vocal critic of this topic but I've heard in private from quite a few folks about these same frustrations. I'll leave it up to them if they want to speak up. Some folks aren't comfortable with that though and feel like it would be burning a bridge. Please keep that in mind. Also please be aware that I'm going to point to specific statements by people but I'm not trying to call those people out and this should not be construed as a personal attack. I understand I can't stop people from feeling that way but I wanted to be clear about this.
So this is partly about Berkshelf and more about communication and workflow.
I originally posted a gist right around ChefConf this year about Berkshelf (
https://gist.github.com/lusis/10696647). My original criticisms were borne out of using omnibus but they apply to the chef toolchain as a whole. Some of those concerns have been partly addressed but some have not and in fact some have gotten worse.
I really think this whole issue boiled down to a lack of communication from Chef in some official capacity. I realize the reasons for NOT wanting to go on the record but at some point silence is complicity.
I understand that much of these changes have come out of the various community summits but I don't think it's unfair to say that the community summit was/is largely the vocal minority. And maybe that's okay but again based on my conversations with people, they feel entirely thrown for loop after loop.
So I'm going to frame these questions again (at least the ones that haven't been clarified for ME):
1) Is Berkshelf becoming a core chef dependency?
I heard no but let's be clear when ALL of the tooling coming out of Chef proper has a dependency on Berkshelf, that's no different. Also ChefDK doesn't solve that problem (especially since it's not actually released yet). Related is "The Berkshelf Way"/model the prescribed workflow for chef repos (note that I'm not saying cookbooks here for a reason).
2) What problem is Berkshelf trying to solve?
This is part of my frustration and other folks as well. The running joke is that Berkshelf solved a problem I didn't have. And it's true. Again I can totally accept that some people had a problem and found that Berkshelf solved it but is that reason enough to bake it into EVERYTHING?
FWIW I didn't have a problem with Berkshelf originally. One: I didn't use it and didn't HAVE to use it. Two: It didn't have this entirely new service it depended on.
Now I can't avoid it and it requires a separate internet service (though now apparently rolled into the supermarket) just to be used.
But this ties into bigger workflow questions. From almost every corner of the Chef proper universe (rough paraphrases):
"Berkshelf won"
"Stop doing devodd. Stop uploading unreleased artifacts to your Chef Servers"
"the separate repos per cookbook voice + Berkshelf is the loudest and with good reason"
"basically (in response to 'so individual cookbooks can be treated like district pieces of software?')"
"You don't have to change your workflow.. <two minutes passes> You have to change your workflow a bit"
And yet the Chef documentation is all over the place:
"The chef-dk defines a common workflow for cookbook development,
including unit and integration testing, identifying lint-like behavior,
dedicated tooling, and more"
"The chef-repo is located on a workstation and should be synchronized
with a version control system, such as git. All of the data in the
chef-repo should be treated like source code."
There is conflicting information here in that the docs describe one thing and yet there is semi-official direction/prescription/statements that you should use a single-cookbook-artifact-berkshelf-some-tool-that-isn't-actually-knife workflow.
But since this toolchain using this new workflow is so convoluted right now, there's ChefDK but it's not released yet and even if it was it's running an ENTIRELY different version of Ruby than the Omnibus chef-client.
And in the end there's, and I hesitated to mention this but it's a part of it, a profound level of arrogance about this workflow as a whole laced with "but you can keep doing it the OLD way" or "you'll eventually figure out the right workflow" or "Berkshelf fits every use case". But just a year ago there was ANOTHER way that was named the same thing but done differently and it's not the right way anymore.
As someone who is largely a run of the mill chef end-user (you can disagree with that. I have a larger than normal "voice" for better or worse), you have to appreciate the confusion here at the mixed messaging and "new shiny" every time I look up. As I've said before, Chef is a means to an end for me and not the defining thing. I don't like to fight my tools and when they keep fighting back I have to weigh the balance of how much time I invest with the tool versus getting actual work done. At some point, you figure out that you're fighting the wrong things.
And I realize that Chef is going through some transformative things right now and trying to get back to certain roots.
So what am I asking here? What's the point of this rambling?
Where's the communication? What's the intention? The post on Omnibus was awesome because it was clear. A line was drawn that said "look, omnibus was built for this and we think it's awesome that people are using it for this other thing but there's a conflict that we can't maintain"
I'm totally cool with that. What's hard for me is that when it comes to workflow, there's a defacto standard (driven by a vocal subset of the community and unofficially by Chef employees - my interpretation) that is infinitely more complicated than the one officially documented. And it's not just a question of workflow, it changes the entire model of how you use Chef when writing cookbooks (again in conflict with the official documentation).
I realize the desire to straddle both ways but at some point you can't when they diverge so dramatically. And really one of them is in largely direct opposition to the way of working that's even possible for a subset of the community. I feel like there's an entire chef middle class being cut out of this entire topic.
So am I asking for an "official workflow"? Part of me says no but part of me says "yes already. And then update the docs so I have somewhere to point new users that isn't being contradicted everywhere else". And frankly for me I almost want it to be done so I can make the difficult decisions around "is it time to move to another tool or not" because in the end my goal is pretty simple. I need to manage my servers and the tool that I have to fight the least to do that is the one I'm going to use.
Maybe I'm wrong about this. I could be the only person who feels this way but I don't think so.
Thanks for reading,
John E. Vincent