On 28 February 2014 18:56, Ashley Penney <ashley.pen...@puppetlabs.com> wrote: > MySQL Roadmap/Redesign > > [This email follows a consensus amongst people attending the Module Triages > that we would like to explore the possibility of cutting edge engineering > techniques such as "design before you start mashing manifests together" and > "lets ask the public what features they'd like before deciding on their > behalf". As such this is an attempt at pulling together an initial > explanation of the pain points of the current module and where we should go > from here.] > > Background > > The puppetlabs-mysql (we'll refer to it simple as the mysql module from now > on) module accreted from a number of PRs that solved immediate and instant > pain points for users over a number of years. A couple of months back I > took a stab at a fairly large refactoring of the module. The two things I > wanted to solve was: > > * Improve the type/providers so they could be used via puppet resource and > fix numerous bugs. > * Rewrite the module to follow our fledgling best practices. > * Make it possible to pass in arbitrary configuration values so we didn't > need a parameter per my.cnf entry. > > This refactoring/rewrite semi-worked. It exposed a metric ton of issues and > problems along the way, and our introduction of an acceptance framework > helped us to fix most of those. It did solve the goal of making the module > easier to work with, and it did improve the situation of arbitrary > configuration, but the general consensus of myself, and the users, is that > there's still a large amount of significant problems that fundamentally stem > from the fact the module has no base design, it just kind of happened, and > the rewrite attempted to retain backwards compatibility with that API. > > Problems we know about > > A user of the module asked his local DBA expert to help us review the > module, which lead to a number of issues which I'll list out below. I've > taken liberties with this review, rewriting parts and condensing others to > make it more suitable here. > > Configuration Variables > > MySQL doesn't treat all configuration values equally, but we do. We don't > handle: > > Initial startup configuration. > > Certain settings, like innodb_log_file_size need to be set before we ever > start the service. If they change after the service is up and running you > have to be able to shutdown MySQL, then delete the appropriate ib_logfile > files, then restart. > > Dynamic configuration > > MySQL allows a whole bunch of stuff to be set via mysql set. We should use > this where possible and not restart MySQL for no reason. > > Defaults > > Our $default_options don't reflect what DBAs consider good defaults. > > Password hashes > > We require plain text passwords in most places in the module, rather than > letting people pass in the hash directly if they want to. > > Client Certificates > > We don't have any facility to use these. > > Configuration in general > > We're still just relying heavily on my.cnf, rather than breaking things up > into a conf.d. > > Smaller concerns > > A lot of these relate to the module as it is today, not what we'd do with > any redesign work: > > * server/account_security.pp inflexible. > * server/root_password.pp the endless troublemaker. Only works as root > thanks to /root, should use /etc/something and --defaults-file. > * db.pp has lots of issues. > * types need further work. > > Where do we go from here? > > I don't want to constrain the design based on my pre-conceptions so first I > want to continue to gather requirements and criticisms of the module in this > email thread. I've started writing up my own thoughts and those are > basically: > > * Configuration is the biggest problem we face and we need to tackle it head > on. > * Ordering is the next largest problem, we have a number of use cases and > it's difficult to handle them all. (stuff like handling existing mysql > setups on a box, people want to take those other with puppet surprisingly > often). > > I have a lot more words written down but that's basically the two things I > suspect we need to address out of the gate. Anyway, let me know what you > people think puppetlabs-mysql needs. >
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) Any thoughts on that? Gareth > > -- > 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%3DLhKvGjCPGmziu4MdFcbhEbU-BRd67d6ntchZANaoNaA%40mail.gmail.com. > For more options, visit https://groups.google.com/groups/opt_out. -- Gareth Rushgrove @garethr devopsweekly.com morethanseven.net garethrushgrove.com -- 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/CAFi_6yL2rDTPdS-Gv-eiaMxZXzj50CYnhJOAgd2%3DP-J586vhEg%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
