Hey folks,

I'm surveying the landscape of existing puppet modules that have to do with
relational database functionality.  I've talked with a few folks now and it
seems like there is a fairly broad range of opinions on what "ideal" would
look like w/rt managing rdbms with puppet.

At one extreme, there is the opinion that each RDBMS should have its own
specific puppet module... so, one module for mysql, one for postgres, one
for sqlite, etc.  With this approach, the possibility exists that there
will be redundant code and divergent models from one module to the next.
 However, depending on how much functionality the module is trying to
provide, it's entirely possible that this divergence is inevitable (because
the deeper you get into an individual database server, the more their
implementation and behaviors differ).

An obvious upside of this approach is that module authors and contributors
don't need to worry about implementation details of *other* rdbms's.  If
you know mysql and you want to contribute to the mysql module, you can just
do it.

At the other end of the spectrum is the idea of having a sort of
uber-module for rdbms; this would contain some defined types that were
meaningful across several rdbms platforms, and providers for each supported
rdbms.  The main upside of this approach would be that it would be easy to
switch between your choice of rdbms by simply toggling a parameter in your
manifests.  Another upside would be the ability to share common code /
logic where applicable (and hopefully including a lot of the test logic,
meaning that all implementations would be more thoroughly and consistently
tested).

The biggest downside here would be that the barrier to contribution would
be a bit higher; if you wanted to add a feature for a specific rdbms
instance, you'd potentially need to consider how the other several rdbms
providers would cope with this new feature.

There are obviously some intermediate options in between those two
extremes.  At the moment, I think that I'm reasonably convinced that the
barrier to contribution to the modules is the most compelling variable in
this equation, and thus I'm leaning towards just keeping the modules
separated and isolated... though I'm struggling with the decision to give
up the possibility of re-usable test logic between the modules.

Would love to hear any ideas, suggestions, thoughts that anyone has on the
topic!

Thanks
Chris

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Developers" group.
To post to this group, send email to puppet-dev@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-dev+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-dev?hl=en.

Reply via email to