[chef] Re: Re: Re: MySQL cookbook 5.0

[Zac Stevens < >]

Thanks Sean, that's a good COMPAT note and justification for the change in direction.

I don't entirely understand why `recipe[mysql::server]` doesn't implement the backwards compatibility of the attributes, given that any modern (5.0 and later) consumers of the cookbook could skip that recipe and use the `mysql_service` resource directly.  This is particularly an issue when there's no convenient way (that I'm aware of) of overriding include_recipe from a wrapper cookbook.

I think it would be nice to preserve a `mysql::ruby` recipe (which simply logged a deprecation warning before including `recipe[mysql-chef_gem]`).  That said, so long as `mysql-chef_gem` works with both 4.x and 5.x of the mysql cookbook (as it appears to do presently), it's not a big deal.

Zac

On Tue, Apr 1, 2014 at 12:03 AM, Sean OMeara < " target="_blank"> > wrote:

Hi.

Thanks for your feedback... I've added a COMPAT.md doc to try and address your concerns.

https://github.com/opscode-cookbooks/mysql/blob/tableflip/COMPAT.md

-s

On Thu, Mar 27, 2014 at 7:28 AM, Zac Stevens < " target="_blank"> > wrote:

Hiya,

On Wed, Mar 26, 2014 at 10:28 PM, Sean OMeara < " target="_blank"> > wrote:

In the next few days, I'm going to push the 5.0 version of the mysql cookbook.

It introduces some backwards incompatibility, so everyone make sure to lock down to the 4.x series until you have a chance adapt your code.

It would be helpful to get a list of what backwards incompatible changes have been made - reviewing a single huge commit with the changes makes it a bit difficult to keep track.

The things that stood out to me were that recipe[mysql::ruby] is now gone completely (does this functionality move elsewhere?), and a bunch of parameters for driving mysql configuration have been removed, and many resources will disappear from the main resource collection (as they're now in providers).  What else have I missed?

In the mean time, I'm looking for testers and feedback.

Highlights:

* mysql is now a library cookbook  - an example pattern for cross-platform resources.

* user supplied configuration - minimal main configuration, with an includedir directive

* Full RHEL, Debian, and Ubuntu, support.

* Illumos coverage for SmartOS and OmniOS

* tests, tests, tests, and more tests.

Positive Feedback:

 * tests are awesome

 * expanded platform coverage is great

 * I was initially turned off by the amount of repetition across the providers and tests, though it does make it easier to follow when you're trying to understand the behaviour of a single platform

Now, negative feedback.  This doesn't look like a new version of the mysql cookbook.  It looks like a new cookbook that's planning to kill the existing mysql cookbook and steal its identity.

No matter what, refactoring recipes into providers would require a major version bump - anyone currently reopening resources in those recipes will need to find another solution for whatever they're doing.  I'm okay with that.  On the other hand, dropping support for the current attribute-driven configuration is hard to forgive - and removal of the ::ruby recipe is so gratuitous I'm wondering whether it's actually an oversight.

It doesn't seem right that _every_ user of the mysql cookbook would need to make changes.  It would be useful to have a clear idea of which users will need to - and I expect they would appreciate knowing why backwards compatibility wasn't possible for their use cases.

Zac