Stove v3.0.0 (Stainless Steel Edition)


#1

Ohai Chefs!

To coincide with the new launch of Supermarket, I’m excited to announce Stove v3.0.0 has landed in your Kitchen. It’s bright, shiny, stainless steel, and uses the latest convection cooking technologies for ultimate pleasure.

Stove 3.0 includes a number of important changes:

Publish to Supermarket by default
Added support for signed tags (thanks Noah!)
Require Ruby 1.9+
Remove a bunch of dependencies (i18n, mixlib-authentication, solve, octokit, jiralicious, faraday, and more)
Remove GitHub functionality (you can still push git tags, but not artifacts)
Remove JIRA functionality (JIRA IS DEAD!)
Remove bump functionality
Remove devodd functionality

There are also a number of bug fixes:

Clarify use of Gemfile vs non-Gemfile
Always read cookbooks as binary objects
Ensure tempfiles are written with the proper mime_type
Do not package editor files

Frequently Asked Questions

Q: Why did you remove bump functionality?
A: You, as a cookbook maintainer, should make an intelligent decision about the version you wish to create. You should version and commit that change as part of your workflow.

Q: Why did you remove the devodd functionality?
A: Before a land of Test Kitchen and Chef Zero, you would often test a cookbook by uploading to a production Chef Server and running some tests. Those days are gone. I have never been a fan of devodd, and I cannot continue to encourage its use by making it a part of a tool I manufacture. Stop doing devodd. Stop uploading unreleased artifacts to your Chef Servers :).

Q: Why did you remove the GitHub artifacts?
A: There are actually a few reasons: First, and most importantly, GitHub has changed their releases API on more than one occasion. Second, it is an incredibly expensive operation - requiring multiple HTTP requests. The “slowness” often experienced was due to the multiple roundtrips required to push an artifact as a “release” to GitHub. Third, I believe Stove should support git, not a third-party hosting provider. I do not wish to propagate the notion that GitHub is a required part of the Chef toolchain. Fourth, in order to better track downloads and usage, you should download cookbooks from an authoritative source.

Q: Why did you remove the JIRA functionality?
A: Didn’t you hear? JIRA is dead! In all actuality, the JIRA functionality was a Chef/Opscode-specific thing. It was really selfish of me to include in Stove, and probably never should have been there in the first place.

Q: Why did you require Ruby 1.9+?
A: Because Ruby 1.8 is dead. Omnibus is 1.9. ChefDK is 2.1.

Q: Why did you remove all those dependencies?
A: There was some controversy over using Stove as a dependency in a project. By minimizing the number of dependencies, it is now again possible to use Stove in your Gemfile. I’ve update the documentation and examples as such.

Q: Can I share with my behind-the-firewall solution?
A: If you are running a behind-the-firewall solution (such as Supermarket), that follows the cookbooks API and mixlib-authentication signed header auth schema, it will continue to work with the new stove.

Q: Is it faster?
A: Yes, like 50x faster

Thanks,
Seth


#2

On Mon, Jul 7, 2014 at 9:25 PM, Seth Vargo sethvargo@getchef.com wrote:

Ohai Chefs!

To coincide with the new launch of Supermarket, I’m excited to announce
Stove v3.0.0 has landed in your Kitchen. It’s bright, shiny, stainless
steel, and uses the latest convection cooking technologies for ultimate
pleasure.

Nice! thanks Seth :slight_smile:

Q: Why did you remove the devodd functionality?

A: Before a land of Test Kitchen and Chef Zero, you would often test a
cookbook by uploading to a production Chef Server and running some tests.
Those days are gone. I have never been a fan of devodd, and I cannot
continue to encourage its use by making it a part of a tool I manufacture.
Stop doing devodd. Stop uploading unreleased artifacts to your Chef Servers
:).

Humm… I don’t agree with this.

devodd isn’t only used for testing, it’s also used when you are waiting for
a PR to be merged. In you case it’s prod ready (so it’s on your
chef-server), but it’s not for community. And you may have really bad day
if you increment version on your own… (I can give some example if
needed).

IMPOV, devodd can only be removed when chef will accept suffix version
(like “-dev” or “-myPR”). But I’m not a huge fan of suffix (how to compare
between them?).


#3

On Tue, Jul 8, 2014 at 12:42 PM, Guilhem Lettron guilhem@lettron.fr wrote:

On Mon, Jul 7, 2014 at 9:25 PM, Seth Vargo sethvargo@getchef.com wrote:

Q: Why did you remove the devodd functionality?
A: Before a land of Test Kitchen and Chef Zero, you would often test a
cookbook by uploading to a production Chef Server and running some tests.
Those days are gone. I have never been a fan of devodd, and I cannot
continue to encourage its use by making it a part of a tool I manufacture.
Stop doing devodd. Stop uploading unreleased artifacts to your Chef Servers
:).

Humm… I don’t agree with this.

devodd isn’t only used for testing

What is devodd?

-aob


#4

What is devodd?

A couple of years ago, the maintainer of most of the Opscode-curated
cookbooks wrote up a blog 1 on a workflow tool I had written, to his
specification. (currently unmaintained)
He had adopted an Odd-Numbered Release versioning method, common in the
Linux Kernel 2 to denote what is ‘stable’ and what is in development.

This was a good approach, when applied unilaterally and mentioned LOUDLY,
especially since the cookbook artifacts do not provide any method for
version identifiers beyond X.Y.Z - other packaging systems struggle with
more identifiers and their comparison, it’s a hard problem to solve when
not every tool in the ecosystem speaks the same version language.

At that time, it was very clear what versions were ‘stable’ and what were
not. If you look at a cookbook like nginx 3, and see the 'Versions’
dropdown, you will see that only even-numbered artifacts have been uploaded
as “releases”.

In many open source projects, you may see the following behavior:

  • release version 1.0.0
  • bump version for development to 1.1.0.dev

(or similar)

This allows users to opt-in to the ‘bleeding edge’ code, i.e. “This is not
stable, it may eat your servers!”.

Versions have been a long-running painful discussion throughout Chef
ecosystem. It’s a topic that comes up all the time.

As the maintainer of Stove, Seth is the one driving the vision behind it -
and as such has explained his reasoning for removal of that flag from the
tool in his email above.
I don’t think it maps to the same problem that we face with open source
code and development versions of cookbooks, but that’s his choice, and we
can disagree - that’s the best part of Open Source - I can fork his code
and rename to to be “dutch-oven” if I want to. :slight_smile:

Hope this provides some background on the ‘devodd’ term that I
invented/introduced into Chef-land in 2012.

Best,
-M

On Tue, Jul 8, 2014 at 8:37 AM, Angus Buchanan angus.o.buchanan@gmail.com
wrote:

On Tue, Jul 8, 2014 at 12:42 PM, Guilhem Lettron guilhem@lettron.fr
wrote:

On Mon, Jul 7, 2014 at 9:25 PM, Seth Vargo sethvargo@getchef.com wrote:

Q: Why did you remove the devodd functionality?
A: Before a land of Test Kitchen and Chef Zero, you would often test a
cookbook by uploading to a production Chef Server and running some tests.
Those days are gone. I have never been a fan of devodd, and I cannot
continue to encourage its use by making it a part of a tool I manufacture.
Stop doing devodd. Stop uploading unreleased artifacts to your Chef Servers
:).

Humm… I don’t agree with this.

devodd isn’t only used for testing

What is devodd?

-aob


#5

After fiddling some knobs, I got stove working for the most part except for
this one error I can’t figure out: {"error"=>"INVALID_DATA", "error_messages"=>["Version constraint is not a valid Chef version constraint"]}

I can’t figure out why I’m getting this error. My metadata looks good as
far as I can tell. I am authenticating fine and github gets the tags and
such, but it seems like supermarket doesn’t like my release.

Does anyone have any ideas?

On Tue, Jul 8, 2014 at 8:05 AM, Mike miketheman@gmail.com wrote:

What is devodd?

A couple of years ago, the maintainer of most of the Opscode-curated
cookbooks wrote up a blog 1 on a workflow tool I had written, to his
specification. (currently unmaintained)
He had adopted an Odd-Numbered Release versioning method, common in the
Linux Kernel 2 to denote what is ‘stable’ and what is in development.

This was a good approach, when applied unilaterally and mentioned LOUDLY,
especially since the cookbook artifacts do not provide any method for
version identifiers beyond X.Y.Z - other packaging systems struggle with
more identifiers and their comparison, it’s a hard problem to solve when
not every tool in the ecosystem speaks the same version language.

At that time, it was very clear what versions were ‘stable’ and what were
not. If you look at a cookbook like nginx 3, and see the 'Versions’
dropdown, you will see that only even-numbered artifacts have been uploaded
as “releases”.

In many open source projects, you may see the following behavior:

  • release version 1.0.0
  • bump version for development to 1.1.0.dev

(or similar)

This allows users to opt-in to the ‘bleeding edge’ code, i.e. “This is not
stable, it may eat your servers!”.

Versions have been a long-running painful discussion throughout Chef
ecosystem. It’s a topic that comes up all the time.

As the maintainer of Stove, Seth is the one driving the vision behind it -
and as such has explained his reasoning for removal of that flag from the
tool in his email above.
I don’t think it maps to the same problem that we face with open source
code and development versions of cookbooks, but that’s his choice, and we
can disagree - that’s the best part of Open Source - I can fork his code
and rename to to be “dutch-oven” if I want to. :slight_smile:

Hope this provides some background on the ‘devodd’ term that I
invented/introduced into Chef-land in 2012.

Best,
-M

On Tue, Jul 8, 2014 at 8:37 AM, Angus Buchanan <angus.o.buchanan@gmail.com

wrote:

On Tue, Jul 8, 2014 at 12:42 PM, Guilhem Lettron guilhem@lettron.fr
wrote:

On Mon, Jul 7, 2014 at 9:25 PM, Seth Vargo sethvargo@getchef.com
wrote:

Q: Why did you remove the devodd functionality?
A: Before a land of Test Kitchen and Chef Zero, you would often test a
cookbook by uploading to a production Chef Server and running some tests.
Those days are gone. I have never been a fan of devodd, and I cannot
continue to encourage its use by making it a part of a tool I manufacture.
Stop doing devodd. Stop uploading unreleased artifacts to your Chef Servers
:).

Humm… I don’t agree with this.

devodd isn’t only used for testing

What is devodd?

-aob


#6

On Tue, Jul 8, 2014 at 5:43 PM, BK Box bk@theboxes.org wrote:

After fiddling some knobs, I got stove working for the most part except for
this one error I can’t figure out: {"error"=>"INVALID_DATA", "error_messages"=>["Version constraint is not a valid Chef version constraint"]}

I can’t figure out why I’m getting this error. My metadata looks good as far
as I can tell. I am authenticating fine and github gets the tags and such,
but it seems like supermarket doesn’t like my release.

Does anyone have any ideas?

I’m getting that too, so for now I’ve opened
https://github.com/sethvargo/stove/issues/41 for now. Maybe there’s a
Supermarket bug, but stove doesn’t take ‘-VV’ so I’ll need some of
Seth Vargo’s advice as to what to pry to track this down.

  • Julian


[ Julian C. Dunn jdunn@aquezada.com * Sorry, I’m ]
[ WWW: http://www.aquezada.com/staff/julian * only Web 1.0 ]
[ gopher://sdf.org/1/users/keymaker/ * compliant! ]
[ PGP: 91B3 7A9D 683C 7C16 715F 442C 6065 D533 FDC2 05B9 ]


#7

Julian,

Thanks for opening the issue. I just got caught up and started following it
as well. I’m pretty sure I saw this issue with knife-supermarket as well,
but I’d have to test again.

On Tue, Jul 8, 2014 at 10:30 PM, Julian C. Dunn jdunn@aquezada.com wrote:

On Tue, Jul 8, 2014 at 5:43 PM, BK Box bk@theboxes.org wrote:

After fiddling some knobs, I got stove working for the most part except
for
this one error I can’t figure out: {"error"=>"INVALID_DATA", "error_messages"=>["Version constraint is not a valid Chef version constraint"]}

I can’t figure out why I’m getting this error. My metadata looks good as
far
as I can tell. I am authenticating fine and github gets the tags and
such,
but it seems like supermarket doesn’t like my release.

Does anyone have any ideas?

I’m getting that too, so for now I’ve opened
https://github.com/sethvargo/stove/issues/41 for now. Maybe there’s a
Supermarket bug, but stove doesn’t take ‘-VV’ so I’ll need some of
Seth Vargo’s advice as to what to pry to track this down.

  • Julian


[ Julian C. Dunn jdunn@aquezada.com * Sorry, I’m ]
[ WWW: http://www.aquezada.com/staff/julian * only Web 1.0 ]
[ gopher://sdf.org/1/users/keymaker/ * compliant! ]
[ PGP: 91B3 7A9D 683C 7C16 715F 442C 6065 D533 FDC2 05B9 ]


#8

Per the discussion on the issue, it’s a Stove bug where it doesn’t
convert unconstrained deps into constrained ones (even ‘>= 0.0.0’)
when making the metadata.json. Feel free to take a whack at fixing it
if you like; I won’t have time this week :slight_smile:

‘knife cookbook site share’ has the correct behavior.

  • Julian

On Wed, Jul 9, 2014 at 11:12 PM, BK Box bk@theboxes.org wrote:

Julian,

Thanks for opening the issue. I just got caught up and started following it
as well. I’m pretty sure I saw this issue with knife-supermarket as well,
but I’d have to test again.

On Tue, Jul 8, 2014 at 10:30 PM, Julian C. Dunn jdunn@aquezada.com wrote:

On Tue, Jul 8, 2014 at 5:43 PM, BK Box bk@theboxes.org wrote:

After fiddling some knobs, I got stove working for the most part except
for
this one error I can’t figure out: {"error"=>"INVALID_DATA", "error_messages"=>["Version constraint is not a valid Chef version constraint"]}

I can’t figure out why I’m getting this error. My metadata looks good as
far
as I can tell. I am authenticating fine and github gets the tags and
such,
but it seems like supermarket doesn’t like my release.

Does anyone have any ideas?

I’m getting that too, so for now I’ve opened
https://github.com/sethvargo/stove/issues/41 for now. Maybe there’s a
Supermarket bug, but stove doesn’t take ‘-VV’ so I’ll need some of
Seth Vargo’s advice as to what to pry to track this down.

  • Julian


[ Julian C. Dunn jdunn@aquezada.com * Sorry, I’m ]
[ WWW: http://www.aquezada.com/staff/julian * only Web 1.0 ]
[ gopher://sdf.org/1/users/keymaker/ * compliant! ]
[ PGP: 91B3 7A9D 683C 7C16 715F 442C 6065 D533 FDC2 05B9 ]


[ Julian C. Dunn jdunn@aquezada.com * Sorry, I’m ]
[ WWW: http://www.aquezada.com/staff/julian * only Web 1.0 ]
[ gopher://sdf.org/1/users/keymaker/ * compliant! ]
[ PGP: 91B3 7A9D 683C 7C16 715F 442C 6065 D533 FDC2 05B9 ]


#9

I had planned on attempting a patch, but it looks like Seth already beat me
to it. Thanks a ton Seth! I’m able to release cookbooks to Supermarket with
Stove again.

Thanks again.

On Thu, Jul 10, 2014 at 7:20 AM, Julian C. Dunn jdunn@aquezada.com wrote:

Per the discussion on the issue, it’s a Stove bug where it doesn’t
convert unconstrained deps into constrained ones (even ‘>= 0.0.0’)
when making the metadata.json. Feel free to take a whack at fixing it
if you like; I won’t have time this week :slight_smile:

‘knife cookbook site share’ has the correct behavior.

  • Julian

On Wed, Jul 9, 2014 at 11:12 PM, BK Box bk@theboxes.org wrote:

Julian,

Thanks for opening the issue. I just got caught up and started following
it
as well. I’m pretty sure I saw this issue with knife-supermarket as well,
but I’d have to test again.

On Tue, Jul 8, 2014 at 10:30 PM, Julian C. Dunn jdunn@aquezada.com
wrote:

On Tue, Jul 8, 2014 at 5:43 PM, BK Box bk@theboxes.org wrote:

After fiddling some knobs, I got stove working for the most part
except

for
this one error I can’t figure out: {"error"=>"INVALID_DATA", "error_messages"=>["Version constraint is not a valid Chef version constraint"]}

I can’t figure out why I’m getting this error. My metadata looks good
as

far
as I can tell. I am authenticating fine and github gets the tags and
such,
but it seems like supermarket doesn’t like my release.

Does anyone have any ideas?

I’m getting that too, so for now I’ve opened
https://github.com/sethvargo/stove/issues/41 for now. Maybe there’s a
Supermarket bug, but stove doesn’t take ‘-VV’ so I’ll need some of
Seth Vargo’s advice as to what to pry to track this down.

  • Julian


[ Julian C. Dunn jdunn@aquezada.com * Sorry, I’m ]
[ WWW: http://www.aquezada.com/staff/julian * only Web 1.0 ]
[ gopher://sdf.org/1/users/keymaker/ * compliant! ]
[ PGP: 91B3 7A9D 683C 7C16 715F 442C 6065 D533 FDC2 05B9 ]


[ Julian C. Dunn jdunn@aquezada.com * Sorry, I’m ]
[ WWW: http://www.aquezada.com/staff/julian * only Web 1.0 ]
[ gopher://sdf.org/1/users/keymaker/ * compliant! ]
[ PGP: 91B3 7A9D 683C 7C16 715F 442C 6065 D533 FDC2 05B9 ]


#10

Thank you for explaining the history Mike. I’ve been swamped with work and had been meaning to respond to this email, but then I saw your history and was like ‘phew - someone else did it :)’

Just to be clear - you can still use devodd. There’s nothing stopping you from editing the version in your metadata.rb and commit to SCM - I am simply choosing not to encourage this workflow as part of Stove. I think it has bad repercussions and assumptions baked in (no pun intended).

If you’re interested in a tool that supports devodd, Mike actually has one called knife-community1.

On Jul 8, 2014, at 9:05 AM, Mike miketheman@gmail.com wrote:

What is devodd?

A couple of years ago, the maintainer of most of the Opscode-curated cookbooks wrote up a blog 1 on a workflow tool I had written, to his specification. (currently unmaintained)
He had adopted an Odd-Numbered Release versioning method, common in the Linux Kernel 2 to denote what is ‘stable’ and what is in development.

This was a good approach, when applied unilaterally and mentioned LOUDLY, especially since the cookbook artifacts do not provide any method for version identifiers beyond X.Y.Z - other packaging systems struggle with more identifiers and their comparison, it’s a hard problem to solve when not every tool in the ecosystem speaks the same version language.

At that time, it was very clear what versions were ‘stable’ and what were not. If you look at a cookbook like nginx 3, and see the ‘Versions’ dropdown, you will see that only even-numbered artifacts have been uploaded as “releases”.

In many open source projects, you may see the following behavior:

  • release version 1.0.0
  • bump version for development to 1.1.0.dev

(or similar)

This allows users to opt-in to the ‘bleeding edge’ code, i.e. “This is not stable, it may eat your servers!”.

Versions have been a long-running painful discussion throughout Chef ecosystem. It’s a topic that comes up all the time.

As the maintainer of Stove, Seth is the one driving the vision behind it - and as such has explained his reasoning for removal of that flag from the tool in his email above.
I don’t think it maps to the same problem that we face with open source code and development versions of cookbooks, but that’s his choice, and we can disagree - that’s the best part of Open Source - I can fork his code and rename to to be “dutch-oven” if I want to. :slight_smile:

Hope this provides some background on the ‘devodd’ term that I invented/introduced into Chef-land in 2012.

Best,
-M

On Tue, Jul 8, 2014 at 8:37 AM, Angus Buchanan angus.o.buchanan@gmail.com wrote:
On Tue, Jul 8, 2014 at 12:42 PM, Guilhem Lettron guilhem@lettron.fr wrote:
On Mon, Jul 7, 2014 at 9:25 PM, Seth Vargo sethvargo@getchef.com wrote:
Q: Why did you remove the devodd functionality?
A: Before a land of Test Kitchen and Chef Zero, you would often test a cookbook by uploading to a production Chef Server and running some tests. Those days are gone. I have never been a fan of devodd, and I cannot continue to encourage its use by making it a part of a tool I manufacture. Stop doing devodd. Stop uploading unreleased artifacts to your Chef Servers :).

Humm… I don’t agree with this.

devodd isn’t only used for testing

What is devodd?

-aob


#11

This has been fixed and a new Stove has been released.

As an aside, I do not monitor the Chef mailing list as closely as I monitor GitHub issues. I respond to most GitHub issues in < 24 hours, but I read the mailing list about once every day or two. If these bugs arise again, please open issues on GitHub; I’m more likely to see them sooner :).

Thanks,
Seth

On Jul 10, 2014, at 8:20 AM, Julian C. Dunn jdunn@aquezada.com wrote:

Per the discussion on the issue, it’s a Stove bug where it doesn’t
convert unconstrained deps into constrained ones (even ‘>= 0.0.0’)
when making the metadata.json. Feel free to take a whack at fixing it
if you like; I won’t have time this week :slight_smile:

‘knife cookbook site share’ has the correct behavior.

  • Julian

On Wed, Jul 9, 2014 at 11:12 PM, BK Box bk@theboxes.org wrote:

Julian,

Thanks for opening the issue. I just got caught up and started following it
as well. I’m pretty sure I saw this issue with knife-supermarket as well,
but I’d have to test again.

On Tue, Jul 8, 2014 at 10:30 PM, Julian C. Dunn jdunn@aquezada.com wrote:

On Tue, Jul 8, 2014 at 5:43 PM, BK Box bk@theboxes.org wrote:

After fiddling some knobs, I got stove working for the most part except
for
this one error I can’t figure out: {"error"=>"INVALID_DATA", "error_messages"=>["Version constraint is not a valid Chef version constraint"]}

I can’t figure out why I’m getting this error. My metadata looks good as
far
as I can tell. I am authenticating fine and github gets the tags and
such,
but it seems like supermarket doesn’t like my release.

Does anyone have any ideas?

I’m getting that too, so for now I’ve opened
https://github.com/sethvargo/stove/issues/41 for now. Maybe there’s a
Supermarket bug, but stove doesn’t take ‘-VV’ so I’ll need some of
Seth Vargo’s advice as to what to pry to track this down.

  • Julian


[ Julian C. Dunn jdunn@aquezada.com * Sorry, I’m ]
[ WWW: http://www.aquezada.com/staff/julian * only Web 1.0 ]
[ gopher://sdf.org/1/users/keymaker/ * compliant! ]
[ PGP: 91B3 7A9D 683C 7C16 715F 442C 6065 D533 FDC2 05B9 ]


[ Julian C. Dunn jdunn@aquezada.com * Sorry, I’m ]
[ WWW: http://www.aquezada.com/staff/julian * only Web 1.0 ]
[ gopher://sdf.org/1/users/keymaker/ * compliant! ]
[ PGP: 91B3 7A9D 683C 7C16 715F 442C 6065 D533 FDC2 05B9 ]