Any way you can share that PDF? The main page suggests it's supposed to be
public anyway so I'm assuming the required login is a mistake.
When you looked at deploying your puppet modules to the clients and getting rid
of the puppetmaster model, did you consider only syncing only the modules the
On Thu, Feb 18, 2010 at 9:12 AM, Trevor Vaughan wrote:
> This is true and, unfortunately, I couldn't get to the presentation either.
I got to read a copy over the shoulder of someone here with a login.
I thought it was pretty skimpy really, and didn't really adequately
cover the advantages of ei
R P Herrold writes:
> On Thu, 18 Feb 2010, Nigel Kersten wrote:
>
> > How, if at all, do any of you do capacity planning with Puppet?
>
> somewhat orthogonal to the question, but after reading this
> piece:
> http://www.usenix.org/publications/login/2010-02/pdfs/bjorgeengen.pdf
> at
This is true and, unfortunately, I couldn't get to the presentation either.
It's pretty well known that, given any two similar systems, the one
written in a lower level language will probably always win in terms of
speed and resource usage and lose in terms of community extensibility.
It all come
On Thu, Feb 18, 2010 at 8:59 AM, R P Herrold wrote:
> On Thu, 18 Feb 2010, Nigel Kersten wrote:
>
>> How, if at all, do any of you do capacity planning with Puppet?
>
> somewhat orthogonal to the question, but after reading this piece:
> http://www.usenix.org/publications/login/2010-02/pdfs
On Thu, 18 Feb 2010, Nigel Kersten wrote:
How, if at all, do any of you do capacity planning with Puppet?
somewhat orthogonal to the question, but after reading this
piece:
http://www.usenix.org/publications/login/2010-02/pdfs/bjorgeengen.pdf
at
http://www.usenix.org/publicat
+puppet-users, puppet-dev to catch the developer-y folks too.
How, if at all, do any of you do capacity planning with Puppet?
I've worked out a snippet of ruby code that will take the cached fact
data from the servers, and use that to issue a bunch of catalog
retrieval requests. I ended up modif
