Mysql cookbook: retrieving resource used in mysql_service hwrp with resources method

ohai chefs,

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:
http://vialstudios.logdown.com/posts/166848-the-environment-cookbook-pattern
so we include our company mysql wrapper cookbook inside our environment
cookbooks.

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

Any help will be appreciated.

Marco

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:
https://github.com/someara/mysql_usage_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:
https://github.com/someara/mysql_usage_example/blob/master/spec/unit/default_spec.rb

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.

https://github.com/opscode-cookbooks/mysql/blob/master/test/fixtures/cookbooks/mysql_test_custom/recipes/server.rb#L6

Hope that helps.....

-s

On Wed, May 21, 2014 at 9:14 AM, Marco Betti m.betti@gmail.com wrote:

ohai chefs,

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:

Logdown - Site Maintenance
so we include our company mysql wrapper cookbook inside our environment
cookbooks.

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:

https://github.com/opscode-cookbooks/mysql/blob/v5.2.12/libraries/provider_mysql_service_rhel.rb

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

Any help will be appreciated.

Marco

Sean,
Your kindness is amazing.
The whole design you depicted is very clear and I like so much new mysql flavour.

I also know that I can use template_source parameter and actually i am already doing it :slight_smile:
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 processes driven.

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 do.
'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 :slight_smile:

Any comment, criticism and/or advice is really appreciated.

Marco

Il giorno 21/mag/2014, alle ore 19:45, Sean OMeara someara@opscode.com ha scritto:

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:
https://github.com/someara/mysql_usage_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:
https://github.com/someara/mysql_usage_example/blob/master/spec/unit/default_spec.rb

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.

https://github.com/opscode-cookbooks/mysql/blob/master/test/fixtures/cookbooks/mysql_test_custom/recipes/server.rb#L6

Hope that helps.....

-s

On Wed, May 21, 2014 at 9:14 AM, Marco Betti m.betti@gmail.com wrote:
ohai chefs,

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:
Logdown - Site Maintenance
so we include our company mysql wrapper cookbook inside our environment cookbooks.

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:
https://github.com/opscode-cookbooks/mysql/blob/v5.2.12/libraries/provider_mysql_service_rhel.rb

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

Any help will be appreciated.

Marco

Hi Marco

The template resource will look in the current cookbook for its source....

So, when dropping off your site config, just ship the template you want to
use in your cookbook.

https://github.com/someara/mysql_usage_example/blob/master/recipes/example2.rb#L10
https://github.com/someara/mysql_usage_example/tree/master/templates/default

-s

On Wed, May 21, 2014 at 4:58 PM, Marco Betti m.betti@gmail.com wrote:

Sean,
Your kindness is amazing.
The whole design you depicted is very clear and I like so much new mysql
flavour.

I also know that I can use template_source parameter and actually i am
already doing it :slight_smile:
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
processes driven.

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
do.
'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 :slight_smile:

Any comment, criticism and/or advice is really appreciated.

Marco

Il giorno 21/mag/2014, alle ore 19:45, Sean OMeara someara@opscode.com
ha scritto:

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:
https://github.com/someara/mysql_usage_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:

https://github.com/someara/mysql_usage_example/blob/master/spec/unit/default_spec.rb

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.

https://github.com/opscode-cookbooks/mysql/blob/master/test/fixtures/cookbooks/mysql_test_custom/recipes/server.rb#L6

Hope that helps.....

-s

On Wed, May 21, 2014 at 9:14 AM, Marco Betti m.betti@gmail.com wrote:

ohai chefs,

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:

Logdown - Site Maintenance
so we include our company mysql wrapper cookbook inside our environment
cookbooks.

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:

https://github.com/opscode-cookbooks/mysql/blob/v5.2.12/libraries/provider_mysql_service_rhel.rb

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

Any help will be appreciated.

Marco

Thank you very much Sean.
I'm sorry for not giving a look properly to cookbook documentation
before...

RTFM strikes again :slight_smile:

Marco

On Fri, May 23, 2014 at 5:17 AM, Sean OMeara someara@opscode.com wrote:

Hi Marco

The template resource will look in the current cookbook for its source....

So, when dropping off your site config, just ship the template you want to
use in your cookbook.

https://github.com/someara/mysql_usage_example/blob/master/recipes/example2.rb#L10

https://github.com/someara/mysql_usage_example/tree/master/templates/default

-s

On Wed, May 21, 2014 at 4:58 PM, Marco Betti m.betti@gmail.com wrote:

Sean,
Your kindness is amazing.
The whole design you depicted is very clear and I like so much new mysql
flavour.

I also know that I can use template_source parameter and actually i am
already doing it :slight_smile:
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
processes driven.

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
do.
'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 :slight_smile:

Any comment, criticism and/or advice is really appreciated.

Marco

Il giorno 21/mag/2014, alle ore 19:45, Sean OMeara someara@opscode.com
ha scritto:

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:
https://github.com/someara/mysql_usage_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:

https://github.com/someara/mysql_usage_example/blob/master/spec/unit/default_spec.rb

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.

https://github.com/opscode-cookbooks/mysql/blob/master/test/fixtures/cookbooks/mysql_test_custom/recipes/server.rb#L6

Hope that helps.....

-s

On Wed, May 21, 2014 at 9:14 AM, Marco Betti m.betti@gmail.com wrote:

ohai chefs,

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:

Logdown - Site Maintenance
so we include our company mysql wrapper cookbook inside our environment
cookbooks.

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:

https://github.com/opscode-cookbooks/mysql/blob/v5.2.12/libraries/provider_mysql_service_rhel.rb

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

Any help will be appreciated.

Marco

--
Ing. Marco Betti
RHCE RHEL4 id 804006512121056

This is why we have a mailing list =)
-s

On Fri, May 23, 2014 at 3:22 AM, Marco Betti m.betti@gmail.com wrote:

Thank you very much Sean.
I'm sorry for not giving a look properly to cookbook documentation
before...

RTFM strikes again :slight_smile:

Marco

On Fri, May 23, 2014 at 5:17 AM, Sean OMeara someara@opscode.com wrote:

Hi Marco

The template resource will look in the current cookbook for its source....

So, when dropping off your site config, just ship the template you want
to use in your cookbook.

https://github.com/someara/mysql_usage_example/blob/master/recipes/example2.rb#L10

https://github.com/someara/mysql_usage_example/tree/master/templates/default

-s

On Wed, May 21, 2014 at 4:58 PM, Marco Betti m.betti@gmail.com wrote:

Sean,
Your kindness is amazing.
The whole design you depicted is very clear and I like so much new mysql
flavour.

I also know that I can use template_source parameter and actually i am
already doing it :slight_smile:
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
processes driven.

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
do.
'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 :slight_smile:

Any comment, criticism and/or advice is really appreciated.

Marco

Il giorno 21/mag/2014, alle ore 19:45, Sean OMeara someara@opscode.com
ha scritto:

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:
https://github.com/someara/mysql_usage_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:

https://github.com/someara/mysql_usage_example/blob/master/spec/unit/default_spec.rb

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.

https://github.com/opscode-cookbooks/mysql/blob/master/test/fixtures/cookbooks/mysql_test_custom/recipes/server.rb#L6

Hope that helps.....

-s

On Wed, May 21, 2014 at 9:14 AM, Marco Betti m.betti@gmail.com wrote:

ohai chefs,

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:

Logdown - Site Maintenance
so we include our company mysql wrapper cookbook inside our environment
cookbooks.

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:

https://github.com/opscode-cookbooks/mysql/blob/v5.2.12/libraries/provider_mysql_service_rhel.rb

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

Any help will be appreciated.

Marco

--
Ing. Marco Betti
RHCE RHEL4 id 804006512121056