(MODULES-1685) permit use of mysql::db without mysql::server

[larsks]

This removes the hard dependencies on mysql::server from manifests/db.pp. This permits one to use this module to manage databases in an existing server, possibly located on a remote host (with a properly configured /root/.my.cnf).

The dependencies are instead placed in mysql/server.pp and are implemented using collectors, so that the dependencies are only created if mysql::server is realized.

[igalic]

i like this idea!
can you add some documentation and tests for this feature?

[larsks]

I've added a short blurb in the README. What sort of additional tests do you think I should add for this feature?

[igalic]

i'll be perfectly honest, i wouldn't now how to add tests for this myself :\

i'll hope @cmurphy will give it another look and then we should merge it.

[slamont]

This would be really helpful, in fact removing the coupling completely and giving the possibility to provide a remote host would greatly help.

When for example you want to install an application with puppet that would use an Amazon RDS Mysql, you would need to provide the remote host and the credentials of the admin users, and create schema and users for the application your installing. I would like to use this puppet module to do so.

[slamont]

For testing this, I would see 2 vagrant box, one would be a "mysql::server" and the other would use the first box hostname or ip to try to do the actions. Maybe there is a way to do this with Beaker https://github.com/puppetlabs/beaker/wiki I never tried that myself.

[underscorgan]

@larsks I think this could be tested by just making sure the catalog compiles and doesn't include mysql::server in the unit tests in https://github.com/puppetlabs/puppetlabs-mysql/blob/master/spec/defines/mysql_db_spec.rb

[hunner]

Instead of collectors, could you add autorequires for Class['mysql::server'] to the mysql_database and mysql_user types? Adding collectors without filters could do something bad for anyone using virtual resources, like creating all databases on all mysql servers.

[stamak]

@hunner It is not possible here due to the aim of patch: we want to use this define without defined class mysql::server(for remote server where mysql server is already installed)
I would offer to clean it up or at least leave as is

[hunner]

Closes MODULES-1685

[stamak]

I would like to see here

require  => defined(Class['mysql::server'])? {
                   true  => [ Class['mysql::server'], Class['mysql::client'] ],
                   false => [ Class['mysql::client'] ]
                },

[nelg]

We've been playing with the concept of using this module to manage RDS instances.

The problem with the above, which we ran into, was that it still only supports exactly 1 database server. When the databases are remote, it is quite possible that the could be more than one that we want to manage from a single instance running puppet.

So, ideally if support could be added to choose which .my.cnf file the module uses, for each resource, that would be ideal.

[danieldreier]

I just ran into a situation trying to use puppet to manage RDS databases where I would have needed this. I'll use this as soon as it's merged.

[igalic]

if somebody gives their 👍 for collector i'll rebase this patch, and add documentation that we're using unfiltered collection.

alternatively, i could also add a filter parameter

---

asked @DavidS in #puppethack, he agrees with hunner, and explained to me that an autorequire will work, regardless of the class being required.

(And i realized that Class is a "type", and mysql::server an instance of that type:)

[igalic]

closing in favour of #736