I tried looking in the language tutorial for this, but I couldn''t find a reference for how to do it, but I''m sure it must be possible. So I''ve got two modules, one for "random_app" and one for "dns_config". "dns_config" has a file resource "resolv.conf" which is just what the name implies. I want service ''foo'' in my random_app module to subscribe to dns_config''s resolv.conf, and if the resolv.conf changes, to restart. (Because, it''s a misbehaving app who doesn''t just use gethostbyname() calls, but runs its own resolver and never looks at resolv.conf again after it starts up.) I would have thought it''d just be subscribing the service to File[''dns_config::resolv.conf''] but clearly that didn''t work. ... Could not find dependency File[dns_config::resolv.conf] .... Any ideas on what I need to do to make that work? Cheers, D -- 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, Feb 15, 2011 at 11:05, Derek J. Balling <dredd@megacity.org> wrote: […]> So I''ve got two modules, one for "random_app" and one for "dns_config". "dns_config" has a file resource "resolv.conf" which is just what the name implies. > > I want service ''foo'' in my random_app module to subscribe to dns_config''s resolv.conf, and if the resolv.conf changes, to restart. (Because, it''s a misbehaving app who doesn''t just use gethostbyname() calls, but runs its own resolver and never looks at resolv.conf again after it starts up.) > > I would have thought it''d just be subscribing the service to File[''dns_config::resolv.conf''] but clearly that didn''t work.service { "foo": require => File["/etc/resolv.conf"] } That will happily cross modules, completely ignoring that boundary. (Match the name of the file you give in the other module, obviously. :) Regards, Daniel -- ⎋ Puppet Labs Developer – http://puppetlabs.com ✉ Daniel Pittman <daniel@puppetlabs.com> ✆ Contact me via gtalk, email, or phone: +1 (877) 575-9775 ♲ Made with 100 percent post-consumer electrons -- 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, Feb 15, 2011 at 2:09 PM, Daniel Pittman <daniel@puppetlabs.com> wrote:> On Tue, Feb 15, 2011 at 11:05, Derek J. Balling <dredd@megacity.org> wrote: > > […] >> So I''ve got two modules, one for "random_app" and one for "dns_config". "dns_config" has a file resource "resolv.conf" which is just what the name implies. >> >> I want service ''foo'' in my random_app module to subscribe to dns_config''s resolv.conf, and if the resolv.conf changes, to restart. (Because, it''s a misbehaving app who doesn''t just use gethostbyname() calls, but runs its own resolver and never looks at resolv.conf again after it starts up.) >> >> I would have thought it''d just be subscribing the service to File[''dns_config::resolv.conf''] but clearly that didn''t work. > > service { "foo": require => File["/etc/resolv.conf"] } > > That will happily cross modules, completely ignoring that boundary. > (Match the name of the file you give in the other module, obviously. > :)You can also create class level dependency so it is less tightly coupled to a specific resource which may benefit you in the long run should you need to refactor dns_config class. class random_app { require dns_config ... } Thanks, Nan -- 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 11-02-15 05:25 PM, Nan Liu wrote:> You can also create class level dependency so it is less tightly > coupled to a specific resource which may benefit you in the long run > should you need to refactor dns_config class. > > class random_app { > require dns_config > ... > }hmm this actually binds the OP''s ''random_app'' module to the ''dns_config'' one while Daniel''s suggestion can find the File resource even though it is moved from one module to another. -- Gabriel Filion -- 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, Feb 15, 2011 at 17:11, Gabriel Filion <lelutin@gmail.com> wrote:> On 11-02-15 05:25 PM, Nan Liu wrote: >> You can also create class level dependency so it is less tightly >> coupled to a specific resource which may benefit you in the long run >> should you need to refactor dns_config class. >> >> class random_app { >> require dns_config >> ... >> } > > hmm this actually binds the OP''s ''random_app'' module to the ''dns_config'' > one while Daniel''s suggestion can find the File resource even though it > is moved from one module to another.For what it is worth, for an extremely well known interface like /etc/resolv.conf I would subscribe to the file resource, but for most cases I prefer to depend on the class. So, I think both answers are right, and I didn''t explain why I chose the apparently tighter binding this time around. Daniel -- ⎋ Puppet Labs Developer – http://puppetlabs.com ✉ Daniel Pittman <daniel@puppetlabs.com> ✆ Contact me via gtalk, email, or phone: +1 (877) 575-9775 ♲ Made with 100 percent post-consumer electrons -- 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.
> For what it is worth, for an extremely well known interface like > /etc/resolv.conf I would subscribe to the file resource, but for most > cases I prefer to depend on the class. So, I think both answers are > right, and I didn''t explain why I chose the apparently tighter binding > this time around.FWIW, we''ve chosen to do both, if for no other reason than so that the app in question won''t be "processed" until after the resolv.conf is updated, so we can minimize the number of restarts, etc., as necessary. The next issue which follows, for me, is that "random_app" is "puppet-agent", because it refuses to notice changes to resolv.conf, and has to be restarted to pick them up. Likely this is because it''s using its own resolver library instead of the system calls, but this is a real PITA, since the only "clean" way to restart the puppet agent, from within puppet, essentially amounts to issuing `/etc/init.d/puppet restart`in the middle of a catalog-run, which sucks for all the obvious reasons you would think it does. D -- 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 02/16/2011 11:30 AM, Derek J. Balling wrote:>> For what it is worth, for an extremely well known interface like >> /etc/resolv.conf I would subscribe to the file resource, but for most >> cases I prefer to depend on the class. So, I think both answers are >> right, and I didn''t explain why I chose the apparently tighter binding >> this time around. > > FWIW, we''ve chosen to do both, if for no other reason than so that the app in question won''t be "processed" until after the resolv.conf is updated, so we can minimize the number of restarts, etc., as necessary. > > The next issue which follows, for me, is that "random_app" is "puppet-agent", because it refuses to notice changes to resolv.conf, and has to be restarted to pick them up. Likely this is because it''s using its own resolver library instead of the system calls, but this is a real PITA, since the only "clean" way to restart the puppet agent, from within puppet, essentially amounts to issuing `/etc/init.d/puppet restart`in the middle of a catalog-run, which sucks for all the obvious reasons you would think it does.Yes. Ugly workaround: Schedule the restart using atd from within the catalog run. (I''ve used "at now+2min" and it works so far). Cheers, Felix -- 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.
Derek J. Balling
2011-Feb-18 16:16 UTC
Re: [Puppet Users] Puppet Restarting Puppet, Puppet-Agent''s resolver (was Inter-Module Dependency)
On Feb 18, 2011, at 9:29 AM, Felix Frank wrote:> Ugly workaround: Schedule the restart using atd from within the catalog > run. (I''ve used "at now+2min" and it works so far).Well, that''s "less ugly" I suppose than the client just vanishing in the middle of a catalog-run. :-) But also my complaint is: Why *isn''t* puppet-agent noticing that resolv.conf has changed? This seems like something that would only be caused by not using the standard gethostbyname() calls and such, since *those* should reflect the change in resolv.conf almost immediately.... :-/ D -- 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.
Thomas Bellman
2011-Feb-18 17:09 UTC
Re: [Puppet Users] Puppet Restarting Puppet, Puppet-Agent''s resolver (was Inter-Module Dependency)
On 2011-02-18 17:16, Derek J. Balling wrote:> But also my complaint is: Why *isn''t* puppet-agent noticing > that resolv.conf has changed? This seems like something that > would only be caused by not using the standard gethostbyname() > calls and such, > since *those* should reflect the change in > resolv.conf almost immediately.... :-/Except that they don''t... At least the GNU libc implementation does not re-read resolv.conf unless you call res_init(). I''m attaching a test program that you can use to verify it yourself. It will call gethostbyname() twice, optionally re-initialize the resolver before the second call. You are supposed to change your resolv.conf between the two calls. I *think* other Unix libc implementations does the same, but I don''t have any machine available where I can test this at the moment. /Bellman -- 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.
Daniel Pittman
2011-Feb-18 20:01 UTC
Re: [Puppet Users] Puppet Restarting Puppet, Puppet-Agent''s resolver (was Inter-Module Dependency)
On Fri, Feb 18, 2011 at 09:09, Thomas Bellman <bellman@nsc.liu.se> wrote:> On 2011-02-18 17:16, Derek J. Balling wrote: > >> But also my complaint is: Why *isn''t* puppet-agent noticing >> that resolv.conf has changed? This seems like something that >> would only be caused by not using the standard gethostbyname() >> calls and such, > since *those* should reflect the change in >> resolv.conf almost immediately.... :-/ > > Except that they don''t... At least the GNU libc implementation does > not re-read resolv.conf unless you call res_init(). I''m attaching > a test program that you can use to verify it yourself. It will call > gethostbyname() twice, optionally re-initialize the resolver before > the second call. You are supposed to change your resolv.conf between > the two calls.Just to be specific: puppet doesn''t do anything except use those standard functions, so we are not actually capable of doing anything portable to solve these problems. It really isn''t so much "puppet ignores the change to..." as "the OS libraries ignore..." Daniel -- ⎋ Puppet Labs Developer – http://puppetlabs.com ✉ Daniel Pittman <daniel@puppetlabs.com> ✆ Contact me via gtalk, email, or phone: +1 (877) 575-9775 ♲ Made with 100 percent post-consumer electrons -- 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.
Derek J. Balling
2011-Feb-18 21:00 UTC
Re: [Puppet Users] Puppet Restarting Puppet, Puppet-Agent''s resolver (was Inter-Module Dependency)
On Feb 18, 2011, at 3:01 PM, Daniel Pittman wrote:> Just to be specific: puppet doesn''t do anything except use those > standard functions, so we are not actually capable of doing anything > portable to solve these problems. It really isn''t so much "puppet > ignores the change to..." as "the OS libraries ignore..."I wonder how other applications deal with it, because some of the other apps on our system noticed the change to resolv.conf in short order. Maybe they''re internally stat()ing /etc/resolv.conf every so often and if the time is different, they''re re-init''ing their resolver object? Seems like that''s something that could happen as part of a catalog run, though, with little to no overhead.... Dunno. D -- 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.