The Great Workflow RFC of 2014


#1

I have posted and RFC that proposes two ‘supported’ workflows for Chef.
This is my attempt to take the various pain-points enumerated on the list,
on irc, and on twitter over the last few weeks and propose a solution. In
watching and listening to folks frustrations with workflow, it feels like
you can boil it down to a few things:

  1. The monolithic chef-repo works great for a lot of people.
  2. The “Berkshelf Way” (as opposed to Berkshelf the tool) doesn’t solve
    a problem everyone feels they have. Meanwhile, for those who feel like they
    have that problem, they <3 it.
  3. We have put ourselves in an awkward spot, where much new tooling
    targets the Berkshelf Way implicitly.
  4. Regardless of the workflow, everyone wants the testing tools to work.
  5. Some folks dislike the Berkshelf implementation

This RFC proposes making two workflows “supported”, which means we expect
them to work all the time, be supported in documentation and the community,
and for tool builders to target them.

It also proposes adding generators and workflow commands to the 'chef’
command in Chef DK. This means we can make the target for documentation and
tool builders much smaller, as the work of noticing which workflow you
prefer is done by the tooling. Where there is overlap with knife, we are
going to subsume that functionality, and make it compatible at the options
level (and perhaps turn the knife plugins themselves into wrappers.)

Lets fix it! Let me know what I didn’t cover.

I’m explicitly not detailing implementation, or even putting effort in to
what the future might hold for either workflow, or a third workflow. Lets
document and standardize what we have, make the experience better, then we
can talk about improvements.

Adam


#2

FYI, the pull request is here: https://github.com/opscode/chef-rfc/pull/34


Daniel DeLeo

On Sunday, July 27, 2014 at 5:16 PM, Adam Jacob wrote:

I have posted and RFC that proposes two ‘supported’ workflows for Chef. This is my attempt to take the various pain-points enumerated on the list, on irc, and on twitter over the last few weeks and propose a solution. In watching and listening to folks frustrations with workflow, it feels like you can boil it down to a few things:
The monolithic chef-repo works great for a lot of people.
The “Berkshelf Way” (as opposed to Berkshelf the tool) doesn’t solve a problem everyone feels they have. Meanwhile, for those who feel like they have that problem, they <3 it.
We have put ourselves in an awkward spot, where much new tooling targets the Berkshelf Way implicitly.
Regardless of the workflow, everyone wants the testing tools to work.
Some folks dislike the Berkshelf implementation

This RFC proposes making two workflows “supported”, which means we expect them to work all the time, be supported in documentation and the community, and for tool builders to target them.

It also proposes adding generators and workflow commands to the ‘chef’ command in Chef DK. This means we can make the target for documentation and tool builders much smaller, as the work of noticing which workflow you prefer is done by the tooling. Where there is overlap with knife, we are going to subsume that functionality, and make it compatible at the options level (and perhaps turn the knife plugins themselves into wrappers.)

Lets fix it! Let me know what I didn’t cover.

I’m explicitly not detailing implementation, or even putting effort in to what the future might hold for either workflow, or a third workflow. Lets document and standardize what we have, make the experience better, then we can talk about improvements.

Adam


#3

I’ll write up the Berkshelf Way workflow today

On Mon, Jul 28, 2014 at 11:00 AM, Daniel DeLeo dan@kallistec.com wrote:

FYI, the pull request is here: https://github.com/opscode/chef-rfc/pull/34


Daniel DeLeo

On Sunday, July 27, 2014 at 5:16 PM, Adam Jacob wrote:

I have posted and RFC that proposes two ‘supported’ workflows for Chef. This is my attempt to take the various pain-points enumerated on the list, on irc, and on twitter over the last few weeks and propose a solution. In watching and listening to folks frustrations with workflow, it feels like you can boil it down to a few things:
The monolithic chef-repo works great for a lot of people.
The “Berkshelf Way” (as opposed to Berkshelf the tool) doesn’t solve a problem everyone feels they have. Meanwhile, for those who feel like they have that problem, they <3 it.
We have put ourselves in an awkward spot, where much new tooling targets the Berkshelf Way implicitly.
Regardless of the workflow, everyone wants the testing tools to work.
Some folks dislike the Berkshelf implementation

This RFC proposes making two workflows “supported”, which means we expect them to work all the time, be supported in documentation and the community, and for tool builders to target them.

It also proposes adding generators and workflow commands to the ‘chef’ command in Chef DK. This means we can make the target for documentation and tool builders much smaller, as the work of noticing which workflow you prefer is done by the tooling. Where there is overlap with knife, we are going to subsume that functionality, and make it compatible at the options level (and perhaps turn the knife plugins themselves into wrappers.)

Lets fix it! Let me know what I didn’t cover.

I’m explicitly not detailing implementation, or even putting effort in to what the future might hold for either workflow, or a third workflow. Lets document and standardize what we have, make the experience better, then we can talk about improvements.

Adam


#4

The independent software projects workflow is, in essence, the Berkshelf
Way - it’s just abstracted.

Adam

On Mon, Jul 28, 2014 at 9:06 AM, Sean OMeara someara@opscode.com wrote:

I’ll write up the Berkshelf Way workflow today

On Mon, Jul 28, 2014 at 11:00 AM, Daniel DeLeo dan@kallistec.com wrote:

FYI, the pull request is here:
https://github.com/opscode/chef-rfc/pull/34


Daniel DeLeo

On Sunday, July 27, 2014 at 5:16 PM, Adam Jacob wrote:

I have posted and RFC that proposes two ‘supported’ workflows for Chef.
This is my attempt to take the various pain-points enumerated on the list,
on irc, and on twitter over the last few weeks and propose a solution. In
watching and listening to folks frustrations with workflow, it feels like
you can boil it down to a few things:

The monolithic chef-repo works great for a lot of people.
The “Berkshelf Way” (as opposed to Berkshelf the tool) doesn’t solve a
problem everyone feels they have. Meanwhile, for those who feel like they
have that problem, they <3 it.

We have put ourselves in an awkward spot, where much new tooling
targets the Berkshelf Way implicitly.

Regardless of the workflow, everyone wants the testing tools to work.
Some folks dislike the Berkshelf implementation

This RFC proposes making two workflows “supported”, which means we
expect them to work all the time, be supported in documentation and the
community, and for tool builders to target them.

It also proposes adding generators and workflow commands to the 'chef’
command in Chef DK. This means we can make the target for documentation and
tool builders much smaller, as the work of noticing which workflow you
prefer is done by the tooling. Where there is overlap with knife, we are
going to subsume that functionality, and make it compatible at the options
level (and perhaps turn the knife plugins themselves into wrappers.)

Lets fix it! Let me know what I didn’t cover.

I’m explicitly not detailing implementation, or even putting effort in
to what the future might hold for either workflow, or a third workflow.
Lets document and standardize what we have, make the experience better,
then we can talk about improvements.

Adam