On 31.05.2012 03:33, Chris Price wrote:
Interesting idea. I don't think we've done much experimentation with a
single-vcs-repo => multiple modules setup. Do you draw a firm
distinction between modules and classes here? E.g., if you could elect
to only use certain (pg-specific or mysql-specific
Interesting idea. I don't think we've done much experimentation with a
single-vcs-repo => multiple modules setup. Do you draw a firm distinction
between modules and classes here? E.g., if you could elect to only use
certain (pg-specific or mysql-specific) classes from within a single
module, you
On Tue, 29 May 2012 11:38:37 -0700, Chris Price
wrote:
> 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 modul
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 ne
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
I'm using existing ones. The biggest reason I never shifted to
puppetlabs-mysql was the lack of replication handling. The one we're using
is a little clumsy in that it requires augeas but it let us easily override
various settings. (The postgres one is currently unused).
We have a class that do
Thanks, that's helpful too. Out of curiosity, are you using modules for
the msyql/pg stuff that you've copied above? Or is it something that you
built up from scratch? If it's from scratch, can you provide some insight
as to what was lacking from existing modules that kept you from using them?
That's true, there's definitely some specific differences between the
different providers for packages that you have to tweak if you're moving
from one to another. It'll be the same for the firewall ones, some
properties just won't apply to other kinds of firewalls. I guess the
biggest difference
Thanks so much for the reply, Ashley!
It's interesting that you brought up the example of the "package" provider.
I brought that one up internally as a well, because it seems like it has
some of the same challenges. The package type currently has some
parameters that are only relevant for specif
I would vote in favor of a single module with multiple providers. As
Puppet grows up and becomes more powerful I think this model is going to
become more common anyway - once you move beyond basic modules you start
relying on more and more functions and "real code". The pool of people who
are lik
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,
11 matches
Mail list logo
