I would absolutely like us to explore breaking down some of these modules
into smaller pieces.  For -apache for example we've talked about breaking
out the vhost stuff, a lot of the more complex mod_* stuff, and so on into
separate modules.

Another piece to this that we've talked about internally is an ARM proposal
that Hunter was working on (I'll just throw him under a bus here) to
introduce a kind of include system that would allow you to do things like:

include puppetlabs-mysql as mysql
include mycustommodule-mysql::server as mysql::server

In order to make it easier to override parts of modules or just use pieces
of them.  I think something like this (He's got a much better
syntax/explanation somewhere) combined with smaller modules would go a long
way towards making them more usable.  We'd still probably ship a
meta-module that includes all of the smaller modules as a whole, but you'd
be able to just nab the types/providers or the backup piece or whatever you
needed.

To bring this back to mysql I guess I'd see:

mysql-provider
mysql-server
mysql-server-accounts
mysql-server-backup
mysql-client

As potential places to split a module like this into smaller bits.  It
would definitely be more complex to have a bunch of smaller modules and
ensure API compatibility between them all, but it's nothing that we
couldn't manage.  Do you have a suggestion on how detailed a split you'd
like to see for something like MySQL?


On Sat, Mar 1, 2014 at 10:26 AM, Jeremy T. Bouse <[email protected]
> wrote:

> On 01.03.2014 05:03, Gareth Rushgrove wrote:
>
>>
>> One of the questions/conversations that came up at Config Management
>> Camp around large modules like this one was: should/could they be
>> split up into multiple sub-modules?
>>
>> For instance one of the usecases was around managing mysql databases
>> without managing the mysql server, for instance in cases like Amazon
>> RDS or similar. Or I'd guess the opposite, manage the servers but let
>> others manage the databases (for instance in a multi-tenant
>> environment)
>>
>>
> I can echo this as a use case for most any database including MySQL and
> PostgreSQL. I do actually use RDS in some environments and there are other
> environments where the ability to do one or the other is desirable if not
> required and thus leave modules unable to perform that way not considered.
>
> Regards,
> Jeremy
>
> PS. Apologizes for the empty email earlier hit send too quickly.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/puppet-dev/e58569e96ca0273607ed3081caab15fa%40undergrid.net.
>
> For more options, visit https://groups.google.com/groups/opt_out.
>



-- 
Ashley Penney
[email protected]
Module Engineer

*Join us at PuppetConf 2014, September 23-24 in San Francisco*

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/CAC9eg%2B%3DxxNrgw4u2RdEVTw30iCXymWYYQ2JWB%3DB4_b3P_tHmJA%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to