Puppet users - Nov 2010 - agent needs to make two runs before master compiles new catalog

Hi all,

I''m a new puppet user and new to the forum.

I just switched my Puppetmaster to running inside Apache (via
Passenger). When I make a change to a resource on the master, it
sometimes takes a given node TWO runs before the master will realize
the resource has changed and recompile a new catalog version for the
node. For example, say my puppetmaster is serving configuration
version ''123'' to a node. I change the file permissions for a
file
resource that''s part of that catalog and then do a puppet run on the
node. If I''m running with Passenger, the master serves config version
''123'' one more time (the agent makes no changes). The next
time I run
the node''s agent, the master compiles new catalog version
''456'' and
the agent makes the permission change.

A few items of note:

1.  This is not a problem with all changes to puppet module content.
For example, if I change the source contents of a file in the
''files''
directory of a module, the master will notice this immediately and the
puppet agent on the node will grab the new file on the first run
following the change on the master.

2.  At first I thought maybe this was a timing issue (e.g. I was doing
the puppet run too quickly after making the resource change) but it''s
not; whether I wait 5 seconds or 5 minutes before making the first
puppet run, the master still doesn''t notice the change.  I set the
''filetimeout'' setting in /etc/puppet/puppet.conf to 0 and it
didn''t
help.

Any ideas on what''s going on here? (thanks in advance for your help)

-Kent

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

On Nov 8, 2010, at 9:10 AM, Kent wrote:
> Hi all,
> 
> I''m a new puppet user and new to the forum.
> 
> I just switched my Puppetmaster to running inside Apache (via
> Passenger). When I make a change to a resource on the master, it
> sometimes takes a given node TWO runs before the master will realize
> the resource has changed and recompile a new catalog version for the
> node. For example, say my puppetmaster is serving configuration
> version ''123'' to a node. I change the file permissions
for a file
> resource that''s part of that catalog and then do a puppet run on
the
> node. If I''m running with Passenger, the master serves config
version
> ''123'' one more time (the agent makes no changes). The
next time I run
> the node''s agent, the master compiles new catalog version
''456'' and
> the agent makes the permission change.
> 
> A few items of note:
> 
> 1.  This is not a problem with all changes to puppet module content.
> For example, if I change the source contents of a file in the
''files''
> directory of a module, the master will notice this immediately and the
> puppet agent on the node will grab the new file on the first run
> following the change on the master.
Fact:
Files sent using "source" aren''t part of the catalog. 
Instead, the client asks the server for them while the client is using the
catalog and not during the compilation done on the server.

Speculation:
I would guess this is because the problem you are having is happening during the
compilation on the server.

> 2.  At first I thought maybe this was a timing issue (e.g. I was doing
> the puppet run too quickly after making the resource change) but
it''s
> not; whether I wait 5 seconds or 5 minutes before making the first
> puppet run, the master still doesn''t notice the change.  I set the
> ''filetimeout'' setting in /etc/puppet/puppet.conf to 0 and
it didn''t
> help.
> 
> Any ideas on what''s going on here? (thanks in advance for your
help)

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

On Nov 8, 11:07 am, Patrick <kc7...@gmail.com>
wrote:
> On Nov 8, 2010, at 9:10 AM, Kent wrote:
>
>
>
>
>
>
>
>
>
> > Hi all,
>
> > I''m a new puppet user and new to the forum.
>
> > I just switched my Puppetmaster to running inside Apache (via
> > Passenger). When I make a change to a resource on the master, it
> > sometimes takes a given node TWO runs before the master will realize
> > the resource has changed and recompile a new catalog version for the
> > node. For example, say my puppetmaster is serving configuration
> > version ''123'' to a node. I change the file
permissions for a file
> > resource that''s part of that catalog and then do a puppet run
on the
> > node. If I''m running with Passenger, the master serves config
version
> > ''123'' one more time (the agent makes no changes).
The next time I run
> > the node''s agent, the master compiles new catalog version
''456'' and
> > the agent makes the permission change.
>
> > A few items of note:
>
> > 1.  This is not a problem with all changes to puppet module content.
> > For example, if I change the source contents of a file in the
''files''
> > directory of a module, the master will notice this immediately and the
> > puppet agent on the node will grab the new file on the first run
> > following the change on the master.
>
> Fact:
> Files sent using "source" aren''t part of the catalog.
 Instead, the client asks the server for them while the client is using the
catalog and not during the compilation done on the server.
>
> Speculation:
> I would guess this is because the problem you are having is happening
during the compilation on the server.
>
>
>
>
>
>
>
> > 2.  At first I thought maybe this was a timing issue (e.g. I was doing
> > the puppet run too quickly after making the resource change) but
it''s
> > not; whether I wait 5 seconds or 5 minutes before making the first
> > puppet run, the master still doesn''t notice the change.  I
set the
> > ''filetimeout'' setting in /etc/puppet/puppet.conf to
0 and it didn''t
> > help.
>
> > Any ideas on what''s going on here? (thanks in advance for
your help)
Ahh, Ok, that makes sense. The source files are not part of the
manifests, just pointed to by them.

However, I am still having a problem with changed manifests not
getting "noticed" by the Puppetmaster until the second run after
it''s
been changed. This is only a problem when running puppetmaster as a
rack app inside Apache. Of course, if I restart Apache it will serve
up the most recent manifests on the first puppet run that connects to
it, but it would be irritating to have to restart httpd every time I
want to make a change to a module/manifest.

I also tried setting the puppet.conf option ''ignorecache =
true'' to no
avail. (side note: on the "servertype" option in puppet.conf, official
documentation still states that the only valid modes are
''webrick'' and
''mongrel''. What is the appropriate mode for running with
passenger?)

Final note: The puppetmaster always logs that it has compiled a
catalog and expired the cached one, even on the first runs where the
new manifest does not yet take effect. (and annoyingly, puppetmaster
under passenger now logs to /var/log/messages instead of /var/log/
puppet/puppetmaster.log; it seems puppetmaster as a rack application
does not look at /etc/sysconfig/puppetmaster - so I can''t add options
like verbosity, etc.)

To me, it seems like there needs to be better Puppet Labs
documentation on the differences between running Puppetmaster
"normally" (e.g. with /etc/init.d/puppetmaster) versus as a Rack
application.

Can anyone shed some light on my issues?

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

On Nov 9, 2010, at 9:34 AM, Kent wrote:
> 
> 
> On Nov 8, 11:07 am, Patrick <kc7...@gmail.com> wrote:
>> On Nov 8, 2010, at 9:10 AM, Kent wrote:
>> 
>> 
>>> Hi all,
>> 
>>> I''m a new puppet user and new to the forum.
>> 
>>> I just switched my Puppetmaster to running inside Apache (via
>>> Passenger). When I make a change to a resource on the master, it
>>> sometimes takes a given node TWO runs before the master will
realize
>>> the resource has changed and recompile a new catalog version for
the
>>> node. For example, say my puppetmaster is serving configuration
>>> version ''123'' to a node. I change the file
permissions for a file
>>> resource that''s part of that catalog and then do a puppet
run on the
>>> node. If I''m running with Passenger, the master serves
config version
>>> ''123'' one more time (the agent makes no changes).
The next time I run
>>> the node''s agent, the master compiles new catalog version
''456'' and
>>> the agent makes the permission change.
>> 
>>> A few items of note:
>> 
>>> 1.  This is not a problem with all changes to puppet module
content.
>>> For example, if I change the source contents of a file in the
''files''
>>> directory of a module, the master will notice this immediately and
the
>>> puppet agent on the node will grab the new file on the first run
>>> following the change on the master.
>> 
>> Fact:
>> Files sent using "source" aren''t part of the
catalog.  Instead, the client asks the server for them while the client is using
the catalog and not during the compilation done on the server.
>> 
>> Speculation:
>> I would guess this is because the problem you are having is happening
during the compilation on the server.
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>>> 2.  At first I thought maybe this was a timing issue (e.g. I was
doing
>>> the puppet run too quickly after making the resource change) but
it''s
>>> not; whether I wait 5 seconds or 5 minutes before making the first
>>> puppet run, the master still doesn''t notice the change.  I
set the
>>> ''filetimeout'' setting in /etc/puppet/puppet.conf
to 0 and it didn''t
>>> help.
>> 
>>> Any ideas on what''s going on here? (thanks in advance for
your help)
> 
> Ahh, Ok, that makes sense. The source files are not part of the
> manifests, just pointed to by them.
> 
> However, I am still having a problem with changed manifests not
> getting "noticed" by the Puppetmaster until the second run after
it''s
> been changed. This is only a problem when running puppetmaster as a
> rack app inside Apache. Of course, if I restart Apache it will serve
> up the most recent manifests on the first puppet run that connects to
> it, but it would be irritating to have to restart httpd every time I
> want to make a change to a module/manifest.
> 
> I also tried setting the puppet.conf option ''ignorecache =
true'' to no
> avail. (side note: on the "servertype" option in puppet.conf,
official
> documentation still states that the only valid modes are
''webrick'' and
> ''mongrel''. What is the appropriate mode for running with
passenger?)
My puppetmaster is working fine and that option isn''t set which means
it''s defaulting to webrick.
> Final note: The puppetmaster always logs that it has compiled a
> catalog and expired the cached one, even on the first runs where the
> new manifest does not yet take effect. (and annoyingly, puppetmaster
> under passenger now logs to /var/log/messages instead of /var/log/
> puppet/puppetmaster.log;
I don''t know how to fix this, but this doesn''t happen under
Ubuntu.
> it seems puppetmaster as a rack application
> does not look at /etc/sysconfig/puppetmaster - so I can''t add
options
> like verbosity, etc.)
Correct.  Files in /etc/sysconfig are red when a service starts.  When using
passenger, the service is apache and puppetmaster is one of it''s
subprocesses.

The equivalent file is config.ru.  It''s in the folder you specify in
the apache config file.  Just do a "find / -name config.ru".

That said, you really shouldn''t need to change it if puppetmaster is
managing to startup at all.
> To me, it seems like there needs to be better Puppet Labs
> documentation on the differences between running Puppetmaster
> "normally" (e.g. with /etc/init.d/puppetmaster) versus as a Rack
> application.

What distro are you using?

What version of puppet are you using? (puppet --version)

How did you install puppet?

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

Patrick, thanks for the speedy reply once again.

I''m using RHEL5 and Puppet 2.6.1, Passenger 2.2.7, Rack 1.1.0.

From what I''ve read in this group and in Puppet Labs docs/wikis,
Debian/Ubuntu users do seem to have an easier time generally than
CentOS/Red Hat :-\

Can I pass my command-line options to Puppetmasterd in the config.ru
file?

-Kent

On Nov 9, 10:53 am, Patrick <kc7...@gmail.com>
wrote:
> On Nov 9, 2010, at 9:34 AM, Kent wrote:
>
>
>
>
>
>
>
>
>
>
>
> > On Nov 8, 11:07 am, Patrick <kc7...@gmail.com> wrote:
> >> On Nov 8, 2010, at 9:10 AM, Kent wrote:
>
> >>> Hi all,
>
> >>> I''m a new puppet user and new to the forum.
>
> >>> I just switched my Puppetmaster to running inside Apache (via
> >>> Passenger). When I make a change to a resource on the master,
it
> >>> sometimes takes a given node TWO runs before the master will
realize
> >>> the resource has changed and recompile a new catalog version
for the
> >>> node. For example, say my puppetmaster is serving
configuration
> >>> version ''123'' to a node. I change the file
permissions for a file
> >>> resource that''s part of that catalog and then do a
puppet run on the
> >>> node. If I''m running with Passenger, the master
serves config version
> >>> ''123'' one more time (the agent makes no
changes). The next time I run
> >>> the node''s agent, the master compiles new catalog
version ''456'' and
> >>> the agent makes the permission change.
>
> >>> A few items of note:
>
> >>> 1.  This is not a problem with all changes to puppet module
content.
> >>> For example, if I change the source contents of a file in the
''files''
> >>> directory of a module, the master will notice this immediately
and the
> >>> puppet agent on the node will grab the new file on the first
run
> >>> following the change on the master.
>
> >> Fact:
> >> Files sent using "source" aren''t part of the
catalog.  Instead, the client asks the server for them while the client is using
the catalog and not during the compilation done on the server.
>
> >> Speculation:
> >> I would guess this is because the problem you are having is
happening during the compilation on the server.
>
> >>> 2.  At first I thought maybe this was a timing issue (e.g. I
was doing
> >>> the puppet run too quickly after making the resource change)
but it''s
> >>> not; whether I wait 5 seconds or 5 minutes before making the
first
> >>> puppet run, the master still doesn''t notice the
change.  I set the
> >>> ''filetimeout'' setting in
/etc/puppet/puppet.conf to 0 and it didn''t
> >>> help.
>
> >>> Any ideas on what''s going on here? (thanks in advance
for your help)
>
> > Ahh, Ok, that makes sense. The source files are not part of the
> > manifests, just pointed to by them.
>
> > However, I am still having a problem with changed manifests not
> > getting "noticed" by the Puppetmaster until the second run
after it''s
> > been changed. This is only a problem when running puppetmaster as a
> > rack app inside Apache. Of course, if I restart Apache it will serve
> > up the most recent manifests on the first puppet run that connects to
> > it, but it would be irritating to have to restart httpd every time I
> > want to make a change to a module/manifest.
>
> > I also tried setting the puppet.conf option ''ignorecache =
true'' to no
> > avail. (side note: on the "servertype" option in
puppet.conf, official
> > documentation still states that the only valid modes are
''webrick'' and
> > ''mongrel''. What is the appropriate mode for running
with passenger?)
>
> My puppetmaster is working fine and that option isn''t set which
means it''s defaulting to webrick.
>
> > Final note: The puppetmaster always logs that it has compiled a
> > catalog and expired the cached one, even on the first runs where the
> > new manifest does not yet take effect. (and annoyingly, puppetmaster
> > under passenger now logs to /var/log/messages instead of /var/log/
> > puppet/puppetmaster.log;
>
> I don''t know how to fix this, but this doesn''t happen
under Ubuntu.
>
> > it seems puppetmaster as a rack application
> > does not look at /etc/sysconfig/puppetmaster - so I can''t add
options
> > like verbosity, etc.)
>
> Correct.  Files in /etc/sysconfig are red when a service starts.  When
using passenger, the service is apache and puppetmaster is one of it''s
subprocesses.
>
> The equivalent file is config.ru.  It''s in the folder you specify
in the apache config file.  Just do a "find / -name config.ru".
>
> That said, you really shouldn''t need to change it if puppetmaster
is managing to startup at all.
>
> > To me, it seems like there needs to be better Puppet Labs
> > documentation on the differences between running Puppetmaster
> > "normally" (e.g. with /etc/init.d/puppetmaster) versus as a
Rack
> > application.
>
> What distro are you using?
>
> What version of puppet are you using? (puppet --version)
>
> How did you install puppet?
-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

I am having the same issue, and am running about the same stack.

CentOS 5.5

facter (1.5.8)
fastthread (1.0.7)
passenger (2.2.15)
puppet (2.6.2)
puppet-module (0.3.0)
rack (1.1.0)
rake (0.8.7)
stomp (1.1.6)


On Tue, Nov 9, 2010 at 2:50 PM, Kent <kentmshultz@gmail.com> wrote:
> Patrick, thanks for the speedy reply once again.
>
> I''m using RHEL5 and Puppet 2.6.1, Passenger 2.2.7, Rack 1.1.0.
>
> From what I''ve read in this group and in Puppet Labs docs/wikis,
> Debian/Ubuntu users do seem to have an easier time generally than
> CentOS/Red Hat :-\
>
> Can I pass my command-line options to Puppetmasterd in the config.ru
> file?
>
> -Kent
>
> On Nov 9, 10:53 am, Patrick <kc7...@gmail.com> wrote:
> > On Nov 9, 2010, at 9:34 AM, Kent wrote:
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > > On Nov 8, 11:07 am, Patrick <kc7...@gmail.com> wrote:
> > >> On Nov 8, 2010, at 9:10 AM, Kent wrote:
> >
> > >>> Hi all,
> >
> > >>> I''m a new puppet user and new to the forum.
> >
> > >>> I just switched my Puppetmaster to running inside Apache
(via
> > >>> Passenger). When I make a change to a resource on the
master, it
> > >>> sometimes takes a given node TWO runs before the master
will realize
> > >>> the resource has changed and recompile a new catalog
version for the
> > >>> node. For example, say my puppetmaster is serving
configuration
> > >>> version ''123'' to a node. I change the
file permissions for a file
> > >>> resource that''s part of that catalog and then do
a puppet run on the
> > >>> node. If I''m running with Passenger, the master
serves config version
> > >>> ''123'' one more time (the agent makes no
changes). The next time I run
> > >>> the node''s agent, the master compiles new
catalog version ''456'' and
> > >>> the agent makes the permission change.
> >
> > >>> A few items of note:
> >
> > >>> 1.  This is not a problem with all changes to puppet
module content.
> > >>> For example, if I change the source contents of a file in
the ''files''
> > >>> directory of a module, the master will notice this
immediately and
> the
> > >>> puppet agent on the node will grab the new file on the
first run
> > >>> following the change on the master.
> >
> > >> Fact:
> > >> Files sent using "source" aren''t part of
the catalog.  Instead, the
> client asks the server for them while the client is using the catalog and
> not during the compilation done on the server.
> >
> > >> Speculation:
> > >> I would guess this is because the problem you are having is
happening
> during the compilation on the server.
> >
> > >>> 2.  At first I thought maybe this was a timing issue
(e.g. I was
> doing
> > >>> the puppet run too quickly after making the resource
change) but it''s
> > >>> not; whether I wait 5 seconds or 5 minutes before making
the first
> > >>> puppet run, the master still doesn''t notice the
change.  I set the
> > >>> ''filetimeout'' setting in
/etc/puppet/puppet.conf to 0 and it didn''t
> > >>> help.
> >
> > >>> Any ideas on what''s going on here? (thanks in
advance for your help)
> >
> > > Ahh, Ok, that makes sense. The source files are not part of the
> > > manifests, just pointed to by them.
> >
> > > However, I am still having a problem with changed manifests not
> > > getting "noticed" by the Puppetmaster until the second
run after it''s
> > > been changed. This is only a problem when running puppetmaster as
a
> > > rack app inside Apache. Of course, if I restart Apache it will
serve
> > > up the most recent manifests on the first puppet run that
connects to
> > > it, but it would be irritating to have to restart httpd every
time I
> > > want to make a change to a module/manifest.
> >
> > > I also tried setting the puppet.conf option ''ignorecache
= true'' to no
> > > avail. (side note: on the "servertype" option in
puppet.conf, official
> > > documentation still states that the only valid modes are
''webrick'' and
> > > ''mongrel''. What is the appropriate mode for
running with passenger?)
> >
> > My puppetmaster is working fine and that option isn''t set
which means
> it''s defaulting to webrick.
> >
> > > Final note: The puppetmaster always logs that it has compiled a
> > > catalog and expired the cached one, even on the first runs where
the
> > > new manifest does not yet take effect. (and annoyingly,
puppetmaster
> > > under passenger now logs to /var/log/messages instead of
/var/log/
> > > puppet/puppetmaster.log;
> >
> > I don''t know how to fix this, but this doesn''t
happen under Ubuntu.
> >
> > > it seems puppetmaster as a rack application
> > > does not look at /etc/sysconfig/puppetmaster - so I
can''t add options
> > > like verbosity, etc.)
> >
> > Correct.  Files in /etc/sysconfig are red when a service starts.  When
> using passenger, the service is apache and puppetmaster is one of
it''s
> subprocesses.
> >
> > The equivalent file is config.ru.  It''s in the folder you
specify in the
> apache config file.  Just do a "find / -name config.ru".
> >
> > That said, you really shouldn''t need to change it if
puppetmaster is
> managing to startup at all.
> >
> > > To me, it seems like there needs to be better Puppet Labs
> > > documentation on the differences between running Puppetmaster
> > > "normally" (e.g. with /etc/init.d/puppetmaster) versus
as a Rack
> > > application.
> >
> > What distro are you using?
> >
> > What version of puppet are you using? (puppet --version)
> >
> > How did you install puppet?
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To post to this group, send email to puppet-users@googlegroups.com.
> To unsubscribe from this group, send email to
>
puppet-users+unsubscribe@googlegroups.com<puppet-users%2Bunsubscribe@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-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Nov 9, 2010, at 12:50 PM, Kent wrote:
> Patrick, thanks for the speedy reply once again.
> 
> I''m using RHEL5 and Puppet 2.6.1, Passenger 2.2.7, Rack 1.1.0.
> 
> From what I''ve read in this group and in Puppet Labs docs/wikis,
> Debian/Ubuntu users do seem to have an easier time generally than
> CentOS/Red Hat :-\
> 
> Can I pass my command-line options to Puppetmasterd in the config.ru
> file?
> 
> -Kent
I think so, but I don''t think you want to do this.  If the puppetmaster
is working at all under passenger, you should be able to set those settings in
/etc/puppet/puppet.conf.  Here is my config.ru in case that helps:

# a config.ru, for use with every rack-compatible webserver.
# SSL needs to be handled outside this, though.

$0 = "master"

# if you want debugging:
# ARGV << "--debug"

ARGV << "--rack"
require ''puppet/application/master''
# we''re usually running inside a Rack::Builder.new {} block,
# therefore we need to call run *here*.
run Puppet::Application[:master].run


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

I have these same options in my config.ru as well.

---
# a config.ru, for use with every rack-compatible webserver.
# SSL needs to be handled outside this, though.

# if puppet is not in your RUBYLIB:
# $:.unshift(''/opt/puppet/lib'')

$0 = "master"

# if you want debugging:
# ARGV << "--debug"

ARGV << "--rack"
require ''puppet/application/master''
# we''re usually running inside a Rack::Builder.new {} block,
# therefore we need to call run *here*.
run Puppet::Application[:master].run


On Tue, Nov 9, 2010 at 4:02 PM, Patrick <kc7zzv@gmail.com> wrote:
>
> On Nov 9, 2010, at 12:50 PM, Kent wrote:
>
> Patrick, thanks for the speedy reply once again.
>
> I''m using RHEL5 and Puppet 2.6.1, Passenger 2.2.7, Rack 1.1.0.
>
> From what I''ve read in this group and in Puppet Labs docs/wikis,
> Debian/Ubuntu users do seem to have an easier time generally than
> CentOS/Red Hat :-\
>
> Can I pass my command-line options to Puppetmasterd in the config.ru
> file?
>
> -Kent
>
>
> I think so, but *I don''t think you want to do this.*  If the
puppetmaster
> is working at all under passenger, you should be able to set those settings
> in /etc/puppet/puppet.conf.  Here is my config.ru in case that helps:
>
> # a config.ru, for use with every rack-compatible webserver.
> # SSL needs to be handled outside this, though.
>
> $0 = "master"
>
> # if you want debugging:
> # ARGV << "--debug"
>
> ARGV << "--rack"
> require ''puppet/application/master''
> # we''re usually running inside a Rack::Builder.new {} block,
> # therefore we need to call run *here*.
> run Puppet::Application[:master].run
>
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To post to this group, send email to puppet-users@googlegroups.com.
> To unsubscribe from this group, send email to
>
puppet-users+unsubscribe@googlegroups.com<puppet-users%2Bunsubscribe@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-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

I have the same config.ru as well (taken from the Puppet 2.6.1 source
I believe).

Mainly at this point I want to have to puppetmaster to log verbose
output so I can maybe diagnose this catalog compilation issue. Using
webrick you can set extra options for puppetmasterd with
PUPPETMASTER_EXTRA_OPTS, but to my knowledge there is not a way to do
this with puppet.conf.

On Nov 9, 2:02 pm, Patrick <kc7...@gmail.com>
wrote:
> On Nov 9, 2010, at 12:50 PM, Kent wrote:
>
> > Patrick, thanks for the speedy reply once again.
>
> > I''m using RHEL5 and Puppet 2.6.1, Passenger 2.2.7, Rack
1.1.0.
>
> > From what I''ve read in this group and in Puppet Labs
docs/wikis,
> > Debian/Ubuntu users do seem to have an easier time generally than
> > CentOS/Red Hat :-\
>
> > Can I pass my command-line options to Puppetmasterd in the config.ru
> > file?
>
> > -Kent
>
> I think so, but I don''t think you want to do this.  If the
puppetmaster is working at all under passenger, you should be able to set those
settings in /etc/puppet/puppet.conf.  Here is my config.ru in case that helps:
>
> # a config.ru, for use with every rack-compatible webserver.
> # SSL needs to be handled outside this, though.
>
> $0 = "master"
>
> # if you want debugging:
> # ARGV << "--debug"
>
> ARGV << "--rack"
> require ''puppet/application/master''
> # we''re usually running inside a Rack::Builder.new {} block,
> # therefore we need to call run *here*.
> run Puppet::Application[:master].run
-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Tue, Nov 9, 2010 at 3:05 PM, Kent <kentmshultz@gmail.com>
wrote:
> I have the same config.ru as well (taken from the Puppet 2.6.1 source
> I believe).
>
> Mainly at this point I want to have to puppetmaster to log verbose
> output so I can maybe diagnose this catalog compilation issue. Using
> webrick you can set extra options for puppetmasterd with
> PUPPETMASTER_EXTRA_OPTS, but to my knowledge there is not a way to do
> this with puppet.conf.
# if you want debugging:
# ARGV << "--debug"

So you can essentially provide anything that you could specify on the
command line with ARGV in your config.ru like

ARGV << "--debug" << "--verbose" <<
"--trace" << "--evaltrace"

and all those options will apply.
>
> On Nov 9, 2:02 pm, Patrick <kc7...@gmail.com> wrote:
>> On Nov 9, 2010, at 12:50 PM, Kent wrote:
>>
>> > Patrick, thanks for the speedy reply once again.
>>
>> > I''m using RHEL5 and Puppet 2.6.1, Passenger 2.2.7, Rack
1.1.0.
>>
>> > From what I''ve read in this group and in Puppet Labs
docs/wikis,
>> > Debian/Ubuntu users do seem to have an easier time generally than
>> > CentOS/Red Hat :-\
>>
>> > Can I pass my command-line options to Puppetmasterd in the
config.ru
>> > file?
>>
>> > -Kent
>>
>> I think so, but I don''t think you want to do this.  If the
puppetmaster is working at all under passenger, you should be able to set those
settings in /etc/puppet/puppet.conf.  Here is my config.ru in case that helps:
>>
>> # a config.ru, for use with every rack-compatible webserver.
>> # SSL needs to be handled outside this, though.
>>
>> $0 = "master"
>>
>> # if you want debugging:
>> # ARGV << "--debug"
>>
>> ARGV << "--rack"
>> require ''puppet/application/master''
>> # we''re usually running inside a Rack::Builder.new {} block,
>> # therefore we need to call run *here*.
>> run Puppet::Application[:master].run
>
> --
> You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
> To post to this group, send email to puppet-users@googlegroups.com.
> To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
> For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
>
>


-- 
Nigel Kersten - Puppet Labs -  http://www.puppetlabs.com

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

On Nov 9, 2010, at 3:05 PM, Kent wrote:
> I have the same config.ru as well (taken from the Puppet 2.6.1 source
> I believe).
> 
> Mainly at this point I want to have to puppetmaster to log verbose
> output so I can maybe diagnose this catalog compilation issue. Using
> webrick you can set extra options for puppetmasterd with
> PUPPETMASTER_EXTRA_OPTS, but to my knowledge there is not a way to do
> this with puppet.conf.
I think that putting this in /etc/puppet/puppet.conf will do the same thing.

[master]
verbose = true
debug = true
> On Nov 9, 2:02 pm, Patrick <kc7...@gmail.com> wrote:
>> On Nov 9, 2010, at 12:50 PM, Kent wrote:
>> 
>>> Patrick, thanks for the speedy reply once again.
>> 
>>> I''m using RHEL5 and Puppet 2.6.1, Passenger 2.2.7, Rack
1.1.0.
>> 
>>> From what I''ve read in this group and in Puppet Labs
docs/wikis,
>>> Debian/Ubuntu users do seem to have an easier time generally than
>>> CentOS/Red Hat :-\
>> 
>>> Can I pass my command-line options to Puppetmasterd in the
config.ru
>>> file?
>> 
>>> -Kent
>> 
>> I think so, but I don''t think you want to do this.  If the
puppetmaster is working at all under passenger, you should be able to set those
settings in /etc/puppet/puppet.conf.  Here is my config.ru in case that helps:
>> 
>> # a config.ru, for use with every rack-compatible webserver.
>> # SSL needs to be handled outside this, though.
>> 
>> $0 = "master"
>> 
>> # if you want debugging:
>> # ARGV << "--debug"
>> 
>> ARGV << "--rack"
>> require ''puppet/application/master''
>> # we''re usually running inside a Rack::Builder.new {} block,
>> # therefore we need to call run *here*.
>> run Puppet::Application[:master].run
> 
> -- 
> You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
> To post to this group, send email to puppet-users@googlegroups.com.
> To unsubscribe from this group, send email to
puppet-users+unsubscribe@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-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

I''ve seen the same issue as well. I just tested then, adding a simple
notify resource to a node and it took three consecutive runs of
puppetd before the message appeared:

# puppetd --test
info: Retrieving plugin
info: Caching catalog for puppet-master-01
info: Applying configuration version ''1289376693''
notice: Finished catalog run in 30.24 seconds
# puppetd --test
info: Retrieving plugin
info: Caching catalog for puppet-master-01
info: Applying configuration version ''1289377768''
notice: Finished catalog run in 24.98 seconds
# puppetd --test
info: Retrieving plugin
info: Caching catalog for puppet-master-01
info: Applying configuration version ''1289379786''
notice: foo
notice: /Stage[main]//Node[puppet-master-01]/Notify[test]/message:
defined ''message'' as ''foo''
notice: Finished catalog run in 26.46 seconds


# /opt/ruby-enterprise/bin/gem list

*** LOCAL GEMS ***

facter (1.5.8)
fastthread (1.0.7)
mysql (2.8.1)
passenger (2.2.9)
puppet (2.6.2)
rack (1.1.0)
rake (0.8.7)


On Nov 9, 9:08 pm, Jeremy Carroll <phobos...@gmail.com>
wrote:
> I am having the same issue, and am running about the same stack.
>
> CentOS 5.5
>
> facter (1.5.8)
> fastthread (1.0.7)
> passenger (2.2.15)
> puppet (2.6.2)
> puppet-module (0.3.0)
> rack (1.1.0)
> rake (0.8.7)
> stomp (1.1.6)
>
> On Tue, Nov 9, 2010 at 2:50 PM, Kent <kentmshu...@gmail.com> wrote:
> > Patrick, thanks for the speedy reply once again.
>
> > I''m using RHEL5 and Puppet 2.6.1, Passenger 2.2.7, Rack
1.1.0.
>
> > From what I''ve read in this group and in Puppet Labs
docs/wikis,
> > Debian/Ubuntu users do seem to have an easier time generally than
> > CentOS/Red Hat :-\
>
> > Can I pass my command-line options to Puppetmasterd in the config.ru
> > file?
>
> > -Kent
>
> > On Nov 9, 10:53 am, Patrick <kc7...@gmail.com> wrote:
> > > On Nov 9, 2010, at 9:34 AM, Kent wrote:
>
> > > > On Nov 8, 11:07 am, Patrick <kc7...@gmail.com> wrote:
> > > >> On Nov 8, 2010, at 9:10 AM, Kent wrote:
>
> > > >>> Hi all,
>
> > > >>> I''m a new puppet user and new to the forum.
>
> > > >>> I just switched my Puppetmaster to running inside
Apache (via
> > > >>> Passenger). When I make a change to a resource on
the master, it
> > > >>> sometimes takes a given node TWO runs before the
master will realize
> > > >>> the resource has changed and recompile a new catalog
version for the
> > > >>> node. For example, say my puppetmaster is serving
configuration
> > > >>> version ''123'' to a node. I change
the file permissions for a file
> > > >>> resource that''s part of that catalog and
then do a puppet run on the
> > > >>> node. If I''m running with Passenger, the
master serves config version
> > > >>> ''123'' one more time (the agent
makes no changes). The next time I run
> > > >>> the node''s agent, the master compiles new
catalog version ''456'' and
> > > >>> the agent makes the permission change.
>
> > > >>> A few items of note:
>
> > > >>> 1.  This is not a problem with all changes to puppet
module content.
> > > >>> For example, if I change the source contents of a
file in the ''files''
> > > >>> directory of a module, the master will notice this
immediately and
> > the
> > > >>> puppet agent on the node will grab the new file on
the first run
> > > >>> following the change on the master.
>
> > > >> Fact:
> > > >> Files sent using "source" aren''t part
of the catalog.  Instead, the
> > client asks the server for them while the client is using the catalog
and
> > not during the compilation done on the server.
>
> > > >> Speculation:
> > > >> I would guess this is because the problem you are having
is happening
> > during the compilation on the server.
>
> > > >>> 2.  At first I thought maybe this was a timing issue
(e.g. I was
> > doing
> > > >>> the puppet run too quickly after making the resource
change) but it''s
> > > >>> not; whether I wait 5 seconds or 5 minutes before
making the first
> > > >>> puppet run, the master still doesn''t notice
the change.  I set the
> > > >>> ''filetimeout'' setting in
/etc/puppet/puppet.conf to 0 and it didn''t
> > > >>> help.
>
> > > >>> Any ideas on what''s going on here? (thanks
in advance for your help)
>
> > > > Ahh, Ok, that makes sense. The source files are not part of
the
> > > > manifests, just pointed to by them.
>
> > > > However, I am still having a problem with changed manifests
not
> > > > getting "noticed" by the Puppetmaster until the
second run after it''s
> > > > been changed. This is only a problem when running
puppetmaster as a
> > > > rack app inside Apache. Of course, if I restart Apache it
will serve
> > > > up the most recent manifests on the first puppet run that
connects to
> > > > it, but it would be irritating to have to restart httpd
every time I
> > > > want to make a change to a module/manifest.
>
> > > > I also tried setting the puppet.conf option
''ignorecache = true'' to no
> > > > avail. (side note: on the "servertype" option in
puppet.conf, official
> > > > documentation still states that the only valid modes are
''webrick'' and
> > > > ''mongrel''. What is the appropriate mode
for running with passenger?)
>
> > > My puppetmaster is working fine and that option isn''t
set which means
> > it''s defaulting to webrick.
>
> > > > Final note: The puppetmaster always logs that it has
compiled a
> > > > catalog and expired the cached one, even on the first runs
where the
> > > > new manifest does not yet take effect. (and annoyingly,
puppetmaster
> > > > under passenger now logs to /var/log/messages instead of
/var/log/
> > > > puppet/puppetmaster.log;
>
> > > I don''t know how to fix this, but this doesn''t
happen under Ubuntu.
>
> > > > it seems puppetmaster as a rack application
> > > > does not look at /etc/sysconfig/puppetmaster - so I
can''t add options
> > > > like verbosity, etc.)
>
> > > Correct.  Files in /etc/sysconfig are red when a service starts.
 When
> > using passenger, the service is apache and puppetmaster is one of
it''s
> > subprocesses.
>
> > > The equivalent file is config.ru.  It''s in the folder
you specify in the
> > apache config file.  Just do a "find / -name config.ru".
>
> > > That said, you really shouldn''t need to change it if
puppetmaster is
> > managing to startup at all.
>
> > > > To me, it seems like there needs to be better Puppet Labs
> > > > documentation on the differences between running
Puppetmaster
> > > > "normally" (e.g. with /etc/init.d/puppetmaster)
versus as a Rack
> > > > application.
>
> > > What distro are you using?
>
> > > What version of puppet are you using? (puppet --version)
>
> > > How did you install puppet?
>
> > --
> > You received this message because you are subscribed to the Google
Groups
> > "Puppet Users" group.
> > To post to this group, send email to puppet-users@googlegroups.com.
> > To unsubscribe from this group, send email to
> >
puppet-users+unsubscribe@googlegroups.com<puppet-users%2Bunsubscribe@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-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Wed, Nov 10, 2010 at 1:08 AM, luke.bigum <luke.bigum@fasthosts.co.uk>
wrote:
> I''ve seen the same issue as well. I just tested then, adding a
simple
> notify resource to a node and it took three consecutive runs of
> puppetd before the message appeared:
Is it the number of runs or is it simply time based?
>
> # puppetd --test
> info: Retrieving plugin
> info: Caching catalog for puppet-master-01
> info: Applying configuration version ''1289376693''
> notice: Finished catalog run in 30.24 seconds
> # puppetd --test
> info: Retrieving plugin
> info: Caching catalog for puppet-master-01
> info: Applying configuration version ''1289377768''
> notice: Finished catalog run in 24.98 seconds
> # puppetd --test
> info: Retrieving plugin
> info: Caching catalog for puppet-master-01
> info: Applying configuration version ''1289379786''
> notice: foo
> notice: /Stage[main]//Node[puppet-master-01]/Notify[test]/message:
> defined ''message'' as ''foo''
> notice: Finished catalog run in 26.46 seconds
>
>
> # /opt/ruby-enterprise/bin/gem list
>
> *** LOCAL GEMS ***
>
> facter (1.5.8)
> fastthread (1.0.7)
> mysql (2.8.1)
> passenger (2.2.9)
> puppet (2.6.2)
> rack (1.1.0)
> rake (0.8.7)
>
>
> On Nov 9, 9:08 pm, Jeremy Carroll <phobos...@gmail.com> wrote:
>> I am having the same issue, and am running about the same stack.
>>
>> CentOS 5.5
>>
>> facter (1.5.8)
>> fastthread (1.0.7)
>> passenger (2.2.15)
>> puppet (2.6.2)
>> puppet-module (0.3.0)
>> rack (1.1.0)
>> rake (0.8.7)
>> stomp (1.1.6)
>>
>> On Tue, Nov 9, 2010 at 2:50 PM, Kent <kentmshu...@gmail.com>
wrote:
>> > Patrick, thanks for the speedy reply once again.
>>
>> > I''m using RHEL5 and Puppet 2.6.1, Passenger 2.2.7, Rack
1.1.0.
>>
>> > From what I''ve read in this group and in Puppet Labs
docs/wikis,
>> > Debian/Ubuntu users do seem to have an easier time generally than
>> > CentOS/Red Hat :-\
>>
>> > Can I pass my command-line options to Puppetmasterd in the
config.ru
>> > file?
>>
>> > -Kent
>>
>> > On Nov 9, 10:53 am, Patrick <kc7...@gmail.com> wrote:
>> > > On Nov 9, 2010, at 9:34 AM, Kent wrote:
>>
>> > > > On Nov 8, 11:07 am, Patrick <kc7...@gmail.com>
wrote:
>> > > >> On Nov 8, 2010, at 9:10 AM, Kent wrote:
>>
>> > > >>> Hi all,
>>
>> > > >>> I''m a new puppet user and new to the
forum.
>>
>> > > >>> I just switched my Puppetmaster to running
inside Apache (via
>> > > >>> Passenger). When I make a change to a resource
on the master, it
>> > > >>> sometimes takes a given node TWO runs before the
master will realize
>> > > >>> the resource has changed and recompile a new
catalog version for the
>> > > >>> node. For example, say my puppetmaster is
serving configuration
>> > > >>> version ''123'' to a node. I
change the file permissions for a file
>> > > >>> resource that''s part of that catalog
and then do a puppet run on the
>> > > >>> node. If I''m running with Passenger,
the master serves config version
>> > > >>> ''123'' one more time (the agent
makes no changes). The next time I run
>> > > >>> the node''s agent, the master compiles
new catalog version ''456'' and
>> > > >>> the agent makes the permission change.
>>
>> > > >>> A few items of note:
>>
>> > > >>> 1.  This is not a problem with all changes to
puppet module content.
>> > > >>> For example, if I change the source contents of
a file in the ''files''
>> > > >>> directory of a module, the master will notice
this immediately and
>> > the
>> > > >>> puppet agent on the node will grab the new file
on the first run
>> > > >>> following the change on the master.
>>
>> > > >> Fact:
>> > > >> Files sent using "source" aren''t
part of the catalog.  Instead, the
>> > client asks the server for them while the client is using the
catalog and
>> > not during the compilation done on the server.
>>
>> > > >> Speculation:
>> > > >> I would guess this is because the problem you are
having is happening
>> > during the compilation on the server.
>>
>> > > >>> 2.  At first I thought maybe this was a timing
issue (e.g. I was
>> > doing
>> > > >>> the puppet run too quickly after making the
resource change) but it''s
>> > > >>> not; whether I wait 5 seconds or 5 minutes
before making the first
>> > > >>> puppet run, the master still doesn''t
notice the change.  I set the
>> > > >>> ''filetimeout'' setting in
/etc/puppet/puppet.conf to 0 and it didn''t
>> > > >>> help.
>>
>> > > >>> Any ideas on what''s going on here?
(thanks in advance for your help)
>>
>> > > > Ahh, Ok, that makes sense. The source files are not part
of the
>> > > > manifests, just pointed to by them.
>>
>> > > > However, I am still having a problem with changed
manifests not
>> > > > getting "noticed" by the Puppetmaster until
the second run after it''s
>> > > > been changed. This is only a problem when running
puppetmaster as a
>> > > > rack app inside Apache. Of course, if I restart Apache
it will serve
>> > > > up the most recent manifests on the first puppet run
that connects to
>> > > > it, but it would be irritating to have to restart httpd
every time I
>> > > > want to make a change to a module/manifest.
>>
>> > > > I also tried setting the puppet.conf option
''ignorecache = true'' to no
>> > > > avail. (side note: on the "servertype" option
in puppet.conf, official
>> > > > documentation still states that the only valid modes are
''webrick'' and
>> > > > ''mongrel''. What is the appropriate
mode for running with passenger?)
>>
>> > > My puppetmaster is working fine and that option
isn''t set which means
>> > it''s defaulting to webrick.
>>
>> > > > Final note: The puppetmaster always logs that it has
compiled a
>> > > > catalog and expired the cached one, even on the first
runs where the
>> > > > new manifest does not yet take effect. (and annoyingly,
puppetmaster
>> > > > under passenger now logs to /var/log/messages instead of
/var/log/
>> > > > puppet/puppetmaster.log;
>>
>> > > I don''t know how to fix this, but this
doesn''t happen under Ubuntu.
>>
>> > > > it seems puppetmaster as a rack application
>> > > > does not look at /etc/sysconfig/puppetmaster - so I
can''t add options
>> > > > like verbosity, etc.)
>>
>> > > Correct.  Files in /etc/sysconfig are red when a service
starts.  When
>> > using passenger, the service is apache and puppetmaster is one of
it''s
>> > subprocesses.
>>
>> > > The equivalent file is config.ru.  It''s in the
folder you specify in the
>> > apache config file.  Just do a "find / -name config.ru".
>>
>> > > That said, you really shouldn''t need to change it if
puppetmaster is
>> > managing to startup at all.
>>
>> > > > To me, it seems like there needs to be better Puppet
Labs
>> > > > documentation on the differences between running
Puppetmaster
>> > > > "normally" (e.g. with
/etc/init.d/puppetmaster) versus as a Rack
>> > > > application.
>>
>> > > What distro are you using?
>>
>> > > What version of puppet are you using? (puppet --version)
>>
>> > > How did you install puppet?
>>
>> > --
>> > You received this message because you are subscribed to the Google
Groups
>> > "Puppet Users" group.
>> > To post to this group, send email to
puppet-users@googlegroups.com.
>> > To unsubscribe from this group, send email to
>> >
puppet-users+unsubscribe@googlegroups.com<puppet-users%2Bunsubscribe@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-users@googlegroups.com.
> To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
> For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
>
>


-- 
Nigel Kersten - Puppet Labs -  http://www.puppetlabs.com

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

Nigel,

It is number-of-runs based. If I execute two runs in rapid succession
2 seconds after changing a manifest on the puppetmaster, the new
config *will* be pushed on the second run. On the other hand I can
walk away for 10 minutes and when I then execute the runs, the new
config will still not take effect until the second run.

Is it likely this has something to do with catalog caching on the
master? I tried turning caching off by setting ''ignorecache =
true'' in
puppet.conf but this didn''t help, so maybe this isn''t the
issue here.

-Kent

On Nov 14, 8:18 am, Nigel Kersten <ni...@puppetlabs.com>
wrote:
> On Wed, Nov 10, 2010 at 1:08 AM, luke.bigum
<luke.bi...@fasthosts.co.uk> wrote:
> > I''ve seen the same issue as well. I just tested then, adding
a simple
> > notify resource to a node and it took three consecutive runs of
> > puppetd before the message appeared:
>
> Is it the number of runs or is it simply time based?
>
>
>
>
>
>
>
>
>
>
>
> > # puppetd --test
> > info: Retrieving plugin
> > info: Caching catalog for puppet-master-01
> > info: Applying configuration version ''1289376693''
> > notice: Finished catalog run in 30.24 seconds
> > # puppetd --test
> > info: Retrieving plugin
> > info: Caching catalog for puppet-master-01
> > info: Applying configuration version ''1289377768''
> > notice: Finished catalog run in 24.98 seconds
> > # puppetd --test
> > info: Retrieving plugin
> > info: Caching catalog for puppet-master-01
> > info: Applying configuration version ''1289379786''
> > notice: foo
> > notice: /Stage[main]//Node[puppet-master-01]/Notify[test]/message:
> > defined ''message'' as ''foo''
> > notice: Finished catalog run in 26.46 seconds
>
> > # /opt/ruby-enterprise/bin/gem list
>
> > *** LOCAL GEMS ***
>
> > facter (1.5.8)
> > fastthread (1.0.7)
> > mysql (2.8.1)
> > passenger (2.2.9)
> > puppet (2.6.2)
> > rack (1.1.0)
> > rake (0.8.7)
>
> > On Nov 9, 9:08 pm, Jeremy Carroll <phobos...@gmail.com> wrote:
> >> I am having the same issue, and am running about the same stack.
>
> >> CentOS 5.5
>
> >> facter (1.5.8)
> >> fastthread (1.0.7)
> >> passenger (2.2.15)
> >> puppet (2.6.2)
> >> puppet-module (0.3.0)
> >> rack (1.1.0)
> >> rake (0.8.7)
> >> stomp (1.1.6)
>
> >> On Tue, Nov 9, 2010 at 2:50 PM, Kent <kentmshu...@gmail.com>
wrote:
> >> > Patrick, thanks for the speedy reply once again.
>
> >> > I''m using RHEL5 and Puppet 2.6.1, Passenger 2.2.7,
Rack 1.1.0.
>
> >> > From what I''ve read in this group and in Puppet Labs
docs/wikis,
> >> > Debian/Ubuntu users do seem to have an easier time generally
than
> >> > CentOS/Red Hat :-\
>
> >> > Can I pass my command-line options to Puppetmasterd in the
config.ru
> >> > file?
>
> >> > -Kent
>
> >> > On Nov 9, 10:53 am, Patrick <kc7...@gmail.com> wrote:
> >> > > On Nov 9, 2010, at 9:34 AM, Kent wrote:
>
> >> > > > On Nov 8, 11:07 am, Patrick
<kc7...@gmail.com> wrote:
> >> > > >> On Nov 8, 2010, at 9:10 AM, Kent wrote:
>
> >> > > >>> Hi all,
>
> >> > > >>> I''m a new puppet user and new to
the forum.
>
> >> > > >>> I just switched my Puppetmaster to running
inside Apache (via
> >> > > >>> Passenger). When I make a change to a
resource on the master, it
> >> > > >>> sometimes takes a given node TWO runs
before the master will realize
> >> > > >>> the resource has changed and recompile a
new catalog version for the
> >> > > >>> node. For example, say my puppetmaster is
serving configuration
> >> > > >>> version ''123'' to a node.
I change the file permissions for a file
> >> > > >>> resource that''s part of that
catalog and then do a puppet run on the
> >> > > >>> node. If I''m running with
Passenger, the master serves config version
> >> > > >>> ''123'' one more time (the
agent makes no changes). The next time I run
> >> > > >>> the node''s agent, the master
compiles new catalog version ''456'' and
> >> > > >>> the agent makes the permission change.
>
> >> > > >>> A few items of note:
>
> >> > > >>> 1.  This is not a problem with all changes
to puppet module content.
> >> > > >>> For example, if I change the source
contents of a file in the ''files''
> >> > > >>> directory of a module, the master will
notice this immediately and
> >> > the
> >> > > >>> puppet agent on the node will grab the new
file on the first run
> >> > > >>> following the change on the master.
>
> >> > > >> Fact:
> >> > > >> Files sent using "source"
aren''t part of the catalog.  Instead, the
> >> > client asks the server for them while the client is using the
catalog and
> >> > not during the compilation done on the server.
>
> >> > > >> Speculation:
> >> > > >> I would guess this is because the problem you
are having is happening
> >> > during the compilation on the server.
>
> >> > > >>> 2.  At first I thought maybe this was a
timing issue (e.g. I was
> >> > doing
> >> > > >>> the puppet run too quickly after making the
resource change) but it''s
> >> > > >>> not; whether I wait 5 seconds or 5 minutes
before making the first
> >> > > >>> puppet run, the master still
doesn''t notice the change.  I set the
> >> > > >>> ''filetimeout'' setting in
/etc/puppet/puppet.conf to 0 and it didn''t
> >> > > >>> help.
>
> >> > > >>> Any ideas on what''s going on here?
(thanks in advance for your help)
>
> >> > > > Ahh, Ok, that makes sense. The source files are not
part of the
> >> > > > manifests, just pointed to by them.
>
> >> > > > However, I am still having a problem with changed
manifests not
> >> > > > getting "noticed" by the Puppetmaster
until the second run after it''s
> >> > > > been changed. This is only a problem when running
puppetmaster as a
> >> > > > rack app inside Apache. Of course, if I restart
Apache it will serve
> >> > > > up the most recent manifests on the first puppet
run that connects to
> >> > > > it, but it would be irritating to have to restart
httpd every time I
> >> > > > want to make a change to a module/manifest.
>
> >> > > > I also tried setting the puppet.conf option
''ignorecache = true'' to no
> >> > > > avail. (side note: on the "servertype"
option in puppet.conf, official
> >> > > > documentation still states that the only valid
modes are ''webrick'' and
> >> > > > ''mongrel''. What is the
appropriate mode for running with passenger?)
>
> >> > > My puppetmaster is working fine and that option
isn''t set which means
> >> > it''s defaulting to webrick.
>
> >> > > > Final note: The puppetmaster always logs that it
has compiled a
> >> > > > catalog and expired the cached one, even on the
first runs where the
> >> > > > new manifest does not yet take effect. (and
annoyingly, puppetmaster
> >> > > > under passenger now logs to /var/log/messages
instead of /var/log/
> >> > > > puppet/puppetmaster.log;
>
> >> > > I don''t know how to fix this, but this
doesn''t happen under Ubuntu.
>
> >> > > > it seems puppetmaster as a rack application
> >> > > > does not look at /etc/sysconfig/puppetmaster - so I
can''t add options
> >> > > > like verbosity, etc.)
>
> >> > > Correct.  Files in /etc/sysconfig are red when a service
starts.  When
> >> > using passenger, the service is apache and puppetmaster is
one of it''s
> >> > subprocesses.
>
> >> > > The equivalent file is config.ru.  It''s in the
folder you specify in the
> >> > apache config file.  Just do a "find / -name
config.ru".
>
> >> > > That said, you really shouldn''t need to change
it if puppetmaster is
> >> > managing to startup at all.
>
> >> > > > To me, it seems like there needs to be better
Puppet Labs
> >> > > > documentation on the differences between running
Puppetmaster
> >> > > > "normally" (e.g. with
/etc/init.d/puppetmaster) versus as a Rack
> >> > > > application.
>
> >> > > What distro are you using?
>
> >> > > What version of puppet are you using? (puppet --version)
>
> >> > > How did you install puppet?
>
> >> > --
> >> > You received this message because you are subscribed to the
Google Groups
> >> > "Puppet Users" group.
> >> > To post to this group, send email to
puppet-users@googlegroups.com.
> >> > To unsubscribe from this group, send email to
> >> >
puppet-users+unsubscribe@googlegroups.com<puppet-users%2Bunsubscribe@google
groups.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-users@googlegroups.com.
> > To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
> > For more options, visit this group
athttp://groups.google.com/group/puppet-users?hl=en.
>
> --
> Nigel Kersten - Puppet Labs -  http://www.puppetlabs.com
-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

Hi Kent,

On Mon, Nov 15, 2010 at 8:05 AM, Kent <kentmshultz@gmail.com> wrote:
> Nigel,
>
> It is number-of-runs based. If I execute two runs in rapid succession
> 2 seconds after changing a manifest on the puppetmaster, the new
> config *will* be pushed on the second run. On the other hand I can
> walk away for 10 minutes and when I then execute the runs, the new
> config will still not take effect until the second run.
>
> Is it likely this has something to do with catalog caching on the
> master? I tried turning caching off by setting ''ignorecache =
true'' in
> puppet.conf

this is a client side configuration, it probably won''t help.

but this didn''t help, so maybe this isn''t the issue
here.
>
try setting filetimeout=0 on the puppet master

for more information you can:

man puppet.conf

> -Kent
>
> On Nov 14, 8:18 am, Nigel Kersten <ni...@puppetlabs.com> wrote:
> > On Wed, Nov 10, 2010 at 1:08 AM, luke.bigum
<luke.bi...@fasthosts.co.uk>
> wrote:
> > > I''ve seen the same issue as well. I just tested then,
adding a simple
> > > notify resource to a node and it took three consecutive runs of
> > > puppetd before the message appeared:
> >
> > Is it the number of runs or is it simply time based?
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > > # puppetd --test
> > > info: Retrieving plugin
> > > info: Caching catalog for puppet-master-01
> > > info: Applying configuration version
''1289376693''
> > > notice: Finished catalog run in 30.24 seconds
> > > # puppetd --test
> > > info: Retrieving plugin
> > > info: Caching catalog for puppet-master-01
> > > info: Applying configuration version
''1289377768''
> > > notice: Finished catalog run in 24.98 seconds
> > > # puppetd --test
> > > info: Retrieving plugin
> > > info: Caching catalog for puppet-master-01
> > > info: Applying configuration version
''1289379786''
> > > notice: foo
> > > notice:
/Stage[main]//Node[puppet-master-01]/Notify[test]/message:
> > > defined ''message'' as ''foo''
> > > notice: Finished catalog run in 26.46 seconds
> >
> > > # /opt/ruby-enterprise/bin/gem list
> >
> > > *** LOCAL GEMS ***
> >
> > > facter (1.5.8)
> > > fastthread (1.0.7)
> > > mysql (2.8.1)
> > > passenger (2.2.9)
> > > puppet (2.6.2)
> > > rack (1.1.0)
> > > rake (0.8.7)
> >
> > > On Nov 9, 9:08 pm, Jeremy Carroll <phobos...@gmail.com>
wrote:
> > >> I am having the same issue, and am running about the same
stack.
> >
> > >> CentOS 5.5
> >
> > >> facter (1.5.8)
> > >> fastthread (1.0.7)
> > >> passenger (2.2.15)
> > >> puppet (2.6.2)
> > >> puppet-module (0.3.0)
> > >> rack (1.1.0)
> > >> rake (0.8.7)
> > >> stomp (1.1.6)
> >
> > >> On Tue, Nov 9, 2010 at 2:50 PM, Kent
<kentmshu...@gmail.com> wrote:
> > >> > Patrick, thanks for the speedy reply once again.
> >
> > >> > I''m using RHEL5 and Puppet 2.6.1, Passenger
2.2.7, Rack 1.1.0.
> >
> > >> > From what I''ve read in this group and in Puppet
Labs docs/wikis,
> > >> > Debian/Ubuntu users do seem to have an easier time
generally than
> > >> > CentOS/Red Hat :-\
> >
> > >> > Can I pass my command-line options to Puppetmasterd in
the
> config.ru
> > >> > file?
> >
> > >> > -Kent
> >
> > >> > On Nov 9, 10:53 am, Patrick <kc7...@gmail.com>
wrote:
> > >> > > On Nov 9, 2010, at 9:34 AM, Kent wrote:
> >
> > >> > > > On Nov 8, 11:07 am, Patrick
<kc7...@gmail.com> wrote:
> > >> > > >> On Nov 8, 2010, at 9:10 AM, Kent wrote:
> >
> > >> > > >>> Hi all,
> >
> > >> > > >>> I''m a new puppet user and new
to the forum.
> >
> > >> > > >>> I just switched my Puppetmaster to
running inside Apache (via
> > >> > > >>> Passenger). When I make a change to a
resource on the master,
> it
> > >> > > >>> sometimes takes a given node TWO runs
before the master will
> realize
> > >> > > >>> the resource has changed and recompile
a new catalog version
> for the
> > >> > > >>> node. For example, say my puppetmaster
is serving
> configuration
> > >> > > >>> version ''123'' to a
node. I change the file permissions for a
> file
> > >> > > >>> resource that''s part of that
catalog and then do a puppet run
> on the
> > >> > > >>> node. If I''m running with
Passenger, the master serves config
> version
> > >> > > >>> ''123'' one more time
(the agent makes no changes). The next
> time I run
> > >> > > >>> the node''s agent, the master
compiles new catalog version
> ''456'' and
> > >> > > >>> the agent makes the permission change.
> >
> > >> > > >>> A few items of note:
> >
> > >> > > >>> 1.  This is not a problem with all
changes to puppet module
> content.
> > >> > > >>> For example, if I change the source
contents of a file in the
> ''files''
> > >> > > >>> directory of a module, the master will
notice this immediately
> and
> > >> > the
> > >> > > >>> puppet agent on the node will grab the
new file on the first
> run
> > >> > > >>> following the change on the master.
> >
> > >> > > >> Fact:
> > >> > > >> Files sent using "source"
aren''t part of the catalog.  Instead,
> the
> > >> > client asks the server for them while the client is
using the
> catalog and
> > >> > not during the compilation done on the server.
> >
> > >> > > >> Speculation:
> > >> > > >> I would guess this is because the problem
you are having is
> happening
> > >> > during the compilation on the server.
> >
> > >> > > >>> 2.  At first I thought maybe this was
a timing issue (e.g. I
> was
> > >> > doing
> > >> > > >>> the puppet run too quickly after
making the resource change)
> but it''s
> > >> > > >>> not; whether I wait 5 seconds or 5
minutes before making the
> first
> > >> > > >>> puppet run, the master still
doesn''t notice the change.  I set
> the
> > >> > > >>> ''filetimeout''
setting in /etc/puppet/puppet.conf to 0 and it
> didn''t
> > >> > > >>> help.
> >
> > >> > > >>> Any ideas on what''s going on
here? (thanks in advance for your
> help)
> >
> > >> > > > Ahh, Ok, that makes sense. The source files
are not part of the
> > >> > > > manifests, just pointed to by them.
> >
> > >> > > > However, I am still having a problem with
changed manifests not
> > >> > > > getting "noticed" by the
Puppetmaster until the second run after
> it''s
> > >> > > > been changed. This is only a problem when
running puppetmaster
> as a
> > >> > > > rack app inside Apache. Of course, if I
restart Apache it will
> serve
> > >> > > > up the most recent manifests on the first
puppet run that
> connects to
> > >> > > > it, but it would be irritating to have to
restart httpd every
> time I
> > >> > > > want to make a change to a module/manifest.
> >
> > >> > > > I also tried setting the puppet.conf option
''ignorecache = true''
> to no
> > >> > > > avail. (side note: on the
"servertype" option in puppet.conf,
> official
> > >> > > > documentation still states that the only valid
modes are
> ''webrick'' and
> > >> > > > ''mongrel''. What is the
appropriate mode for running with
> passenger?)
> >
> > >> > > My puppetmaster is working fine and that option
isn''t set which
> means
> > >> > it''s defaulting to webrick.
> >
> > >> > > > Final note: The puppetmaster always logs that
it has compiled a
> > >> > > > catalog and expired the cached one, even on
the first runs where
> the
> > >> > > > new manifest does not yet take effect. (and
annoyingly,
> puppetmaster
> > >> > > > under passenger now logs to /var/log/messages
instead of
> /var/log/
> > >> > > > puppet/puppetmaster.log;
> >
> > >> > > I don''t know how to fix this, but this
doesn''t happen under
> Ubuntu.
> >
> > >> > > > it seems puppetmaster as a rack application
> > >> > > > does not look at /etc/sysconfig/puppetmaster -
so I can''t add
> options
> > >> > > > like verbosity, etc.)
> >
> > >> > > Correct.  Files in /etc/sysconfig are red when a
service starts.
>  When
> > >> > using passenger, the service is apache and puppetmaster
is one of
> it''s
> > >> > subprocesses.
> >
> > >> > > The equivalent file is config.ru.  It''s in
the folder you specify
> in the
> > >> > apache config file.  Just do a "find / -name
config.ru".
> >
> > >> > > That said, you really shouldn''t need to
change it if puppetmaster
> is
> > >> > managing to startup at all.
> >
> > >> > > > To me, it seems like there needs to be better
Puppet Labs
> > >> > > > documentation on the differences between
running Puppetmaster
> > >> > > > "normally" (e.g. with
/etc/init.d/puppetmaster) versus as a Rack
> > >> > > > application.
> >
> > >> > > What distro are you using?
> >
> > >> > > What version of puppet are you using? (puppet
--version)
> >
> > >> > > How did you install puppet?
> >
> > >> > --
> > >> > You received this message because you are subscribed to
the Google
> Groups
> > >> > "Puppet Users" group.
> > >> > To post to this group, send email to
puppet-users@googlegroups.com.
> > >> > To unsubscribe from this group, send email to
> > >> >
puppet-users+unsubscribe@googlegroups.com<puppet-users%2Bunsubscribe@googlegroups.com>
> <puppet-users%2Bunsubscribe@google groups.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-users@googlegroups.com.
> > > To unsubscribe from this group, send email to
>
puppet-users+unsubscribe@googlegroups.com<puppet-users%2Bunsubscribe@googlegroups.com>
> .
> > > For more options, visit this group athttp://
> groups.google.com/group/puppet-users?hl=en.
> >
> > --
> > Nigel Kersten - Puppet Labs -  http://www.puppetlabs.com
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To post to this group, send email to puppet-users@googlegroups.com.
> To unsubscribe from this group, send email to
>
puppet-users+unsubscribe@googlegroups.com<puppet-users%2Bunsubscribe@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-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

Already tried filetimeout=0 with no success.

the description for the setting ignorecache in puppet.conf man page:

"
Ignore  cache  and  always  recompile the configuration. This is
useful for testing new configurations, where the
local cache may in fact be stale even if the timestamps are up to date
- if the facts change  or  if  the  server
changes.
"

This sounds like a server setting to me since it mentions compilation.
In any case, the puppetmaster''s log reports that on every run it
expires the cached catalog for the host making the run, and that it
recompiles for the host.


On Nov 15, 8:46 am, Dan Bode <d...@puppetlabs.com>
wrote:
> Hi Kent,
>
> On Mon, Nov 15, 2010 at 8:05 AM, Kent <kentmshu...@gmail.com> wrote:
> > Nigel,
>
> > It is number-of-runs based. If I execute two runs in rapid succession
> > 2 seconds after changing a manifest on the puppetmaster, the new
> > config *will* be pushed on the second run. On the other hand I can
> > walk away for 10 minutes and when I then execute the runs, the new
> > config will still not take effect until the second run.
>
> > Is it likely this has something to do with catalog caching on the
> > master? I tried turning caching off by setting ''ignorecache =
true'' in
> > puppet.conf
>
> this is a client side configuration, it probably won''t help.
>
> but this didn''t help, so maybe this isn''t the issue here.
>
>
>
> try setting filetimeout=0 on the puppet master
>
> for more information you can:
>
> man puppet.conf
>
>
>
>
>
>
>
> > -Kent
>
> > On Nov 14, 8:18 am, Nigel Kersten <ni...@puppetlabs.com> wrote:
> > > On Wed, Nov 10, 2010 at 1:08 AM, luke.bigum
<luke.bi...@fasthosts.co.uk>
> > wrote:
> > > > I''ve seen the same issue as well. I just tested
then, adding a simple
> > > > notify resource to a node and it took three consecutive runs
of
> > > > puppetd before the message appeared:
>
> > > Is it the number of runs or is it simply time based?
>
> > > > # puppetd --test
> > > > info: Retrieving plugin
> > > > info: Caching catalog for puppet-master-01
> > > > info: Applying configuration version
''1289376693''
> > > > notice: Finished catalog run in 30.24 seconds
> > > > # puppetd --test
> > > > info: Retrieving plugin
> > > > info: Caching catalog for puppet-master-01
> > > > info: Applying configuration version
''1289377768''
> > > > notice: Finished catalog run in 24.98 seconds
> > > > # puppetd --test
> > > > info: Retrieving plugin
> > > > info: Caching catalog for puppet-master-01
> > > > info: Applying configuration version
''1289379786''
> > > > notice: foo
> > > > notice:
/Stage[main]//Node[puppet-master-01]/Notify[test]/message:
> > > > defined ''message'' as
''foo''
> > > > notice: Finished catalog run in 26.46 seconds
>
> > > > # /opt/ruby-enterprise/bin/gem list
>
> > > > *** LOCAL GEMS ***
>
> > > > facter (1.5.8)
> > > > fastthread (1.0.7)
> > > > mysql (2.8.1)
> > > > passenger (2.2.9)
> > > > puppet (2.6.2)
> > > > rack (1.1.0)
> > > > rake (0.8.7)
>
> > > > On Nov 9, 9:08 pm, Jeremy Carroll
<phobos...@gmail.com> wrote:
> > > >> I am having the same issue, and am running about the
same stack.
>
> > > >> CentOS 5.5
>
> > > >> facter (1.5.8)
> > > >> fastthread (1.0.7)
> > > >> passenger (2.2.15)
> > > >> puppet (2.6.2)
> > > >> puppet-module (0.3.0)
> > > >> rack (1.1.0)
> > > >> rake (0.8.7)
> > > >> stomp (1.1.6)
>
> > > >> On Tue, Nov 9, 2010 at 2:50 PM, Kent
<kentmshu...@gmail.com> wrote:
> > > >> > Patrick, thanks for the speedy reply once again.
>
> > > >> > I''m using RHEL5 and Puppet 2.6.1,
Passenger 2.2.7, Rack 1.1.0.
>
> > > >> > From what I''ve read in this group and in
Puppet Labs docs/wikis,
> > > >> > Debian/Ubuntu users do seem to have an easier time
generally than
> > > >> > CentOS/Red Hat :-\
>
> > > >> > Can I pass my command-line options to Puppetmasterd
in the
> > config.ru
> > > >> > file?
>
> > > >> > -Kent
>
> > > >> > On Nov 9, 10:53 am, Patrick
<kc7...@gmail.com> wrote:
> > > >> > > On Nov 9, 2010, at 9:34 AM, Kent wrote:
>
> > > >> > > > On Nov 8, 11:07 am, Patrick
<kc7...@gmail.com> wrote:
> > > >> > > >> On Nov 8, 2010, at 9:10 AM, Kent
wrote:
>
> > > >> > > >>> Hi all,
>
> > > >> > > >>> I''m a new puppet user
and new to the forum.
>
> > > >> > > >>> I just switched my Puppetmaster
to running inside Apache (via
> > > >> > > >>> Passenger). When I make a change
to a resource on the master,
> > it
> > > >> > > >>> sometimes takes a given node TWO
runs before the master will
> > realize
> > > >> > > >>> the resource has changed and
recompile a new catalog version
> > for the
> > > >> > > >>> node. For example, say my
puppetmaster is serving
> > configuration
> > > >> > > >>> version ''123''
to a node. I change the file permissions for a
> > file
> > > >> > > >>> resource that''s part of
that catalog and then do a puppet run
> > on the
> > > >> > > >>> node. If I''m running
with Passenger, the master serves config
> > version
> > > >> > > >>> ''123'' one more
time (the agent makes no changes). The next
> > time I run
> > > >> > > >>> the node''s agent, the
master compiles new catalog version
> > ''456'' and
> > > >> > > >>> the agent makes the permission
change.
>
> > > >> > > >>> A few items of note:
>
> > > >> > > >>> 1.  This is not a problem with
all changes to puppet module
> > content.
> > > >> > > >>> For example, if I change the
source contents of a file in the
> > ''files''
> > > >> > > >>> directory of a module, the master
will notice this immediately
> > and
> > > >> > the
> > > >> > > >>> puppet agent on the node will
grab the new file on the first
> > run
> > > >> > > >>> following the change on the
master.
>
> > > >> > > >> Fact:
> > > >> > > >> Files sent using "source"
aren''t part of the catalog.  Instead,
> > the
> > > >> > client asks the server for them while the client is
using the
> > catalog and
> > > >> > not during the compilation done on the server.
>
> > > >> > > >> Speculation:
> > > >> > > >> I would guess this is because the
problem you are having is
> > happening
> > > >> > during the compilation on the server.
>
> > > >> > > >>> 2.  At first I thought maybe this
was a timing issue (e.g. I
> > was
> > > >> > doing
> > > >> > > >>> the puppet run too quickly after
making the resource change)
> > but it''s
> > > >> > > >>> not; whether I wait 5 seconds or
5 minutes before making the
> > first
> > > >> > > >>> puppet run, the master still
doesn''t notice the change.  I set
> > the
> > > >> > > >>> ''filetimeout''
setting in /etc/puppet/puppet.conf to 0 and it
> > didn''t
> > > >> > > >>> help.
>
> > > >> > > >>> Any ideas on what''s
going on here? (thanks in advance for your
> > help)
>
> > > >> > > > Ahh, Ok, that makes sense. The source
files are not part of the
> > > >> > > > manifests, just pointed to by them.
>
> > > >> > > > However, I am still having a problem with
changed manifests not
> > > >> > > > getting "noticed" by the
Puppetmaster until the second run after
> > it''s
> > > >> > > > been changed. This is only a problem when
running puppetmaster
> > as a
> > > >> > > > rack app inside Apache. Of course, if I
restart Apache it will
> > serve
> > > >> > > > up the most recent manifests on the first
puppet run that
> > connects to
> > > >> > > > it, but it would be irritating to have to
restart httpd every
> > time I
> > > >> > > > want to make a change to a
module/manifest.
>
> > > >> > > > I also tried setting the puppet.conf
option ''ignorecache = true''
> > to no
> > > >> > > > avail. (side note: on the
"servertype" option in puppet.conf,
> > official
> > > >> > > > documentation still states that the only
valid modes are
> > ''webrick'' and
> > > >> > > > ''mongrel''. What is the
appropriate mode for running with
> > passenger?)
>
> > > >> > > My puppetmaster is working fine and that
option isn''t set which
> > means
> > > >> > it''s defaulting to webrick.
>
> > > >> > > > Final note: The puppetmaster always logs
that it has compiled a
> > > >> > > > catalog and expired the cached one, even
on the first runs where
> > the
> > > >> > > > new manifest does not yet take effect.
(and annoyingly,
> > puppetmaster
> > > >> > > > under passenger now logs to
/var/log/messages instead of
> > /var/log/
> > > >> > > > puppet/puppetmaster.log;
>
> > > >> > > I don''t know how to fix this, but
this doesn''t happen under
> > Ubuntu.
>
> > > >> > > > it seems puppetmaster as a rack
application
> > > >> > > > does not look at
/etc/sysconfig/puppetmaster - so I can''t add
> > options
> > > >> > > > like verbosity, etc.)
>
> > > >> > > Correct.  Files in /etc/sysconfig are red when
a service starts.
> >  When
> > > >> > using passenger, the service is apache and
puppetmaster is one of
> > it''s
> > > >> > subprocesses.
>
> > > >> > > The equivalent file is config.ru.
 It''s in the folder you specify
> > in the
> > > >> > apache config file.  Just do a "find / -name
config.ru".
>
> > > >> > > That said, you really shouldn''t need
to change it if puppetmaster
> > is
> > > >> > managing to startup at all.
>
> > > >> > > > To me, it seems like there needs to be
better Puppet Labs
> > > >> > > > documentation on the differences between
running Puppetmaster
> > > >> > > > "normally" (e.g. with
/etc/init.d/puppetmaster) versus as a Rack
> > > >> > > > application.
>
> > > >> > > What distro are you using?
>
> > > >> > > What version of puppet are you using? (puppet
--version)
>
> > > >> > > How did you install puppet?
>
> > > >> > --
> > > >> > You received this message because you are
subscribed to the Google
> > Groups
> > > >> > "Puppet Users" group.
> > > >> > To post to this group, send email to
puppet-users@googlegroups.com.
> > > >> > To unsubscribe from this group, send email to
> > > >> >
puppet-users+unsubscribe@googlegroups.com<puppet-users%2Bunsubscribe@google
groups.com>
> > <puppet-users%2Bunsubscribe@google groups.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-users@googlegroups.com.
> > > > To unsubscribe from this group, send email to
> >
puppet-users+unsubscribe@googlegroups.com<puppet-users%2Bunsubscribe@google
groups.com>
> > .
> > > > For more options, visit this group athttp://
> > groups.google.com/group/puppet-users?hl=en.
>
> > > --
> > > Nigel Kersten - Puppet Labs -  http://www.puppetlabs.com
>
> > --
> > You received this message because you are subscribed to the Google
Groups
> > "Puppet Users" group.
> > To post to this group, send email to puppet-users@googlegroups.com.
> > To unsubscribe from this group, send email to
> >
puppet-users+unsubscribe@googlegroups.com<puppet-users%2Bunsubscribe@google
groups.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-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

Can you ping me on #puppet at freenode? bodepd.

-Dan

On Mon, Nov 15, 2010 at 9:16 AM, Kent <kentmshultz@gmail.com> wrote:
> Already tried filetimeout=0 with no success.
>
:(

the description for the setting ignorecache in puppet.conf man
page:
>
> "
> Ignore  cache  and  always  recompile the configuration. This is
> useful for testing new configurations, where the
> local cache may in fact be stale even if the timestamps are up to date
> - if the facts change  or  if  the  server
> changes.
> "
>
> This sounds like a server setting to me since it mentions compilation.
> In any case, the puppetmaster''s log reports that on every run it
> expires the cached catalog for the host making the run, and that it
> recompiles for the host.
>
>
> On Nov 15, 8:46 am, Dan Bode <d...@puppetlabs.com> wrote:
> > Hi Kent,
> >
> > On Mon, Nov 15, 2010 at 8:05 AM, Kent <kentmshu...@gmail.com>
wrote:
> > > Nigel,
> >
> > > It is number-of-runs based. If I execute two runs in rapid
succession
> > > 2 seconds after changing a manifest on the puppetmaster, the new
> > > config *will* be pushed on the second run. On the other hand I
can
> > > walk away for 10 minutes and when I then execute the runs, the
new
> > > config will still not take effect until the second run.
> >
> > > Is it likely this has something to do with catalog caching on the
> > > master? I tried turning caching off by setting
''ignorecache = true'' in
> > > puppet.conf
> >
> > this is a client side configuration, it probably won''t help.
> >
> > but this didn''t help, so maybe this isn''t the issue
here.
> >
> >
> >
> > try setting filetimeout=0 on the puppet master
> >
> > for more information you can:
> >
> > man puppet.conf
> >
> >
> >
> >
> >
> >
> >
> > > -Kent
> >
> > > On Nov 14, 8:18 am, Nigel Kersten <ni...@puppetlabs.com>
wrote:
> > > > On Wed, Nov 10, 2010 at 1:08 AM, luke.bigum <
> luke.bi...@fasthosts.co.uk>
> > > wrote:
> > > > > I''ve seen the same issue as well. I just
tested then, adding a
> simple
> > > > > notify resource to a node and it took three consecutive
runs of
> > > > > puppetd before the message appeared:
> >
> > > > Is it the number of runs or is it simply time based?
> >
> > > > > # puppetd --test
> > > > > info: Retrieving plugin
> > > > > info: Caching catalog for puppet-master-01
> > > > > info: Applying configuration version
''1289376693''
> > > > > notice: Finished catalog run in 30.24 seconds
> > > > > # puppetd --test
> > > > > info: Retrieving plugin
> > > > > info: Caching catalog for puppet-master-01
> > > > > info: Applying configuration version
''1289377768''
> > > > > notice: Finished catalog run in 24.98 seconds
> > > > > # puppetd --test
> > > > > info: Retrieving plugin
> > > > > info: Caching catalog for puppet-master-01
> > > > > info: Applying configuration version
''1289379786''
> > > > > notice: foo
> > > > > notice:
/Stage[main]//Node[puppet-master-01]/Notify[test]/message:
> > > > > defined ''message'' as
''foo''
> > > > > notice: Finished catalog run in 26.46 seconds
> >
> > > > > # /opt/ruby-enterprise/bin/gem list
> >
> > > > > *** LOCAL GEMS ***
> >
> > > > > facter (1.5.8)
> > > > > fastthread (1.0.7)
> > > > > mysql (2.8.1)
> > > > > passenger (2.2.9)
> > > > > puppet (2.6.2)
> > > > > rack (1.1.0)
> > > > > rake (0.8.7)
> >
> > > > > On Nov 9, 9:08 pm, Jeremy Carroll
<phobos...@gmail.com> wrote:
> > > > >> I am having the same issue, and am running about
the same stack.
> >
> > > > >> CentOS 5.5
> >
> > > > >> facter (1.5.8)
> > > > >> fastthread (1.0.7)
> > > > >> passenger (2.2.15)
> > > > >> puppet (2.6.2)
> > > > >> puppet-module (0.3.0)
> > > > >> rack (1.1.0)
> > > > >> rake (0.8.7)
> > > > >> stomp (1.1.6)
> >
> > > > >> On Tue, Nov 9, 2010 at 2:50 PM, Kent
<kentmshu...@gmail.com>
> wrote:
> > > > >> > Patrick, thanks for the speedy reply once
again.
> >
> > > > >> > I''m using RHEL5 and Puppet 2.6.1,
Passenger 2.2.7, Rack 1.1.0.
> >
> > > > >> > From what I''ve read in this group and
in Puppet Labs docs/wikis,
> > > > >> > Debian/Ubuntu users do seem to have an easier
time generally
> than
> > > > >> > CentOS/Red Hat :-\
> >
> > > > >> > Can I pass my command-line options to
Puppetmasterd in the
> > > config.ru
> > > > >> > file?
> >
> > > > >> > -Kent
> >
> > > > >> > On Nov 9, 10:53 am, Patrick
<kc7...@gmail.com> wrote:
> > > > >> > > On Nov 9, 2010, at 9:34 AM, Kent wrote:
> >
> > > > >> > > > On Nov 8, 11:07 am, Patrick
<kc7...@gmail.com> wrote:
> > > > >> > > >> On Nov 8, 2010, at 9:10 AM, Kent
wrote:
> >
> > > > >> > > >>> Hi all,
> >
> > > > >> > > >>> I''m a new puppet
user and new to the forum.
> >
> > > > >> > > >>> I just switched my
Puppetmaster to running inside Apache
> (via
> > > > >> > > >>> Passenger). When I make a
change to a resource on the
> master,
> > > it
> > > > >> > > >>> sometimes takes a given node
TWO runs before the master
> will
> > > realize
> > > > >> > > >>> the resource has changed and
recompile a new catalog
> version
> > > for the
> > > > >> > > >>> node. For example, say my
puppetmaster is serving
> > > configuration
> > > > >> > > >>> version
''123'' to a node. I change the file permissions for
> a
> > > file
> > > > >> > > >>> resource that''s
part of that catalog and then do a puppet
> run
> > > on the
> > > > >> > > >>> node. If I''m
running with Passenger, the master serves
> config
> > > version
> > > > >> > > >>> ''123'' one
more time (the agent makes no changes). The next
> > > time I run
> > > > >> > > >>> the node''s agent,
the master compiles new catalog version
> > > ''456'' and
> > > > >> > > >>> the agent makes the
permission change.
> >
> > > > >> > > >>> A few items of note:
> >
> > > > >> > > >>> 1.  This is not a problem
with all changes to puppet
> module
> > > content.
> > > > >> > > >>> For example, if I change the
source contents of a file in
> the
> > > ''files''
> > > > >> > > >>> directory of a module, the
master will notice this
> immediately
> > > and
> > > > >> > the
> > > > >> > > >>> puppet agent on the node
will grab the new file on the
> first
> > > run
> > > > >> > > >>> following the change on the
master.
> >
> > > > >> > > >> Fact:
> > > > >> > > >> Files sent using
"source" aren''t part of the catalog.
>  Instead,
> > > the
> > > > >> > client asks the server for them while the
client is using the
> > > catalog and
> > > > >> > not during the compilation done on the server.
> >
> > > > >> > > >> Speculation:
> > > > >> > > >> I would guess this is because
the problem you are having is
> > > happening
> > > > >> > during the compilation on the server.
> >
> > > > >> > > >>> 2.  At first I thought maybe
this was a timing issue (e.g.
> I
> > > was
> > > > >> > doing
> > > > >> > > >>> the puppet run too quickly
after making the resource
> change)
> > > but it''s
> > > > >> > > >>> not; whether I wait 5
seconds or 5 minutes before making
> the
> > > first
> > > > >> > > >>> puppet run, the master still
doesn''t notice the change.  I
> set
> > > the
> > > > >> > > >>>
''filetimeout'' setting in /etc/puppet/puppet.conf to 0 and
> it
> > > didn''t
> > > > >> > > >>> help.
> >
> > > > >> > > >>> Any ideas on what''s
going on here? (thanks in advance for
> your
> > > help)
> >
> > > > >> > > > Ahh, Ok, that makes sense. The
source files are not part of
> the
> > > > >> > > > manifests, just pointed to by them.
> >
> > > > >> > > > However, I am still having a problem
with changed manifests
> not
> > > > >> > > > getting "noticed" by the
Puppetmaster until the second run
> after
> > > it''s
> > > > >> > > > been changed. This is only a problem
when running
> puppetmaster
> > > as a
> > > > >> > > > rack app inside Apache. Of course,
if I restart Apache it
> will
> > > serve
> > > > >> > > > up the most recent manifests on the
first puppet run that
> > > connects to
> > > > >> > > > it, but it would be irritating to
have to restart httpd
> every
> > > time I
> > > > >> > > > want to make a change to a
module/manifest.
> >
> > > > >> > > > I also tried setting the puppet.conf
option ''ignorecache > true''
> > > to no
> > > > >> > > > avail. (side note: on the
"servertype" option in
> puppet.conf,
> > > official
> > > > >> > > > documentation still states that the
only valid modes are
> > > ''webrick'' and
> > > > >> > > > ''mongrel''. What is
the appropriate mode for running with
> > > passenger?)
> >
> > > > >> > > My puppetmaster is working fine and that
option isn''t set
> which
> > > means
> > > > >> > it''s defaulting to webrick.
> >
> > > > >> > > > Final note: The puppetmaster always
logs that it has
> compiled a
> > > > >> > > > catalog and expired the cached one,
even on the first runs
> where
> > > the
> > > > >> > > > new manifest does not yet take
effect. (and annoyingly,
> > > puppetmaster
> > > > >> > > > under passenger now logs to
/var/log/messages instead of
> > > /var/log/
> > > > >> > > > puppet/puppetmaster.log;
> >
> > > > >> > > I don''t know how to fix this,
but this doesn''t happen under
> > > Ubuntu.
> >
> > > > >> > > > it seems puppetmaster as a rack
application
> > > > >> > > > does not look at
/etc/sysconfig/puppetmaster - so I can''t
> add
> > > options
> > > > >> > > > like verbosity, etc.)
> >
> > > > >> > > Correct.  Files in /etc/sysconfig are red
when a service
> starts.
> > >  When
> > > > >> > using passenger, the service is apache and
puppetmaster is one
> of
> > > it''s
> > > > >> > subprocesses.
> >
> > > > >> > > The equivalent file is config.ru. 
It''s in the folder you
> specify
> > > in the
> > > > >> > apache config file.  Just do a "find /
-name config.ru".
> >
> > > > >> > > That said, you really shouldn''t
need to change it if
> puppetmaster
> > > is
> > > > >> > managing to startup at all.
> >
> > > > >> > > > To me, it seems like there needs to
be better Puppet Labs
> > > > >> > > > documentation on the differences
between running
> Puppetmaster
> > > > >> > > > "normally" (e.g. with
/etc/init.d/puppetmaster) versus as a
> Rack
> > > > >> > > > application.
> >
> > > > >> > > What distro are you using?
> >
> > > > >> > > What version of puppet are you using?
(puppet --version)
> >
> > > > >> > > How did you install puppet?
> >
> > > > >> > --
> > > > >> > You received this message because you are
subscribed to the
> Google
> > > Groups
> > > > >> > "Puppet Users" group.
> > > > >> > To post to this group, send email to
> puppet-users@googlegroups.com.
> > > > >> > To unsubscribe from this group, send email to
> > > > >> >
puppet-users+unsubscribe@googlegroups.com<puppet-users%2Bunsubscribe@googlegroups.com>
> <puppet-users%2Bunsubscribe@google groups.com>
> > > <puppet-users%2Bunsubscribe@google groups.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-users@googlegroups.com
> .
> > > > > To unsubscribe from this group, send email to
> > >
puppet-users+unsubscribe@googlegroups.com<puppet-users%2Bunsubscribe@googlegroups.com>
> <puppet-users%2Bunsubscribe@google groups.com>
> > > .
> > > > > For more options, visit this group athttp://
> > > groups.google.com/group/puppet-users?hl=en.
> >
> > > > --
> > > > Nigel Kersten - Puppet Labs -  http://www.puppetlabs.com
> >
> > > --
> > > You received this message because you are subscribed to the
Google
> Groups
> > > "Puppet Users" group.
> > > To post to this group, send email to
puppet-users@googlegroups.com.
> > > To unsubscribe from this group, send email to
> > >
puppet-users+unsubscribe@googlegroups.com<puppet-users%2Bunsubscribe@googlegroups.com>
> <puppet-users%2Bunsubscribe@google groups.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-users@googlegroups.com.
> To unsubscribe from this group, send email to
>
puppet-users+unsubscribe@googlegroups.com<puppet-users%2Bunsubscribe@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-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

Hi Kent,

Thanks for bringing this issue to our attention. I have recreated and filed
the following ticket:

http://projects.puppetlabs.com/issues/5318

Feel free to watch the ticket to track the progress of the issue.

-Dan

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