Hi. This is going to be long... so brace yourself.
The README on the cookbook really needs to be shored up a bit to clear up confusion, since it implements a new(ish) pattern.. let's call it a "primitive cookbook".
A couple things... first, usage, and second, design. (I'll address your specific question towards the bottom)
Usage:
The blog post you referenced was written against an old version of the mysql cookbook. Unfortunately, following it step by step won't work. In particular, setting the node['mysql']['tunable'] attributes will have no effect... they have all been removed in favor of user supplied configuration.
The old version (pre 5.x series) implemented a mysql service with a recipes. The new version ships a mysql_service primitive. (think user, directory, cron, package, etc). It also ships a recipe that consumes said primitive.
The mysql_service resource loads a minimal configuration... just enough to get the service up and running. Beyond that, all customizations (like innodb_log_buffer_size), need to be placed in a file in your platform's conf.d directory.
See this cookbook for an example:
Design:
Mysql is a perfect example of a piece of software so complex, that attempting to provide a tweakable knob for every configuration option, across every platform, across every version, borders on insanity. To deal with this, we create a mysql_service primitive that is responsible for handing the business of getting the service running, then allows a DBA to drop in a configuration file with custom settings, like innodb_log_buffer_size.
mysql_service becomes an autonomous agent, who inner working are assumed to be unknown. It looks, smells, and feels like a core resource. It can be notified, and can notify when it repairs itself. It works across all platforms.
The fact that your platform's provider happenes to be implemented in Chef, (via use_inline_resources, with my.conf managed with a template resource) is an implementation detail. It could have very well been implemented in Pure Ruby (as the Chef core providers are), or by shelling out bash, python, or even assembly. The primitive repairing the service on every invocation is the important part.
Modifying an internal resource would be the moral equivalent of monkey patching a method in a core Chef resource to modify its behavior.
To be clear, it is purposefully opaque.
This comes with some benefits. For example, this spec represents %100 ChefSpec touch coverage:
All that being said, there is a way to customize the main my.cnf instead of dropping a file into the conf.d directory. There is a template_source parameter, that lets you use your own source, instead of the default. This is by design, and is built into the resource's interface, to remove the need for monkey patching.
Hope that helps.....