Your kindness is amazing.
The whole design you depicted is very clear and I like so much new mysql
I also know that I can use template_source parameter and actually i am
already doing it
Our use case is not so easy to explain: we are working to take CHEF and
devops in a traditional and legacy ICT company, not very agile but heavy
At the beginning of this year three different teams were set up: an
automation team that works to provide what we call “core cookbooks”, a team
that assembles core cookbooks into environment cookbooks to deploy
application stack infrastructures and a team that deploys applications
using the same environment cookbooks.
In this situation it is not so easy to spread necessary knowledge among
all these teams, so core-team is currently providing cookbooks whose
recipes need only to be included and configured via overridden attributes.
In this specific case Core-team provides ‘company_mysql’ cookbook, that
uses mysql_service resource inside a recipe inst_mysql that sets up and
manage mysql in our standard way.
Environment cookbook team provides ‘myface’ environment cookbook that
includes ‘company_mysql::inst_mysql’ like many other environment cookbooks
‘company_mysql::inst_mysql’ is a general recipe very easy to use (you just
have to include it).
The problem is that while ‘company_mysql::inst_mysql’ can use
’template_source’ parameter, no ‘template_cookbook’ parameter exists, so
when ‘myface’ includes ‘company_mysql::inst_mysql’ it can’t specify a
my.cnf template different from another environment cookbook (‘yourface’ for
example) also using the same core cookbook (‘company_mysql::inst_mysql’)
because template resource of mysql_service is taken from the cookbook that
uses it (‘company_mysql::inst_mysql’).
Off course a possible solution would be to drop ‘company_mysql’ core
cookbook and having our environment cookbooks to directly use
mysql_service, but our current approach is to let our company start using
CHEF lowering as much as possible complexity and learning curve.
My purpose wasn’t to modify a primitive resource internal, I just would
like there was a way to specify a ‘template_cookbook’ parameter also
Any comment, criticism and/or advice is really appreciated.
Il giorno 21/mag/2014, alle ore 19:45, Sean OMeara firstname.lastname@example.org
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
A couple things… first, usage, and second, design. (I’ll address your
specific question towards the bottom)
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
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
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
See this cookbook for an example:
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
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
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…
On Wed, May 21, 2014 at 9:14 AM, Marco Betti email@example.com wrote:
we made a company mysql wrapper cookbook that uses mysql cookbook hwrp in
order to be re-used from our mysql company installation (it does not
include server recipe of mysql cookbook).
We follow “environment cookbook” pattern:
so we include our company mysql wrapper cookbook inside our environment
We use CentOS and our issue is that we are not able to retrieve
’template’ resource used in mysql_service hwrp using resources method in
order to specify a different cookbook as a cookbook-source for the
’template’. See line 183:
Could anybody please help us to find a way to achieve this goal?
I think the solution (if present) is inside CHEF internals… but I can’t
Any help will be appreciated.