Nico,
Your repeated citing of the yum and mysql rewrites (1.5 and 1.3 years
ago, respectively) as a reason to avoid Chef Server make no sense.
Chef Server has nothing to do with cookbooks breaking APIs on major
revisions. If anything, it's argument FOR using a server, since it
functions as an artifact repo that can host multiple cookbook versions
simultaneously. As you mentioned, you can use Berkshelf and the
metadata system to lock down a Chef Environment. The Chef Server lets
you have multiple environments so you can test changes in isolation
without disturbing production.
For the record, Noah is doing the right thing here.
The yum and mysql cookbooks should have went through a period of
backwards-compat + deprecation warning. I'm sorry that caused you
frustration. However, there IS a point where things need to change,
and major version numbers are the place to do it.
-s
On Sun, Jul 19, 2015 at 12:01 AM, Nico Kadel-Garcia
nkadel@skyhookwireless.com wrote:
If you're going to flat- out break reverse compatibility, rename it. I had major grief with the mostly avoidable incompatibilities of older yum, which had the "yum::epel" recipe used by other major cookbooks, and splitting off yum-epel without leaving a yum::epel just to call yum-epel for backwards compatibility. And I'm afraid that the recent updates to "mysql", replacing the default mysql configurator with a mere LWRP, broke even more. By moving aside and hiding my.cnf from normal users, it broke socket based access and all the tools that used a default value or read /etc/my.cnf to find the socket.
The list if incompatible revised cookbooks is not small, and it's de-stabilizing. It makes upgrades if any component with dependencies unsafe, and forces admins to waste valuable testing resources and time.
Frankly, it's yet another reason to avoid chef servers and use chefdk with chef-solo. You can lock down Berksfile.lock and avoid mixed updates and old dependencies from breaking your whole environment.
Python is a critical system resource: please take the idea of renaming the cookbook to avoid incompatibilities seruously.
Nico Kadel-Garcia
Email: nkadel@gmail.com
Sent from iPhone
On Jul 17, 2015, at 14:46, "Noah Kantrowitz" noah@coderanger.net wrote:
Hi there everyone,
I'm the current maintainer of the python cookbook on Supermarket, and have been working on a major upgrade for it over the past few weeks: GitHub - poise/poise-python: A Chef cookbook to provide a unified interface for installing Python, managing Python packages, and creating virtualenvs.. The downside is this will break at least some compatibility with the old cookbook. The new cookbook does not currently support installing from source, though this is planned in the same way as poise-ruby-build works. My migration plan is to release the new cookbook under the poise-python name, and then release a new version of the python cookbook that acts as a compat wrapper around the new code. This means python_pip will be an alias for python_package and the old python::default recipe will continue to work. It is highly recommended that you prepare to switch your dependencies to the new cookbook, as the old one (python) will be deprecated.
On the positive note, poise-python adds long-requested features like multi-package installs, a resource for pip install -r, and better support for Python 3 and PyPy! You can check out the documentation for poise-python at GitHub - poise/poise-python: A Chef cookbook to provide a unified interface for installing Python, managing Python packages, and creating virtualenvs.. I welcome any and all feedback on poise-python, especially about missing or insufficient features, or any questions about the deprecation/migration.
tl;dr python cookbook is deprecated and being replaced by poise-python soon.
--Noah