[Blueprint servercloud-q-chef] Getting Chef Back Into Ubuntu

[James Page]

Blueprint changed by James Page:

Whiteboard changed:
  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.
+  - 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.
+  - 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.
+ -- 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.
  
- [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=602697
- [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=620253
+ 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.

-- 
Getting Chef Back Into Ubuntu
https://blueprints.launchpad.net/ubuntu/+spec/servercloud-q-chef