Puppet users - Jan 2007 - Delayed detection of updates

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi *!

Has anybody a fix/workaround for this beahaviour? My Service[munin-node] is 
subscribed to the timestamp of a directory containing config-snippets like 
this:

{{{
file{"/etc/munin/plugins": checksum => mtime, }
service{munin-node: subscribe => File["/etc/munin/plugins"], # ...
}}}

When adding new snippets to the directory (usually via symlinks), the restart 
is delayed until the next run detects the changed checksum:

david@services:~$ sudo puppetd --test
notice: Starting configuration run
notice:
//services/dbp_etch/ntp_client/munin_plugin[ntp_chip_mariatreu_at]/file=/etc/munin/plugins/ntp_chip_mariatreu_at/ensure:
created
notice: Finished configuration run in 33.43 seconds
david@services:~$ sudo puppetd --test
notice: Starting configuration run
notice:
//services/dbp_etch/default_munin_node/munin_node[default_munin_node]/file=/etc/munin/plugins/checksum:
checksum changed ''{time}Wed Dec 13 23:44:07 +0100 2006'' to
''{time}Sun Jan 14
12:44:01 +0100 2007''
info:
//services/dbp_etch/default_munin_node/munin_node[default_munin_node]/file=/etc/munin/plugins:
Scheduling refresh of service[munin-node]
notice:
//services/dbp_etch/default_munin_node/munin_node[default_munin_node]/service=munin-node:
Triggering ''refresh'' from 1 dependencies
notice: Finished configuration run in 32.81 seconds
david@services:~$ 


Regards, David

- -- 
- - hallo... wie gehts heute?
- - *hust* gut *rotz* *keuch*
- - gott sei dank kommunizieren wir über ein septisches medium ;)
 -- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFFqgoN/Pp1N6Uzh0URAjlOAJ9Ol/70jPaXJIDwhDVvECWExf+KrwCgg7jm
zWHxwl+w8DVl/WIBDKbz49Y=Kf5Z
-----END PGP SIGNATURE-----

On Jan 14, 2007, at 9:46 PM, David Schmitt wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi *!
>
> Has anybody a fix/workaround for this beahaviour? My Service[munin- 
> node] is
> subscribed to the timestamp of a directory containing config- 
> snippets like
> this:
>
> {{{
> file{"/etc/munin/plugins": checksum => mtime, }
> service{munin-node: subscribe => File["/etc/munin/plugins"], #
...
> }}}
>
> When adding new snippets to the directory (usually via symlinks),  
> the restart
> is delayed until the next run detects the changed checksum:
How are you adding the symlinks?  If you''re using Puppet to do it,  
it''d be better if you used ''notify'' in the symlinks,
since that would
guarantee the service would get notified in that run.

The reason this is happening is because parent directories always get  
checked before subdirs/contained files, so Puppet first checks the  
timestamp of the directory, then creates links or whatever, which  
means that the directory doesn''t realize it changed in this run.

There''s no workaround for this problem that I know of, other than  
creating direct relationships between the contained files and the  
service.  This is probably a bug, but the only fix I can think of  
requires specifying that the parent directory should be applied after  
the contained file.

Hmm.  I just realized that we could set it up so that explicit  
relationships overrode automatic relationships, which in this case  
means that you could explicitly specify that the symlinks are  
required by the directory, which would make the directory catch the  
changes.  That''s a good idea.  I''ll open that as an
enhancement request.

  --
  Today I dialed a wrong number...The other person said, "Hello?" and
  I said, "Hello, could I speak to Joey?"...
  They said, "Uh...I don''t think so...he''s only 2 months
old."
  I said, "I''ll wait."  -- Steven Wright
  ---------------------------------------------------------------------
  Luke Kanies | http://reductivelabs.com | http://madstop.com

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Monday 15 January 2007 06:34, Luke Kanies wrote:
> > {{{
> > file{"/etc/munin/plugins": checksum => mtime, }
> > service{munin-node: subscribe =>
File["/etc/munin/plugins"], # ...
> > }}}
> >
> > When adding new snippets to the directory (usually via symlinks),
> > the restart
> > is delayed until the next run detects the changed checksum:
>
> How are you adding the symlinks?  If you''re using Puppet to do it,
> it''d be better if you used ''notify'' in the
symlinks, since that would
> guarantee the service would get notified in that run.
Yes, I do. After adding ''notify => Service[munin-node]'' to
the appropriate
places on the symlinks, the service restarts immediately. 

Actually the subscription to the directory is wrong anyways. I''d rather
like
to write ''subscribe =>
File["/etc/munin/plugins/*"]''
> The reason this is happening is because parent directories always get
> checked before subdirs/contained files, so Puppet first checks the
> timestamp of the directory, then creates links or whatever, which
> means that the directory doesn''t realize it changed in this run.
>
> There''s no workaround for this problem that I know of, other than
> creating direct relationships between the contained files and the
> service.  This is probably a bug, but the only fix I can think of
> requires specifying that the parent directory should be applied after
> the contained file.
I guess reevaluating parts of the transaction in mid-run is not feasible, but 
what about re-running the downloaded config until no changes are commited?
> Hmm.  I just realized that we could set it up so that explicit
> relationships overrode automatic relationships, which in this case
> means that you could explicitly specify that the symlinks are
> required by the directory, which would make the directory catch the
> changes.  That''s a good idea.  I''ll open that as an
enhancement request.
This would still need enumerating all symlinks in the directory. I tried to 
add a ''notify => File["/etc/munin/plugins"]'' but
that causes a stack
overflow. 


Regards, David
- -- 
- - hallo... wie gehts heute?
- - *hust* gut *rotz* *keuch*
- - gott sei dank kommunizieren wir über ein septisches medium ;)
 -- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFFq1mn/Pp1N6Uzh0URAgDlAJ9HRyBdgkTZouZtxKD8hbWMGtYWGwCgn+SV
umXvnHE2gLj1hE+zRiMiLbQ=JPdC
-----END PGP SIGNATURE-----

On Jan 15, 2007, at 9:38 PM, David Schmitt wrote:
> Yes, I do. After adding ''notify =>
Service[munin-node]'' to the
> appropriate
> places on the symlinks, the service restarts immediately.
>
> Actually the subscription to the directory is wrong anyways. I''d  
> rather like
> to write ''subscribe =>
File["/etc/munin/plugins/*"]''
Mmm, globbing.  I could actually support file globbing in some places  
now (although I don''t, other than in sources) but I hadn''t
thought
about it for dependencies.  Hmm.
> I guess reevaluating parts of the transaction in mid-run is not  
> feasible, but
> what about re-running the downloaded config until no changes are  
> commited?
I think that this would be very bad.  Some configurations (e.g.,  
anything involving yum) can take a really long time to run, and  
really, if Puppet can''t order things correctly for one run, then  
that''s a bug.  Cfengine runs twice every time, and it got very nasty  
sometimes.

The right answer here is to make sure you can specify relationships  
correctly, not to hack around the lack of that ability.
> This would still need enumerating all symlinks in the directory. I  
> tried to
> add a ''notify => File["/etc/munin/plugins"]''
but that causes a stack
> overflow.
Hmm.  Puppet should have thrown a failure there, because it creates a  
circular graph.  It definitely shouldn''t have an overflow.  Can you  
post the code that causes this problem?

  --
  Susskind''s Rule of Thumb:
      Don''t ask what they think. Ask what they do.
  ---------------------------------------------------------------------
  Luke Kanies | http://reductivelabs.com | http://madstop.com

[Moving to -dev]

On Tuesday 16 January 2007 00:00, Luke Kanies wrote:
> On Jan 15, 2007, at 9:38 PM, David Schmitt wrote:
> > This would still need enumerating all symlinks in the directory. I
> > tried to
> > add a ''notify =>
File["/etc/munin/plugins"]'' but that causes a stack
> > overflow.
>
> Hmm.  Puppet should have thrown a failure there, because it creates a
> circular graph.  It definitely shouldn''t have an overflow.  Can
you
> post the code that causes this problem?
Attached file produces this:

david@zion:~/tmp/pp$ l
total 4
-rw-r--r-- 1 david david 253 2007-01-16 10:35 test.pp
david@zion:~/tmp/pp$ puppet --debug test.pp
[...]
debug: Loaded state in 0.00 seconds
debug: /Service[ntp]/subscribe: subscribes to File[/home/david/tmp/pp/dir]
debug: /File[/home/david/tmp/pp/dir/file]/notify: subscribes to 
File[/home/david/tmp/pp/dir]
debug: //File[/home/david/tmp/pp/dir/file]: Autorequiring 
File[/home/david/tmp/pp/dir]
err: Found a bug: stack level too deep
debug: Storing state
debug: Stored state in 0.00 seconds
david@zion:~/tmp/pp$ puppet --version
0.22.0
david@zion:~/tmp/pp$ 


Shall I create a bug report?

Regards, David
-- 
- hallo... wie gehts heute?
- *hust* gut *rotz* *keuch*
- gott sei dank kommunizieren wir über ein septisches medium ;)
 -- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15



_______________________________________________
Puppet-users mailing list
Puppet-users@madstop.com
https://mail.madstop.com/mailman/listinfo/puppet-users

On Jan 16, 2007, at 8:39 PM, David Schmitt wrote:
>
> Attached file produces this:
>
> david@zion:~/tmp/pp$ l
> total 4
> -rw-r--r-- 1 david david 253 2007-01-16 10:35 test.pp
> david@zion:~/tmp/pp$ puppet --debug test.pp
> [...]
> debug: Loaded state in 0.00 seconds
> debug: /Service[ntp]/subscribe: subscribes to File[/home/david/tmp/ 
> pp/dir]
> debug: /File[/home/david/tmp/pp/dir/file]/notify: subscribes to
> File[/home/david/tmp/pp/dir]
> debug: //File[/home/david/tmp/pp/dir/file]: Autorequiring
> File[/home/david/tmp/pp/dir]
> err: Found a bug: stack level too deep
> debug: Storing state
> debug: Stored state in 0.00 seconds
> david@zion:~/tmp/pp$ puppet --version
> 0.22.0
> david@zion:~/tmp/pp$
>
>
> Shall I create a bug report?
I wasn''t able to test this on a machine with an ntp daemon, but
I''ve
filed a bug about the allowed circular graph (#437).

If you skip the ntp code in your example, do you still get the ''stack  
too deep'' failure?  When I just have the file operations, the  
circular dependency results in no work being done (a quirk of doing a  
topological sort on a circular graph).

  --
  Millions long for immortality who do not know what to do with
  themselves on a rainy Sunday afternoon.         -- Susan Ertz
  ---------------------------------------------------------------------
  Luke Kanies | http://reductivelabs.com | http://madstop.com

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tuesday 16 January 2007 23:54, Luke Kanies wrote:
> On Jan 16, 2007, at 8:39 PM, David Schmitt wrote:
> > Attached file produces this:
> >
> > david@zion:~/tmp/pp$ l
> > total 4
> > -rw-r--r-- 1 david david 253 2007-01-16 10:35 test.pp
> > david@zion:~/tmp/pp$ puppet --debug test.pp
> > [...]
> > debug: Loaded state in 0.00 seconds
> > debug: /Service[ntp]/subscribe: subscribes to File[/home/david/tmp/
> > pp/dir]
> > debug: /File[/home/david/tmp/pp/dir/file]/notify: subscribes to
> > File[/home/david/tmp/pp/dir]
> > debug: //File[/home/david/tmp/pp/dir/file]: Autorequiring
> > File[/home/david/tmp/pp/dir]
> > err: Found a bug: stack level too deep
> > debug: Storing state
> > debug: Stored state in 0.00 seconds
> > david@zion:~/tmp/pp$ puppet --version
> > 0.22.0
> > david@zion:~/tmp/pp$
> >
> >
> > Shall I create a bug report?
>
> I wasn''t able to test this on a machine with an ntp daemon, but
I''ve
> filed a bug about the allowed circular graph (#437).
>
> If you skip the ntp code in your example, do you still get the
''stack
> too deep'' failure?  When I just have the file operations, the
> circular dependency results in no work being done (a quirk of doing a
> topological sort on a circular graph).
No, the Service[ntp] was just for illustration, because the service type 
reacts to the notify quite obviously. I suspect the same results with any 
other service.


Regards, David
- -- 
- - hallo... wie gehts heute?
- - *hust* gut *rotz* *keuch*
- - gott sei dank kommunizieren wir über ein septisches medium ;)
 -- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFFr5VE/Pp1N6Uzh0URAgf7AJ9yLnyCcf9njGGYXQ+zFaaPGSXTpACggwPW
SucwoYqrPmvYt7mU+a7MWtw=UDMm
-----END PGP SIGNATURE-----

On Jan 19, 2007, at 2:41 AM, David Schmitt wrote:
> No, the Service[ntp] was just for illustration, because the service  
> type
> reacts to the notify quite obviously. I suspect the same results  
> with any
> other service.
I''ve not been able to reproduce the stack-too-deep error using an  
exec (which also responds to notify), so hopefully just fixing the  
circular dependency problem will fix that.

It''d be great if you could test this when I get it fixed.

  --
  Take the utmost trouble to find the right thing to say, and then  
say it
  with the utmost levity.     -- George Bernard Shaw
  ---------------------------------------------------------------------
  Luke Kanies | http://reductivelabs.com | http://madstop.com