MySQL cookbook 5.0

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

-s

Hiya,

On Wed, Mar 26, 2014 at 10:28 PM, Sean OMeara 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

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 zts@cryptocracy.com wrote:

Hiya,

On Wed, Mar 26, 2014 at 10:28 PM, Sean OMeara 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

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 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 zts@cryptocracy.com wrote:

Hiya,

On Wed, Mar 26, 2014 at 10:28 PM, Sean OMeara someara@opscode.comwrote:

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