Getting Chef Back Into Ubuntu

Registered by Robbie Williamson

In 12.04 chef and ohai were removed from the Ubuntu archives at the request of the maintainer due to being outdated and unsupported.

OpsCode are working on getting the latest upstream versions of these packages into Debian.

We should aim to re-instate chef in 12.10.

Goal: Re-instate chef as a core part of the Ubuntu distribution for 12.10.

Blueprint information

Status:
Complete
Approver:
Antonio Rosales
Priority:
Medium
Drafter:
Ubuntu Server
Direction:
Approved
Assignee:
James Page
Definition:
Approved
Series goal:
Proposed for quantal
Implementation:
Implemented
Milestone target:
milestone icon quantal-alpha-3
Started by
James Page
Completed by
James Page

Related branches

Sprints

Whiteboard

Discussion Topics:

What issues lead to the packages being removed from precise?
 - Fast Chef development cycle over the last two years made current stable branch 0.10.x while precise still had 0.8.16.
 - solr package became out of date and broken, which blocked chef-solr [1]
-- james-page: which version of solr is required to support re-entry into the archive? is the current version sufficient or do we need to move to 3.6 (and associated lucene 3.6 release)? I can help with either scenario and solr 1.4 is not actually 'broken' - just a little negelected.
-- btm: "broken" was my summary of BTS #602697 [1] which justified pulling solr from debian squeeze. solr 1.4 should be fine, but we need to review the bugs against solr to ensure this won't happen again in the near future.

0.9.x - blocked by dependency upgrades.
0.10.x - DD on contract to refresh packaging.

Current blockers:
    merb - ruby-merb - working with debian-ruby team to resolve current issues.
How do we ensure that these don't re-occur to ensure the long term viability of chef as part of Ubuntu?
 - Maintaining chef in Debian will help with this.
   a) The debian pkg-ruby-extras team can use help, especially with the current transition
 - rails3 support in debian [2] for Chef 11
 - Recommending users of Ubuntu and Debian to use the packages (instead of gem installing) will also help.
   a) The differing release paradigm makes this problematic. With a goal of stability, debian/ubuntu follow a waterfall software development model of heavy testing and then a stable release with minor bug and security fixes as needed. On the contrary, Chef is under continuous development and improvement. The version of Chef in an LTS release will be severely out of date in a year. Providing individual bug patches (diffs) to this package would alone be very resource intensive, but major features will be missing which provides a large documentation issue. "use the 'foobarblah' resource, except if you're on Ubuntu LTS, then do it this way," cannot be achieved across all our documentation, let alone the blogs and howto's of the internet. The latter will be improved when we provide versioned documentation. Under the Ubuntu release model, this will necessitate that the user upgrade their distribution whenever they want the latest version of Chef, which is problematic for people running services in a production environment.
   b) Debian packages are the recommended installation method for Debian/Ubuntu, but using the Opscode apt repository due to the above issue.
   c) The recommended installation method in the future will be our full-stack installer, to provide a stable version of ruby (missing in most distributions, probably due to Ruby's release paradigm) alongside the latest version of Chef in the simplest installation method possible. "How software should be installed" is a matter of personal preference for many, and Opscode aims to continue supporting distribution level and gem packaging for those who prefer it.

-- james-page: backports might help a bit - which is what currently happens with puppet. But we need to consider ruby version dependencies etc.. if we go down this route.
-- james-page: can/did we generate/package documents as part of the package build process? Might help address the documentation concerns for the LTS version and any backports would get revised docs.

Main inclusion?
 - 5 years for the LTS
 - Challenge is that chef has a large number of external dependencies (unlike puppet).

User Stories:

Liam wants to implement configuration management within his Ubuntu infrastructure; he's used chef in the past and is able to easily use chef with Ubuntu 12.10 without installing additional repositories from OpsCode.

Assumptions:

- Required dependency issues can be resolved in Debian within the 12.10 development cycle.
- Future new dependencies can be managed to allow effective backporting to take place.
- Solr 1.5 can be polished sufficiently to allow entry back into wheezy (although this is not a direct blocker in Ubuntu).

Test Plan:

Chef is installable -
  sudo apt-get install chef

Release Note:

Chef 0.10.x is now avaliable as part of the Ubuntu 12.10 distribution, providing users with additional configuration management options.

(?)

Work Items

Work items:
[james-page] Generally keep a eye on progress in Debian and ensure syncs/blacklists allow this (esp milestones): DONE
[james-page] Sort out solr in Debian to help unblock Debian work: DONE
[btm] Check on whether solr 3.6 could be used with chef: DONE
[btm] Subscribe to relevant packages in ubuntu to help with communications (chef, ohai, *mixlib*): DONE

Dependency tree

* Blueprints in grey have been implemented.

This blueprint contains Public information 
Everyone can see this information.