it is simple to lock cookbook versions, but it does not help with situations like yum and mysql... unless you are willing to be locked out of all new releases of other cookbooks that depend on these going forward, which is not very realistic.On Mon, Jul 20, 2015 at 9:54 AM, Yoshi Spendiff < " target="_blank"> > wrote:I think what Sean is trying to say, is that it's extremely simple to just specify a particular version requirement in the metadata.rb of a cookbook and no matter how you deploy your cookbooks (server/solo) you won't have to deal with this. If a new version breaks something then just specify a version look in the cookbook that depends on it.I use environments in my chef server to lock cookbook versions for all cookbooks, and only ever update this after a full testing pass, which would pick up any breakages like this. If something breaks then I specify the version I need in the metadata.rb of the cookbook that broke. In this case it wouldn't matter if I then deployed via solo or server, the metadata.rb version statement does it's job.--On Mon, Jul 20, 2015 at 6:27 AM, Nico Kadel-Garcia < " target="_blank"> > wrote:I'm afraid that the "multiple versions on the chef server" breaks down very badly very quickly. The backwards incompatible rewrites were most noticeable with the yum and mysql cookbooks are the prime ones, but minor such changes have happened with nagios, yumrepo, and tomcat in the last few years.
Nico Kadel-Garcia
Email: " target="_blank">
Sent from iPhone
> On Jul 19, 2015, at 13:31, "Sean OMeara" < " target="_blank"> > wrote:
>
> 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
> < " target="_blank"> > 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: " target="_blank">
>> Sent from iPhone
>>
>>> On Jul 17, 2015, at 14:46, "Noah Kantrowitz" < " target="_blank"> > 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: https://github.com/poise/poise-python. 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 https://github.com/poise/poise-python#quick-start. 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
>>>
Archive powered by MHonArc 2.6.16.