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 <jeremy.bo...@undergrid.net > 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 puppet-dev+unsubscr...@googlegroups.com. > 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 ashley.pen...@puppetlabs.com 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 puppet-dev+unsubscr...@googlegroups.com. 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.
