[chef] Re: Re: Re: Install specific chef version using omnibus

[Bryan McLellan < >]

On Wed, Sep 12, 2012 at 1:35 PM, Tim Smith 
<
 >
 wrote:
> Has Opscode put together a policy on retention of previous versions of
> Chef within the Omnibus installer?  I am a bit hesitant to use a script to
> install a very critical part of my infrastructure without certainty that
> the version I need will be there in the future.  Older versions of Chef 10
> are already missing from apt.opscode.com, but the use of debs allows
> anyone to archive off versions they rely on to a local repository.  That
> goes away if you rely on a script to install Chef.  While I'd like to
> always run the current release of Chef, parts of my infrastructure still
> run on Chef .9 and upgrading it tricky sometimes.  Will there be a posted
> lifecycle for each release?

Actually, Opscode doesn't delete any of the old versions of any of the
packages; Omnibus, rubygems or the deb packages.

--- Omnibus

Omnibus packages were beta until 10.12.0, when we announced Omnibus
shortly thereafter. This is why releases before 10.12.0 are not
included in the API endpoint for downloading.

http://www.opscode.com/blog/2012/06/19/chef-10-12-0-released/
http://www.opscode.com/blog/2012/06/29/omnibus-chef-packaging/

If someone wants the Omnibus beta releases, they can grab them out of
the S3 bucket, they're all still there:
https://opscode-full-stack.s3.amazonaws.com/

--- Rubygems

The gems on rubygems.org go back to 0.7.10 released in September 2009.
For anyone alive way back then, you might recall that rubygems.org had
a lot of stability issues in the past and we had our own gem server,
from which you can still get old gems (its actually an S3 bucket now).

http://rubygems.org/gems/chef/versions


$ gem list '^chef$' -r -a --source http://gems.opscode.com

*** REMOTE GEMS ***

chef (10.14.2, 10.14.0, 10.12.0, 0.10.10, 0.10.8, 0.10.6, 0.10.4,
0.10.2, 0.10.0, 0.9.18, 0.9.16, 0.9.14, 0.9.12, 0.9.10, 0.9.8, 0.9.6,
0.9.4, 0.9.2, 0.9.0, 0.8.16, 0.8.14, 0.8.10, 0.8.8, 0.8.6, 0.8.4,
0.8.2, 0.7.16 ruby, 0.7.14 ruby, 0.7.12 ruby, 0.7.10 ruby, 0.7.8,
0.7.4, 0.7.2, 0.7.0, 0.6.2, 0.6.0, 0.5.6, 0.5.4, 0.5.2, 0.5.1)

--- Debian packages

Debian archives are hard. Really they're just a file hierarchy with
some special files and signing, which should be easy, but this has led
to lots of tools that do just enough. We've been using reprepro for
quite some time, which creates the indexes and signs them, but it
doesn't support having more than one version of the same package in
the index it creates. Of course we use separate repositories for each
major release to allow folks to only get upgrades for their own
release if they're not pinning or using a local repository for
software management. We discovered that originally reprepro cleaned up
older versions, but we figured out how to turn that off, and there are
multiple versions of debian packages stored there.

http://apt.opscode.com/pool/main/c/chef/

Bryan