# MySQL cookbook 5.0

**URL:** <https://discourse.chef.io/t/mysql-cookbook-5-0/5171>\
**Category:** Chef Infra (archive)\
**Created:** [March 26, 2014, 10:28pm UTC](https://discourse.chef.io/t/mysql-cookbook-5-0/5171 "2014-03-26T22:28:54Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![Sean\_OMeara1](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/sean_omeara1/32/207_2.png) [@Sean\_OMeara1](https://discourse.chef.io/u/Sean_OMeara1)\
**Post date:** [March 26, 2014, 10:28pm UTC](https://discourse.chef.io/t/mysql-cookbook-5-0/5171/1 "2014-03-26T22:28:54Z")

</div>

Ohai there.

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.

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.

Check it out from git here:

[https://github.com/opscode-cookbooks/mysql/tree/tableflip](https://github.com/opscode-cookbooks/mysql/tree/tableflip)

-s

---

<div class="post-metadata">

**Author:** ![zts](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/zts/32/111_2.png) [@zts](https://discourse.chef.io/u/zts)\
**Post date:** [March 27, 2014, 11:28am UTC](https://discourse.chef.io/t/mysql-cookbook-5-0/5171/2 "2014-03-27T11:28:22Z")

</div>

Hiya,

On Wed, Mar 26, 2014 at 10:28 PM, Sean OMeara [someara@opscode.com](mailto:someara@opscode.com) 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

---

<div class="post-metadata">

**Author:** ![Sean\_OMeara1](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/sean_omeara1/32/207_2.png) [@Sean\_OMeara1](https://discourse.chef.io/u/Sean_OMeara1)\
**Post date:** [March 31, 2014, 11:03pm UTC](https://discourse.chef.io/t/mysql-cookbook-5-0/5171/3 "2014-03-31T23:03:39Z")

</div>

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](https://github.com/opscode-cookbooks/mysql/blob/tableflip/COMPAT.md)

-s

On Thu, Mar 27, 2014 at 7:28 AM, Zac Stevens [zts@cryptocracy.com](mailto:zts@cryptocracy.com) wrote:

> Hiya,
> 
> On Wed, Mar 26, 2014 at 10:28 PM, Sean OMeara [someara@opscode.com](mailto:someara@opscode.com) 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

---

<div class="post-metadata">

**Author:** ![zts](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/zts/32/111_2.png) [@zts](https://discourse.chef.io/u/zts)\
**Post date:** [April 2, 2014, 11:05am UTC](https://discourse.chef.io/t/mysql-cookbook-5-0/5171/4 "2014-04-02T11:05:17Z")

</div>

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 [someara@opscode.com](mailto:someara@opscode.com) 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](https://github.com/opscode-cookbooks/mysql/blob/tableflip/COMPAT.md)
> 
> -s
> 
> On Thu, Mar 27, 2014 at 7:28 AM, Zac Stevens [zts@cryptocracy.com](mailto:zts@cryptocracy.com) wrote:
> 
> > Hiya,
> > 
> > On Wed, Mar 26, 2014 at 10:28 PM, Sean OMeara [someara@opscode.com](mailto:someara@opscode.com)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