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,
>> I mean a cron job with:
>>
>> facter -y > /var/lib/facter/cache.yaml
>
>
> Based on past experiences I am always a little unnerved by the idea of using
> a file on disk as "API". It is revealing an implementation detail of your
> program that makes it much harder to make changes in the future w
s/fairly/fairly easily/
On Fri, May 25, 2012 at 9:33 AM, Chris Price wrote:
> On Thu, May 24, 2012 at 11:27 PM, Jeff Weiss
> wrote:
>
> Facter itself will not use the cache. If you have an application that
>> needs facts and needs them quickly, you may read the yaml file on disk.
>
>
> On Fri
On Thu, May 24, 2012 at 11:27 PM, Jeff Weiss
wrote:
Facter itself will not use the cache. If you have an application that
> needs facts and needs them quickly, you may read the yaml file on disk.
On Fri, May 25, 2012 at 3:38 AM, Ken Barber wrote:
And from memory PE already does this.
I m
- Original Message -
> From: "Ken Barber"
> To: puppet-dev@googlegroups.com
> Sent: Friday, May 25, 2012 11:38:35 AM
> Subject: Re: [Puppet-dev] External cache for fact values
>
> >> can you give some more detail on how the cache will be used? If a
> >> fact
> >> is found on disk via th
>> can you give some more detail on how the cache will be used? If a fact
>> is found on disk via the rb file and there's nothing in the cache will
>> it then simply run the slow way? and update the cache?
>>
> Facter itself will not use the cache. If you have an application that needs
> facts and
sorry, It's not possible to reply sanely to your html email.
Thanks for clarifying, I think the word cache might be a confusing
choice of name for this feature in that case.
- Original Message -
> From: "Jeff Weiss"
> To: puppet-dev@googlegroups.com
> Sent: Friday, May 25, 2012 7:10:36 A
12 matches
Mail list logo
