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.
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.
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.
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.