date:20100310

On Wed, Mar 10, 2010 at 1:24 AM, Ohad Levy ohadl...@gmail.com wrote:
 another option that I use is to extend the string class in ruby, that would
 allow you to do something like:
 Facter.memorysize.to_gb
 in order to do that add somewhere (e.g. before your custom fact)
 class String
   def to_gb
     begin
       value,unit=self.match(/(\d+|.+) ([KMG]B)$/i)[1..2]
       case unit.to_sym
       when nil, :B, :byte          then (value.to_f / 1000_000_000)
       when :GB, :G, :gigabyte      then value.to_f
       when :MB, :M, :megabyte      then (value.to_f / 1000)
       when :KB, :K, :kilobyte, :kB then (value.to_f / 1000_000)
       else raise Unknown unit: #{unit.inspect}!
       end
     rescue
       raise Unknown string
     end
   end
 end
 Ohad

I'd rather look into fixing the problem than doing code monkeypatching
in everyday environments and require folks to write facts to get this
data.

Let's look at making things like this available today in facter.
Patch material?

I generally think facts shouldn't include units anyway, yet we don't
want to break existing things that depend on them.

--Michael

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

Re: [Puppet Users] Is it possible for puppet to compile packages?

On Wed, Mar 10, 2010 at 4:04 AM, James Turnbull ja...@lovedthanlost.net wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 On 10/03/10 8:02 PM, Ohad Levy wrote:
 I'm not saying its a good thing, but I've created an rpm for passenger,
 which compiles the apache modules in the post installation scripts.

 all of the required packages for building it are part of the rpm package
 requirements...


 What Ohad said. If, and it is rarely, I have to do this then I build
 some own RPM packages and stick them in a custom Yum repo and manage
 them like that.

 Regards

 James Turnbull


which compiles the apache modules in the post installation scripts

Apache modules can easily be shipped as seperate packages (mod_python
as an example)
that contain loadable modules.

(Forgive my ignorance, but is that not doable for passenger?)

Anyway, from a best practices perspective, it would be better to do
the rebuilds on your build server
as James said.

You don't want to be doing compilation on production servers, and you
won't have very good
granularity into what happens if something goes wrong.

rpm %post sections of any sufficient complexity are to be avoided.

--Michael

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

Re: [Puppet Users] Re: memorysize returned as string - maybe

2010-03-10 Thread Ohad Levy

I fully agree - the main reason I've done this conversion is because I want
to show nice graphs in foreman :) and that was not an option to change
everyones facter.

Ohad


On Wed, Mar 10, 2010 at 11:41 PM, Michael DeHaan
mich...@reductivelabs.comwrote:

 On Wed, Mar 10, 2010 at 1:24 AM, Ohad Levy ohadl...@gmail.com wrote:
  another option that I use is to extend the string class in ruby, that
 would
  allow you to do something like:
  Facter.memorysize.to_gb
  in order to do that add somewhere (e.g. before your custom fact)
  class String
def to_gb
  begin
value,unit=self.match(/(\d+|.+) ([KMG]B)$/i)[1..2]
case unit.to_sym
when nil, :B, :byte  then (value.to_f / 1000_000_000)
when :GB, :G, :gigabyte  then value.to_f
when :MB, :M, :megabyte  then (value.to_f / 1000)
when :KB, :K, :kilobyte, :kB then (value.to_f / 1000_000)
else raise Unknown unit: #{unit.inspect}!
end
  rescue
raise Unknown string
  end
end
  end
  Ohad

 I'd rather look into fixing the problem than doing code monkeypatching
 in everyday environments and require folks to write facts to get this
 data.

 Let's look at making things like this available today in facter.
 Patch material?

 I generally think facts shouldn't include units anyway, yet we don't
 want to break existing things that depend on them.

 --Michael

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



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

Re: [Puppet Users] How to efficiently manage multiple packages installing in the same directory


 site.pp

    import classes/install_foo.pp
    import classes/install_bar.pp

    node 'standard.node.local' {
       include install_foo
       include install_bar
    }

 ---

 classes/install_foo.pp:

    class install_foo {
       file { /:
          ensure  = directory,
          recurse = true,
          source  = puppet:///files/foo
       }
    }

 ---

 classes/install_bar.pp:

    class install_bar {
       file { /:
          ensure  = directory,
          recurse = true,
          source  = puppet:///files/bar
       }
    }

 --


Yeah, I would recommend not doing this, and would want to know more
about the use case around why you wanted to do it that way.

If you have multiple sets of applications that you don't want to
package into something LSB compliant, it would be better to install
each seperate app in /opt or /srv, such as

/opt/foo and /opt/bar

That's not great by best practices' guidelines, but it works and gets
the job done if you don't want to package things so that they fully
understand /etc and /var and such.

The error you get is because Puppet will not allow the same resource
to be represented twice, but the larger problem is you're also kind of
subverting the point of the package manager
if you are overlaying files all over the file system.  You lose the
ability manage dependencies and see how what got where, hence I'd
really recommend asking why the use case is like that.

If you're not deploying a full app, just perhaps a set of data files
or content, be more specific about where it should go:

 file { /this/is/where/where/the/files/go:
  ensure  = directory,
  recurse = true,
  source  = puppet:///files/wherever/bar
   }

Versus doing paths relative to root.

Further, I don't really know how many files you are distributing this
way, but if it's the whole OS, that is going to be rather slow and not
entirely deseriable.   If you strictly
have to do this, you might as well just rsync the content with an Exec
task ... though again, it's better if you can do something else.

--Michael

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

Re: [Puppet Users] Re: memorysize returned as string - maybe

On Wed, Mar 10, 2010 at 10:51 AM, Ohad Levy ohadl...@gmail.com wrote:
 I fully agree - the main reason I've done this conversion is because I want
 to show nice graphs in foreman :) and that was not an option to change
 everyones facter.
 Ohad

I think it is actually an option.In order to trend facts
efficiently (regardless of the app), we need numeric facts.

Send us a patch for a numeric fact in facter (and for any other facts
that have units), though I think we probably /do/ have to keep the
existing ones around.

--Michael

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

Re: [Puppet Users] Is it possible for puppet to compile packages?

I build debs for passenger based upon the brightbox PPA dsc file.

I refuse to compile by hand on production.

On Mar 10, 2010 7:46 AM, Michael DeHaan mich...@reductivelabs.com wrote:

On Wed, Mar 10, 2010 at 4:04 AM, James Turnbull ja...@lovedthanlost.net
wrote:
 -BEGIN PGP SI...
Apache modules can easily be shipped as seperate packages (mod_python
as an example)
that contain loadable modules.

(Forgive my ignorance, but is that not doable for passenger?)

Anyway, from a best practices perspective, it would be better to do
the rebuilds on your build server
as James said.

You don't want to be doing compilation on production servers, and you
won't have very good
granularity into what happens if something goes wrong.

rpm %post sections of any sufficient complexity are to be avoided.

--Michael


-- 
You received this message because you are subscribed to the Google Groups
Puppet Users group

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

Re: [Puppet Users] Is it possible for puppet to compile packages?

2010-03-10 Thread Ohad Levy

yeah, I'm ashamed - thats why I started by saying that its NOT a good idea
;)


On Thu, Mar 11, 2010 at 12:01 AM, Nigel Kersten nig...@google.com wrote:

 I build debs for passenger based upon the brightbox PPA dsc file.

 I refuse to compile by hand on production.

 On Mar 10, 2010 7:46 AM, Michael DeHaan mich...@reductivelabs.com
 wrote:

 On Wed, Mar 10, 2010 at 4:04 AM, James Turnbull ja...@lovedthanlost.net
 wrote:
  -BEGIN PGP SI...

 Apache modules can easily be shipped as seperate packages (mod_python
 as an example)
 that contain loadable modules.

 (Forgive my ignorance, but is that not doable for passenger?)

 Anyway, from a best practices perspective, it would be better to do
 the rebuilds on your build server
 as James said.

 You don't want to be doing compilation on production servers, and you
 won't have very good
 granularity into what happens if something goes wrong.

 rpm %post sections of any sufficient complexity are to be avoided.

 --Michael


 --
 You received this message because you are subscribed to the Google Groups
 Puppet Users group

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


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

[Puppet Users] Failed to retrieve current state of resource a.o

2010-03-10 Thread skoesters

Hi,

i am new to puppet and installed / configured it the first time.

I have some trouble with 2 Error Messages where google did not help
till now:

--

err: /File[/var/lib/puppet/lib]: Failed to retrieve current state of
resource: Could not retrieve information from source(s)
puppet://puppet.domain.net/plugins

--

i noticed that this error disappears when i disable the pluginsync in
puppet.conf

#pluginsync = true

with pluginsync on i get the error.

I dont know what to do to get this work with pluginsync on.

Second Problem is this:

warning: Value of 'preferred_serialization_format' (pson) is invalid
for report, using default (marshal)

i think this is not very bad, but is there a way to solve this?

If you need anything let me know.

btw. OS is CentOS 5

best regards
Sebastian

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

[Puppet Users] puppetd hangs, dies

2010-03-10 Thread Gerhard Rieger

Hi,

I experienced some problems with puppetd when it cannot reach
puppetmasterd. They apply to 0.25.1 on Debian; I could not find these
issues in changelog or bugtrack, so here I go:

1) When puppetd starts for the first time and cannot reach
puppetmasterd (due to routing or firewall problem), it hangs and
cannot be stopped with SIGTERM (that is used by /etc/init.d/puppet
stop and restart)

2) puppetd had successfully connected to puppetmasterd before. When on
a following scheduled connection attempt puppetmasterd cannot be
reached (host down or network broken), puppetd terminates silently
instead of retrying later.

3) When puppetd has actually established a connection to puppetmasterd
and the network breaks, puppetd hangs until the server responds again;
when there is a stateful firewall between these hosts that drops the
established packets after some time puppetd hangs forever instead of
closing the connection after some timeout and retrying later.

Are these already known/fixed?

-gr

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

Re: [Puppet Users] DNS issues?

2010-03-10 Thread Patrick


On Mar 10, 2010, at 6:54 AM, Brian Keifer wrote:

 
 On Mar 9, 2010, at 5:50 PM, Patrick wrote:
 
 
 On Mar 9, 2010, at 1:59 PM, Brian Keifer wrote:
 
 
 On Mar 9, 2010, at 4:57 PM, Patrick wrote:
 
 
 On Mar 9, 2010, at 6:36 AM, Brian Keifer wrote:
 
 
 On Mar 9, 2010, at 12:17 AM, Dan Bode wrote:
 
 
 1. Check the source attribute assignment.
 
 source = puppet:///modules/stats/denora.conf
 
 the third slash means use same server address as the server we connected 
 to.
 
 maybe its hardcoded to be the server name?
 
 2. you could also try:
 
 [puppetmasterd]
 certdnsnames=badger.valinor.net
 
 on the server if you need this name to be accepted by the cert.
 
 
 Thanks!  I had been using source = 
 puppet://$servername/module/path/filename.ext.  I switched to 
 puppet:/// and added the certdnsnames line to my puppetmaster's config 
 file.  My config looks a bit cleaner, but I'm still getting the random 
 errors on my file definitions:
 
 err: //inspircd/File[/home/procrast/inspircd/conf/modules.conf]: Failed 
 to retrieve current state of resource: undefined method `closed?' for 
 nil:NilClass Could not retrieve file metadata for 
 puppet:///inspircd/modules.conf: undefined method `closed?' for 
 nil:NilClass at /etc/puppet/modules/inspircd/manifests/init.pp:15
 
 From several test runs with:
 
   puppetd --server puppet.procrast.net --fqdn badger.procrast.net 
 --no-daemonize --onetime --verbose
 
 I get between 3 and 9 of these errors each time, always a different 
 subset of my files.  These same files serve properly to my other two 
 clients.
 
 I don't get it.
 
 This might be related to http://projects.reductivelabs.com/issues/3083.  
 Try using puppetca --list --all on the server and check if those clients 
 are in the list.  If they are not in the list, it's probably that bug.
 -Patrick
 
 
 The problem client does appear to be listed.
 
 [r...@badger /etc/puppet]# puppetca --list --all
 + badger.procrast.net
 + puppet.procrast.net
 
 Does puppetca show the other clients (that work) as being in the same 
 domain?  Also, take a look at /etc/puppet/fileserver.conf.
 
 
 Yep.  They all show .procrast.net addresses.  My fileserver.conf is quite 
 basic at the moment.  It's got the path to the files for each module and an 
 allow * for each.
 
 I believe the fileserver.conf is set up correctly, as the problems are 
 sporadic.  On one run a file may fail, but on the other runs it copies 
 properly.  Additionally, the other two clients that are not on the same 
 machine as the fileserver have no issues at all.
 
 Thanks!

I really have no idea what's wrong.  Here's some standard troubleshooting ideas 
that I would try.

Here are a couple of things to compare between clients that work and clients 
that don't:
What version of puppet are they using?
Is the path to the server complicated?  (How many router hops? is there 
a natting firewall in between?  High latency?  Packet loss?)
What OS are you using?


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

Re: [Puppet Users] DNS issues?

2010-03-10 Thread Brian Keifer


On Mar 10, 2010, at 11:48 AM, Patrick wrote:

 
 On Mar 10, 2010, at 6:54 AM, Brian Keifer wrote:
 
 
 On Mar 9, 2010, at 5:50 PM, Patrick wrote:
 
 
 On Mar 9, 2010, at 1:59 PM, Brian Keifer wrote:
 
 
 On Mar 9, 2010, at 4:57 PM, Patrick wrote:
 
 
 On Mar 9, 2010, at 6:36 AM, Brian Keifer wrote:
 
 
 On Mar 9, 2010, at 12:17 AM, Dan Bode wrote:
 
 
 1. Check the source attribute assignment.
 
 source = puppet:///modules/stats/denora.conf
 
 the third slash means use same server address as the server we 
 connected to.
 
 maybe its hardcoded to be the server name?
 
 2. you could also try:
 
 [puppetmasterd]
 certdnsnames=badger.valinor.net
 
 on the server if you need this name to be accepted by the cert.
 
 
 Thanks!  I had been using source = 
 puppet://$servername/module/path/filename.ext.  I switched to 
 puppet:/// and added the certdnsnames line to my puppetmaster's config 
 file.  My config looks a bit cleaner, but I'm still getting the random 
 errors on my file definitions:
 
 err: //inspircd/File[/home/procrast/inspircd/conf/modules.conf]: Failed 
 to retrieve current state of resource: undefined method `closed?' for 
 nil:NilClass Could not retrieve file metadata for 
 puppet:///inspircd/modules.conf: undefined method `closed?' for 
 nil:NilClass at /etc/puppet/modules/inspircd/manifests/init.pp:15
 
 From several test runs with:
 
  puppetd --server puppet.procrast.net --fqdn badger.procrast.net 
 --no-daemonize --onetime --verbose
 
 I get between 3 and 9 of these errors each time, always a different 
 subset of my files.  These same files serve properly to my other two 
 clients.
 
 I don't get it.
 
 This might be related to http://projects.reductivelabs.com/issues/3083.  
 Try using puppetca --list --all on the server and check if those 
 clients are in the list.  If they are not in the list, it's probably that 
 bug.
 -Patrick
 
 
 The problem client does appear to be listed.
 
 [r...@badger /etc/puppet]# puppetca --list --all
 + badger.procrast.net
 + puppet.procrast.net
 
 Does puppetca show the other clients (that work) as being in the same 
 domain?  Also, take a look at /etc/puppet/fileserver.conf.
 
 
 Yep.  They all show .procrast.net addresses.  My fileserver.conf is quite 
 basic at the moment.  It's got the path to the files for each module and an 
 allow * for each.
 
 I believe the fileserver.conf is set up correctly, as the problems are 
 sporadic.  On one run a file may fail, but on the other runs it copies 
 properly.  Additionally, the other two clients that are not on the same 
 machine as the fileserver have no issues at all.
 
 I really have no idea what's wrong.  Here's some standard troubleshooting 
 ideas that I would try.
 
 Here are a couple of things to compare between clients that work and clients 
 that don't:
   What version of puppet are they using?
   Is the path to the server complicated?  (How many router hops? is there 
 a natting firewall in between?  High latency?  Packet loss?)
   What OS are you using?

All clients and the server are using 0.25.4 installed via gem.

The path to the two remote clients is 10-12 hops, but they work fine.  The path 
to the client that's running from the same machine as the puppetmaster is, 
naturally, zero hops.  That's the only one that's having problems.

The problem server is FreeBSD, but I'm fairly certain we can rule out the OS as 
the problem since the other clients can connect to it without issue and a 
puppetd on the FreeBSD machine can connect to a remote puppetmaster without any 
problems.

Anyone else happen to have any insight or know of any documentation that 
specifically speaks to running puppetd and puppetmasterd on the same host with 
different IP addresses?

Thanks!

-Brian 

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

Re: [Puppet Users] How to efficiently manage multiple packages installing in the same directory

2010-03-10 Thread Mathew Binkley

On Wed, Mar 10, 2010 at 9:59 AM, Michael DeHaan
mich...@reductivelabs.com wrote:

 Yeah, I would recommend not doing this, and would want to know more
 about the use case around why you wanted to do it that way.

Hi Michael (and Patrick and Claus).  We are in heavy development of a
storage app, as well as collaborating with several universities in
testing their own applications on a storage network we manage.  We
would like to make sure machine X is always running the latest
versions of applications Foo and Bar.

We want to use a flat folder of files because it's quick and simple
and doesn't require writing debian build files, RPM specs, or
otherwise having to package the files up in any way given that we are
constantly (every few days) updating binaries and configs.  I don't
mean simply upgrading an existing file, I'm talking about adding new
files and removing old files.   Essentially we'd like to use Puppet as
an rsync-like tool, albeit with a lot more intelligence and
flexibility.

 The error you get is because Puppet will not allow the same resource
 to be represented twice, but the larger problem is you're also kind of
 subverting the point of the package manager
 if you are overlaying files all over the file system.

I know that's generally true, but in this instance, each package's
file are orthogonal.   Only package foo will have /etc/foo.conf.  I
was expecting that Puppet could manage multiple File / statements as
long as the files for each package on the Puppet server were unique.

 If you're not deploying a full app, just perhaps a set of data files
 or content, be more specific about where it should go:

In a static environment your point make sense.  However we and our
other collaborators are adding/removing files at a furious rate, and
I'd like to avoid spending 15 minutes each time tweaking Puppet config
files.  I know that this is far from the typical use case, but I do
believe it is a *valid* use case.

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

[Puppet Users] Making Puppet run faster

We have puppet 0.24.8 running on multiple EIGHT core 3.16Ghz servers
with 32Gb of RAM, and in each case puppet is taking longer and longer
to run, as we have it control more. Currently it's taking up to 20
minutes to perform a run.

What approaches can I take to significantly reduce the time it takes
puppet to run? It's ALSO sucking up an inordinate amount of CPU while
it performs a run. The server is using passenger.

Doug

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

Re: [Puppet Users] Making Puppet run faster

On Wed, Mar 10, 2010 at 9:58 AM, Douglas Garstang
doug.garst...@gmail.com wrote:
 We have puppet 0.24.8 running on multiple EIGHT core 3.16Ghz servers
 with 32Gb of RAM, and in each case puppet is taking longer and longer
 to run, as we have it control more. Currently it's taking up to 20
 minutes to perform a run.

 What approaches can I take to significantly reduce the time it takes
 puppet to run? It's ALSO sucking up an inordinate amount of CPU while
 it performs a run. The server is using passenger.

What Ruby version are you running ?
Do you have storeconfigs on?
How have you configured passenger?

Upgrading to 0.25.4 on your server and clients will improve file
transfers, and significantly reduce memory consumption, but CPU usage
will still be high in my experience.




 Doug

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





-- 
nigel

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

Re: [Puppet Users] Making Puppet run faster

On Wed, Mar 10, 2010 at 12:58 PM, Douglas Garstang
doug.garst...@gmail.com wrote:
 We have puppet 0.24.8 running on multiple EIGHT core 3.16Ghz servers
 with 32Gb of RAM, and in each case puppet is taking longer and longer
 to run, as we have it control more. Currently it's taking up to 20
 minutes to perform a run.

 What approaches can I take to significantly reduce the time it takes
 puppet to run? It's ALSO sucking up an inordinate amount of CPU while
 it performs a run. The server is using passenger.

 Doug


Some more information about details on what you are managing would be
helpful here.

One open bug for instance is about updating Puppet to batch yum
transactions, which can speed up run time.
If you are seeing very long runs on the client, that can be a factor.

On the server side, there are various things you might want to do,
such as selectively updating certain servers
at a time (i.e. using puppetrun) or setting up different schedules for
different machines so they don't hit all
at once (such as using cron).

We're also working to reduce server load via cached catalogs and so
forth, though it ultimately does depend
a bit about how much you are managing per server.

--Michael


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



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

Re: [Puppet Users] Making Puppet run faster

2010-03-10 Thread Brice Figureau

On 10/03/10 18:58, Douglas Garstang wrote:
 We have puppet 0.24.8 running on multiple EIGHT core 3.16Ghz servers
 with 32Gb of RAM, and in each case puppet is taking longer and longer
 to run, as we have it control more. Currently it's taking up to 20
 minutes to perform a run.
 
 What approaches can I take to significantly reduce the time it takes
 puppet to run? It's ALSO sucking up an inordinate amount of CPU while
 it performs a run. The server is using passenger.

Where do you experience the issue: on the clients or on the master?
0.25 highly improved the master performance and file serving.

High cpu usage on the client is highly dependent on what you are
managing (ie most of the time is usually spent in other processes than
puppet, like package manager). Something that also can stress clients is
managing deep file hierarchies.

For high cpu usage on the master, you can try to:
 * disable storeconfigs or use thin_storeconfigs (0.25)
 * make sure your clients sleep longer than the default or use splay
times so they don't ask their catalogs at the same time
 * use a different ruby interpreter, and/or passenger
 * if you're doing tons of file serving, offload those to a static
server (see my last blog article in my signature). This will free your
masters to serve more catalogs per unit of time.

Hope that helps,
-- 
Brice Figureau
My Blog: http://www.masterzen.fr/

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

Re: [Puppet Users] Making Puppet run faster

On Wed, Mar 10, 2010 at 10:06 AM, Nigel Kersten nig...@google.com wrote:
 On Wed, Mar 10, 2010 at 9:58 AM, Douglas Garstang
 doug.garst...@gmail.com wrote:
 We have puppet 0.24.8 running on multiple EIGHT core 3.16Ghz servers
 with 32Gb of RAM, and in each case puppet is taking longer and longer
 to run, as we have it control more. Currently it's taking up to 20
 minutes to perform a run.

 What approaches can I take to significantly reduce the time it takes
 puppet to run? It's ALSO sucking up an inordinate amount of CPU while
 it performs a run. The server is using passenger.

 What Ruby version are you running ?
 Do you have storeconfigs on?
 How have you configured passenger?

Ruby version, on client and server is:
ruby 1.8.5 (2006-08-25) [x86_64-linux]

We aren't using storeconfigs... I think the idea of putting puppet
config in a db stupid, because you lose your ability to revision
control your changes.

I configured passenger as per:
http://reductivelabs.com/trac/puppet/wiki/UsingPassenger


 Upgrading to 0.25.4 on your server and clients will improve file
 transfers, and significantly reduce memory consumption, but CPU usage
 will still be high in my experience.

Until I know for sure that 0.25.4 will fix the performance problems,
given that I've had all sorts of problems with 0.25.x in the past (as
it relates to SSL keys), I really don't want to do that. I can't take
that risk.

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

Re: [Puppet Users] Making Puppet run faster

On Wed, Mar 10, 2010 at 10:18 AM, Brice Figureau
brice-pup...@daysofwonder.com wrote:
 On 10/03/10 18:58, Douglas Garstang wrote:
 We have puppet 0.24.8 running on multiple EIGHT core 3.16Ghz servers
 with 32Gb of RAM, and in each case puppet is taking longer and longer
 to run, as we have it control more. Currently it's taking up to 20
 minutes to perform a run.

 What approaches can I take to significantly reduce the time it takes
 puppet to run? It's ALSO sucking up an inordinate amount of CPU while
 it performs a run. The server is using passenger.

 Where do you experience the issue: on the clients or on the master?
 0.25 highly improved the master performance and file serving.

The issue is on the clients. The master seems fine. I'd like to avoid
0.25 for now, as I simply could not get the SSL keys to work with it
the last time I tried and I can't risk production seems not being able
to receive updates for days on end.


 High cpu usage on the client is highly dependent on what you are
 managing (ie most of the time is usually spent in other processes than
 puppet, like package manager). Something that also can stress clients is
 managing deep file hierarchies.

We probably have some deep file hierarchies.


 For high cpu usage on the master, you can try to:
  * disable storeconfigs or use thin_storeconfigs (0.25)
  * make sure your clients sleep longer than the default or use splay
 times so they don't ask their catalogs at the same time
  * use a different ruby interpreter, and/or passenger
  * if you're doing tons of file serving, offload those to a static
 server (see my last blog article in my signature). This will free your
 masters to serve more catalogs per unit of time.

The main isssue isn't even really the high CPU usage... it's just that
the client takes 20 minutes to run. That's the really inconvenient
bit. We aren't using storeconfigs. Putting config in a db is crazy. We
only have a total of maybe a dozen machines running the client, so I
doubt increasing the time between runs will make any difference. We
ARE using passenger on the server (said that in my original post). Not
doing tons of file serving... the master is not working anywhere near
as hard as the clients.

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

Re: [Puppet Users] Making Puppet run faster

On Wed, Mar 10, 2010 at 10:19 AM, Douglas Garstang
doug.garst...@gmail.com wrote:
 On Wed, Mar 10, 2010 at 10:06 AM, Nigel Kersten nig...@google.com wrote:
 On Wed, Mar 10, 2010 at 9:58 AM, Douglas Garstang
 doug.garst...@gmail.com wrote:
 We have puppet 0.24.8 running on multiple EIGHT core 3.16Ghz servers
 with 32Gb of RAM, and in each case puppet is taking longer and longer
 to run, as we have it control more. Currently it's taking up to 20
 minutes to perform a run.

 What approaches can I take to significantly reduce the time it takes
 puppet to run? It's ALSO sucking up an inordinate amount of CPU while
 it performs a run. The server is using passenger.

 What Ruby version are you running ?
 Do you have storeconfigs on?
 How have you configured passenger?

 Ruby version, on client and server is:
 ruby 1.8.5 (2006-08-25) [x86_64-linux]

You should see significant improvements if you move to a more recent Ruby stack.

A simple test is http://www.rubyenterpriseedition.com as you can
install to /opt and not interfere with your current stack or have to
work on packaging while you just evaluate it.

I have it all packaged for debian now, but I used to simply symlink
puppet/facter etc from the normal ruby lib into the Ruby EE one.


 We aren't using storeconfigs... I think the idea of putting puppet
 config in a db stupid, because you lose your ability to revision
 control your changes.

That's not all it can do, but that's somewhat irrelevant.


 I configured passenger as per:
 http://reductivelabs.com/trac/puppet/wiki/UsingPassenger

I have this config for 4 VCPUs and 4GB RAM:

IfModule mod_passenger.c
  PassengerMaxRequests 5500
  PassengerPoolIdleTime 600
  PassengerMaxPoolSize 10
  PassengerStatThrottleRate 600
/IfModule

MaxRequests isn't so necessary with 0.25, but definitely stops memory leaks.

what do your machines look like when they're busy? Are all cores maxed
out? uptime/load stats? memory consumption?





 Upgrading to 0.25.4 on your server and clients will improve file
 transfers, and significantly reduce memory consumption, but CPU usage
 will still be high in my experience.

 Until I know for sure that 0.25.4 will fix the performance problems,
 given that I've had all sorts of problems with 0.25.x in the past (as
 it relates to SSL keys), I really don't want to do that. I can't take
 that risk.

No-one knows for sure whether 0.25.4 will fix your specific issues.
You don't have a development environment you can test on?


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





-- 
nigel

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

Re: [Puppet Users] Making Puppet run faster

On Wed, Mar 10, 2010 at 10:24 AM, Douglas Garstang
doug.garst...@gmail.com wrote:
 On Wed, Mar 10, 2010 at 10:18 AM, Brice Figureau
 brice-pup...@daysofwonder.com wrote:
 On 10/03/10 18:58, Douglas Garstang wrote:
 We have puppet 0.24.8 running on multiple EIGHT core 3.16Ghz servers
 with 32Gb of RAM, and in each case puppet is taking longer and longer
 to run, as we have it control more. Currently it's taking up to 20
 minutes to perform a run.

 What approaches can I take to significantly reduce the time it takes
 puppet to run? It's ALSO sucking up an inordinate amount of CPU while
 it performs a run. The server is using passenger.

 Where do you experience the issue: on the clients or on the master?
 0.25 highly improved the master performance and file serving.

 The issue is on the clients. The master seems fine. I'd like to avoid
 0.25 for now, as I simply could not get the SSL keys to work with it
 the last time I tried and I can't risk production seems not being able
 to receive updates for days on end.

If the issue is on the clients, then ignore everything I said above :)

Are you sure the server isn't a bottleneck though? Does it look overloaded?



 High cpu usage on the client is highly dependent on what you are
 managing (ie most of the time is usually spent in other processes than
 puppet, like package manager). Something that also can stress clients is
 managing deep file hierarchies.

 We probably have some deep file hierarchies.


 For high cpu usage on the master, you can try to:
  * disable storeconfigs or use thin_storeconfigs (0.25)
  * make sure your clients sleep longer than the default or use splay
 times so they don't ask their catalogs at the same time
  * use a different ruby interpreter, and/or passenger
  * if you're doing tons of file serving, offload those to a static
 server (see my last blog article in my signature). This will free your
 masters to serve more catalogs per unit of time.

 The main isssue isn't even really the high CPU usage... it's just that
 the client takes 20 minutes to run. That's the really inconvenient
 bit. We aren't using storeconfigs. Putting config in a db is crazy. We
 only have a total of maybe a dozen machines running the client, so I
 doubt increasing the time between runs will make any difference. We
 ARE using passenger on the server (said that in my original post). Not
 doing tons of file serving... the master is not working anywhere near
 as hard as the clients.

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





-- 
nigel

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

Re: [Puppet Users] Making Puppet run faster

 We aren't using storeconfigs... I think the idea of putting puppet
 config in a db stupid, because you lose your ability to revision
 control your changes.

Just on a technical note, this is not what storeconfigs are about so much.

It also gives you information such as the current value of facts on each node
(such as giving you a simple inventory system)

The puppet manifest still drives the system, and can still be version
controlled.

--Michael

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

Re: [Puppet Users] Making Puppet run faster

On Wed, Mar 10, 2010 at 10:25 AM, Nigel Kersten nig...@google.com wrote:
 On Wed, Mar 10, 2010 at 10:19 AM, Douglas Garstang
 doug.garst...@gmail.com wrote:
 On Wed, Mar 10, 2010 at 10:06 AM, Nigel Kersten nig...@google.com wrote:
 On Wed, Mar 10, 2010 at 9:58 AM, Douglas Garstang
 doug.garst...@gmail.com wrote:
 We have puppet 0.24.8 running on multiple EIGHT core 3.16Ghz servers
 with 32Gb of RAM, and in each case puppet is taking longer and longer
 to run, as we have it control more. Currently it's taking up to 20
 minutes to perform a run.

 What approaches can I take to significantly reduce the time it takes
 puppet to run? It's ALSO sucking up an inordinate amount of CPU while
 it performs a run. The server is using passenger.

 What Ruby version are you running ?
 Do you have storeconfigs on?
 How have you configured passenger?

 Ruby version, on client and server is:
 ruby 1.8.5 (2006-08-25) [x86_64-linux]

 You should see significant improvements if you move to a more recent Ruby 
 stack.

 A simple test is http://www.rubyenterpriseedition.com as you can
 install to /opt and not interfere with your current stack or have to
 work on packaging while you just evaluate it.

 I have it all packaged for debian now, but I used to simply symlink
 puppet/facter etc from the normal ruby lib into the Ruby EE one.


 We aren't using storeconfigs... I think the idea of putting puppet
 config in a db stupid, because you lose your ability to revision
 control your changes.

 That's not all it can do, but that's somewhat irrelevant.


 I configured passenger as per:
 http://reductivelabs.com/trac/puppet/wiki/UsingPassenger

 I have this config for 4 VCPUs and 4GB RAM:

 IfModule mod_passenger.c
  PassengerMaxRequests 5500
  PassengerPoolIdleTime 600
  PassengerMaxPoolSize 10
  PassengerStatThrottleRate 600
 /IfModule

 MaxRequests isn't so necessary with 0.25, but definitely stops memory leaks.

 what do your machines look like when they're busy? Are all cores maxed
 out? uptime/load stats? memory consumption?

Thanks Nigel. Let me go check this stuff.

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

RE: [Puppet Users] Using puppet to automate tasks (ex: mysql slave setup)

2010-03-10 Thread Byron Pezan

In my environment I'd probably do something like this with Func 
(https://fedorahosted.org/func/).  It's primarily used with RedHat based 
systems.  If that's not a problem for you, then you can write scripts on your 
overlord that run commands on any systems running the func daemon and 
reporting to your overlord.  Your specific issue could be solved mostly with 
the Command and CopyFile module or, with a little Python experience, you 
could write your own module using the available api.

It takes some work getting Func implemented but can be done quite easily with 
an existing puppet infrastructure or with something like Cobbler.


byron

-Original Message-
From: puppet-users@googlegroups.com [mailto:puppet-us...@googlegroups.com] On 
Behalf Of Doug Warner
Sent: Wednesday, March 10, 2010 8:19 AM
To: puppet-users@googlegroups.com
Subject: [Puppet Users] Using puppet to automate tasks (ex: mysql slave setup)

I'm not sure if puppet can be coerced to do something like this, but I wanted 
to throw it out there as it's a process that seems fairly easy to automate.

To create new mysql slaves my process goes something like this:

1) run innobackupex [1] on mysql master
2a) copy data from master to slave (takes a decent amount of time depending on 
wire speed and database size; usually on the order of 6-24 hrs)
2b) setup mysql slave w/ data from mysql master to start replicating binary log
3) import backup using innobackupex

The problem here seems to be that I need to do things on two different hosts 
and only once certain things have happened.

I figured I could easily specify the node that is the master and the slave in 
the manifests, but I'm not sure how far this gets me.  I imagine through the 
creative use of exec's and onlyifs this should be doable, but I wanted to get 
other people's experiences with automating processes like this.

-Doug

[1]
http://www.percona.com/docs/wiki/percona-xtrabackup:xtrabackup_manual#setting_up_a_new_slave_from_a_backup_in_replication

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

Re: [Puppet Users] Making Puppet run faster

2010-03-10 Thread Brice Figureau

On 10/03/10 19:24, Douglas Garstang wrote:
 On Wed, Mar 10, 2010 at 10:18 AM, Brice Figureau
 brice-pup...@daysofwonder.com wrote:
 On 10/03/10 18:58, Douglas Garstang wrote:
 We have puppet 0.24.8 running on multiple EIGHT core 3.16Ghz servers
 with 32Gb of RAM, and in each case puppet is taking longer and longer
 to run, as we have it control more. Currently it's taking up to 20
 minutes to perform a run.

 What approaches can I take to significantly reduce the time it takes
 puppet to run? It's ALSO sucking up an inordinate amount of CPU while
 it performs a run. The server is using passenger.

 Where do you experience the issue: on the clients or on the master?
 0.25 highly improved the master performance and file serving.
 
 The issue is on the clients. The master seems fine. I'd like to avoid
 0.25 for now, as I simply could not get the SSL keys to work with it
 the last time I tried and I can't risk production seems not being able
 to receive updates for days on end.
 

 High cpu usage on the client is highly dependent on what you are
 managing (ie most of the time is usually spent in other processes than
 puppet, like package manager). Something that also can stress clients is
 managing deep file hierarchies.
 
 We probably have some deep file hierarchies.

Try to comment those in your manifests, just to see if that is the root
cause.
Also make sure you don't have a default like this:
File { checksum = md5 }
or other checksum in your non-sourced/non-content file{} resource.

Because that means all your local not sourced file management will have
to md5 every managed file. If you combine this with deep hierarchies and
recursion, then you'll have some CPU consumption troubles.
If you have those recursive not sourced file {} resources, make sure to use:

checksum = undef

in them to at least not md5 everything.
I think this problem doesn't exist in 0.25.


 For high cpu usage on the master, you can try to:
  * disable storeconfigs or use thin_storeconfigs (0.25)
  * make sure your clients sleep longer than the default or use splay
 times so they don't ask their catalogs at the same time
  * use a different ruby interpreter, and/or passenger
  * if you're doing tons of file serving, offload those to a static
 server (see my last blog article in my signature). This will free your
 masters to serve more catalogs per unit of time.
 
 The main isssue isn't even really the high CPU usage... it's just that
 the client takes 20 minutes to run. That's the really inconvenient
 bit. We aren't using storeconfigs. Putting config in a db is crazy. We
 only have a total of maybe a dozen machines running the client, so I
 doubt increasing the time between runs will make any difference. We
 ARE using passenger on the server (said that in my original post). Not
 doing tons of file serving... the master is not working anywhere near
 as hard as the clients.

You can ignore my above advice since only your clients are affected.
-- 
Brice Figureau
My Blog: http://www.masterzen.fr/

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

[Puppet Users] config settings for environments

2010-03-10 Thread Rob McBroom

Hello. The documentation on using multiple environments says there are only a 
couple of settings that make sense per-environment (modulepath, templatedir, 
manifest) but it’s not clear to me whether or not those are the only ones 
supported.

Specifically, I’m trying to set config_version. Each of my environments are 
clones of the same git repo at different points in its history, so using git to 
determine a config_version should yield different results in different 
environments.

I set a default value for config_version and then do something like this for a 
test environment:

[test]
manifest = /etc/puppet/manifests/test/site.pp
modulepath = /etc/puppet/manifests/test/modules
config_version = 'git --git-dir /etc/puppet/manifests/test/.git rev-parse 
--shor
t HEAD 2/dev/null || echo'

But the configuration version shown on the client is always that of production 
(the default).

-- 
Rob McBroom
http://www.skurfer.com/

It's not that I think guns, drugs, prostitution, swimming, eating and reading 
should be legal. It's just that no one on Earth has the authority to make them 
illegal.

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

Re: [Puppet Users] config settings for environments

2010-03-10 Thread Rob McBroom

On Mar 10, 2010, at 3:07 PM, Rob McBroom wrote:

 Hello. The documentation on using multiple environments says there are only a 
 couple of settings that make sense per-environment (modulepath, templatedir, 
 manifest) but it’s not clear to me whether or not those are the only ones 
 supported.

Sorry, forgot to say that both master and client are at 0.25.4. Thanks.

-- 
Rob McBroom
http://www.skurfer.com/

Because it screws up the order in which people normally read text.

Original message:

 Why is it bad to top-post your reply?



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

Re: [Puppet Users] Making Puppet run faster

On Wed, Mar 10, 2010 at 11:41 AM, Brice Figureau
brice-pup...@daysofwonder.com wrote:
 On 10/03/10 19:24, Douglas Garstang wrote:
 On Wed, Mar 10, 2010 at 10:18 AM, Brice Figureau
 brice-pup...@daysofwonder.com wrote:
 On 10/03/10 18:58, Douglas Garstang wrote:
 We have puppet 0.24.8 running on multiple EIGHT core 3.16Ghz servers
 with 32Gb of RAM, and in each case puppet is taking longer and longer
 to run, as we have it control more. Currently it's taking up to 20
 minutes to perform a run.

 What approaches can I take to significantly reduce the time it takes
 puppet to run? It's ALSO sucking up an inordinate amount of CPU while
 it performs a run. The server is using passenger.

 Where do you experience the issue: on the clients or on the master?
 0.25 highly improved the master performance and file serving.

 The issue is on the clients. The master seems fine. I'd like to avoid
 0.25 for now, as I simply could not get the SSL keys to work with it
 the last time I tried and I can't risk production seems not being able
 to receive updates for days on end.


 High cpu usage on the client is highly dependent on what you are
 managing (ie most of the time is usually spent in other processes than
 puppet, like package manager). Something that also can stress clients is
 managing deep file hierarchies.

 We probably have some deep file hierarchies.

 Try to comment those in your manifests, just to see if that is the root
 cause.
 Also make sure you don't have a default like this:
 File { checksum = md5 }
 or other checksum in your non-sourced/non-content file{} resource.

 Because that means all your local not sourced file management will have
 to md5 every managed file. If you combine this with deep hierarchies and
 recursion, then you'll have some CPU consumption troubles.
 If you have those recursive not sourced file {} resources, make sure to use:

 checksum = undef

 in them to at least not md5 everything.
 I think this problem doesn't exist in 0.25.

Thanks. Checked and files are NOT being checksummed.

Doug.

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

Re: [Puppet Users] Making Puppet run faster

So, it became apparent to me, after emailing someone off list, that
managing a lot of files in deep directory structures might be part of
the cause.

We are running 10 instances of JBOSS and 10 instances of tomcat on
each of these servers. Don't ask me why, it's just the way it was done
before I arrived and changing it is not trivial.

On disk, each instance of JBOSS starts at
/opt/jboss/current/server/tfelN (where N is the instance number)

and each instance of tomcat starts at:
/opt/tomcat/tfelN/starterkit/current (where N is the instance number)

I manually looked through the puppet config and counted 25 unique
files that are being managed for jboss and tomcat within these paths.
If you do the math, 25 x 10 x 2 = 500. That's therefore (currently)
500 unique files that are being managed in these deep directory
structures. Could that potentially be the reason behind puppets crap
performance?

Doug.

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

Re: [Puppet Users] Making Puppet run faster

2010-03-10 Thread Brice Figureau

On 10/03/10 22:06, Douglas Garstang wrote:
 So, it became apparent to me, after emailing someone off list, that
 managing a lot of files in deep directory structures might be part of
 the cause.
 
 We are running 10 instances of JBOSS and 10 instances of tomcat on
 each of these servers. Don't ask me why, it's just the way it was done
 before I arrived and changing it is not trivial.
 
 On disk, each instance of JBOSS starts at
 /opt/jboss/current/server/tfelN (where N is the instance number)
 
 and each instance of tomcat starts at:
 /opt/tomcat/tfelN/starterkit/current (where N is the instance number)

Do you source the whole hierarchy?
Or do you only manage it?

 I manually looked through the puppet config and counted 25 unique
 files that are being managed for jboss and tomcat within these paths.
 If you do the math, 25 x 10 x 2 = 500. That's therefore (currently)
 500 unique files that are being managed in these deep directory
 structures. Could that potentially be the reason behind puppets crap
 performance?

What do you manage for those files?
But no, 500 doesn't seem like a high number to me.

You mentioned in another e-mail in this thread that the problem is more
the 20 minutes run than the CPU.
Could it be possible you have many slow execs?
Or you manage many packages?

This also reminds me Ohad's bug:
http://projects.reductivelabs.com/issues/1719

At this stage you should probably run puppetd on the console in --debug
to see what happens (and run with --summarize too) and if it stalls.
-- 
Brice Figureau
My Blog: http://www.masterzen.fr/

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

Re: [Puppet Users] Making Puppet run faster

On Wed, Mar 10, 2010 at 1:17 PM, Brice Figureau
brice-pup...@daysofwonder.com wrote:
On 10/03/10 22:06, Douglas Garstang wrote:
So, it became apparent to me, after emailing someone off list, that
managing a lot of files in deep directory structures might be part of
the cause.

We are running 10 instances of JBOSS and 10 instances of tomcat on
each of these servers. Don't ask me why, it's just the way it was done
before I arrived and changing it is not trivial.

On disk, each instance of JBOSS starts at
/opt/jboss/current/server/tfelN (where N is the instance number)

and each instance of tomcat starts at:
/opt/tomcat/tfelN/starterkit/current (where N is the instance number)

Do you source the whole hierarchy?
Or do you only manage it?

I manually looked through the puppet config and counted 25 unique
files that are being managed for jboss and tomcat within these paths.
If you do the math, 25 x 10 x 2 = 500. That's therefore (currently)
500 unique files that are being managed in these deep directory
structures. Could that potentially be the reason behind puppets crap
performance?

What do you manage for those files?
But no, 500 doesn't seem like a high number to me.

You mentioned in another e-mail in this thread that the problem is more
the 20 minutes run than the CPU.
Could it be possible you have many slow execs?
Or you manage many packages?

This also reminds me Ohad's bug:
http://projects.reductivelabs.com/issues/1719

At this stage you should probably run puppetd on the console in --debug
to see what happens (and run with --summarize too) and if it stalls.

I just ran puppet in debug mode and it was obvious that most of the
puppet run time was spent in checksumming files.

Eg:

debug:
//Node[app01.fr.xxx.com]/Jboss::Instance[tfel8]/File[/opt/jboss/current/server/tfel8/conf/jboss.web/localhost/rewrite.properties]:
Creating checksum {md5}f5d16bcc20b92631eb59514018fd34e5

... takes a long time to run. Multiple that by several hundred files...

However, when I run this on the command line:
md5sum
/opt/jboss/current/server/tfel8/conf/jboss.web/localhost/rewrite.properties

... the result is instananeous... So... is puppet using a ruby library
for performing md5 checksums? Is that where the performance bottle
neck could be?

Doug

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

Re: [Puppet Users] Making Puppet run faster