Thanks, David. I think that something along these lines is where we will
likely end up at some point. One question that has come up a few times,
though, is whether or not to package the implementation-specific stuff as
separate modules or as part of a single, larger module.
We will definitely need to draw a line between simple, common functionality
and db-specific functionality, but there are a few different options with
respect to packaging. If we package the basic functionality as one module,
and then the db-specific functionality as separate modules, then we end up
with bits of our mysql support in two separate places, bits of our postgres
support in two separate places, etc.
An alternative would be to package the "common" stuff and the db-specific
stuff all in one larger module together; then everything lives in the same
place, but you do get into some other possible issues with clutter, module
size, etc.
It's starting to feel like the best way to address this may be to do some
work to improve our postgres capabilities--as a separate module for the
time being--and bring them into alignment with our current mysql stuff; if
we do this with an eye towards bringing the common parts together at some
point, hopefully the overlap will become more obvious and we can take the
appropriate next steps afterwards.
Thanks a ton for the input... if anyone has any additional thoughts they
would be welcomed!
On Sun, May 27, 2012 at 1:18 PM, David Schmitt <da...@dasz.at> wrote:
> On 2012-05-25 19:44, Chris Price wrote:
>
>> 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.
>>
>
> Hi,
>
> I believe that rdbms are complex enough they warrant implementing both
> layers separately: One module for each implementation that provides for
> fine-grained control over all available features and tunings, as well as a
> common integration module that provides a simple, unified interface.
>
> The first is needed because I need all the knobs for tuning my system.
>
> The second is needed because I just want to say "class { 'zenoss':
> database => 'postgres' }" and have it work.
>
> Using the first set of module in the common integration module ensures
> that tuning is still possible.
>
>
> Common code can always be placed into a base module, used by everyone.
>
>
> Best Regards, David
>
>
> --
> 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+unsubscribe@**
> googlegroups.com <puppet-dev%2bunsubscr...@googlegroups.com>.
> For more options, visit this group at http://groups.google.com/**
> group/puppet-dev?hl=en <http://groups.google.com/group/puppet-dev?hl=en>.
>
>
--
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.
