I know it has been discussed several time and "notify" is the
"magic
word" to use here but it''s not working here; my case is a bit
different. This is what I have:
***************************************************************
define line_check($fname, $line, $bool = ''false'') {
exec { "/bin/echo ''${line}'' >>
''${fname}''":
unless => "/bin/grep -q ''^$line''
''$fname''",
refreshonly => "$bool";
}
}
class zmfs::config {
zmfs::defined::line_check {''auto.master'':
fname => ''/etc/auto.master'',
line => ''/zmfs /etc/auto.zmfs'',
notify => Class[''zmfs::service''];
}
}
class zmfs::service {
service { ''autofs'':
enable => true,
ensure => running,
hasstatus => true,
hasrestart => true,
status => ''service zmfs probe'',
require =>
Package[''zmfs'',''zmfs-init-scripts''];
}
}
***************************************************************
So, I''m expecting, whenever "/etc/auto.master" is modified,
autofs
service will be restarted but that''s not case I see here. What am I
missing?
Another question: Can I just do "service {
''autofs'':" or "service
{ ''nfs'':" (or any given standard unix/linux service) just
like that?
I''m wondering if that part is being completely ignored.
Cheers,
San
--
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.
Bekir Dogan
2011-Dec-14 13:47 UTC
Re: [Puppet Users] restarting "service" when configuration changes
You should see the refreshonly parameter in exec resource type from http://docs.puppetlabs.com/references/stable/type.html#exec There is also an example with subscribe (instead of notify) which i think you can solve your problem using that example. bekir On Wed, Dec 14, 2011 at 15:35, Sans <r.santanu.das@gmail.com> wrote:> I know it has been discussed several time and "notify" is the "magic > word" to use here but it''s not working here; my case is a bit > different. This is what I have: > > *************************************************************** > define line_check($fname, $line, $bool = ''false'') { > > exec { "/bin/echo ''${line}'' >> ''${fname}''": > unless => "/bin/grep -q ''^$line'' ''$fname''", > refreshonly => "$bool"; > } > } > > class zmfs::config { > > zmfs::defined::line_check {''auto.master'': > fname => ''/etc/auto.master'', > line => ''/zmfs /etc/auto.zmfs'', > notify => Class[''zmfs::service'']; > } > } > > class zmfs::service { > service { ''autofs'': > enable => true, > ensure => running, > hasstatus => true, > hasrestart => true, > status => ''service zmfs probe'', > require => Package[''zmfs'',''zmfs-init-scripts'']; > } > } > *************************************************************** > > So, I''m expecting, whenever "/etc/auto.master" is modified, autofs > service will be restarted but that''s not case I see here. What am I > missing? > > Another question: Can I just do "service { ''autofs'':" or "service > { ''nfs'':" (or any given standard unix/linux service) just like that? > I''m wondering if that part is being completely ignored. > > Cheers, > San > > -- > 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.
Jo Rhett
2011-Dec-14 22:37 UTC
Re: [Puppet Users] restarting "service" when configuration changes
Try notify => Service[''autofs''] On Dec 14, 2011, at 5:35 AM, Sans wrote:> I know it has been discussed several time and "notify" is the "magic > word" to use here but it''s not working here; my case is a bit > different. This is what I have: > > *************************************************************** > define line_check($fname, $line, $bool = ''false'') { > > exec { "/bin/echo ''${line}'' >> ''${fname}''": > unless => "/bin/grep -q ''^$line'' ''$fname''", > refreshonly => "$bool"; > } > } > > class zmfs::config { > > zmfs::defined::line_check {''auto.master'': > fname => ''/etc/auto.master'', > line => ''/zmfs /etc/auto.zmfs'', > notify => Class[''zmfs::service'']; > } > } > > class zmfs::service { > service { ''autofs'': > enable => true, > ensure => running, > hasstatus => true, > hasrestart => true, > status => ''service zmfs probe'', > require => Package[''zmfs'',''zmfs-init-scripts'']; > } > } > *************************************************************** > > So, I''m expecting, whenever "/etc/auto.master" is modified, autofs > service will be restarted but that''s not case I see here. What am I > missing? > > Another question: Can I just do "service { ''autofs'':" or "service > { ''nfs'':" (or any given standard unix/linux service) just like that? > I''m wondering if that part is being completely ignored. > > Cheers, > San > > -- > 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. >-- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness -- 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.
jcbollinger
2011-Dec-15 14:08 UTC
[Puppet Users] Re: restarting "service" when configuration changes
On Dec 14, 4:37 pm, Jo Rhett <jrh...@netconsonance.com> wrote:> Try > notify => Service[''autofs'']Right. As far as I know, classes do not forward signals to resources they contain. Furthermore, you should consider whether it would be appropriate to combine your two classes. That a resource belonging to one wants to signal a resource belonging to the other is a hint in that direction (but no more than that). I''m not seeing what you gain by defining such fine-grained classes, especially with the implicit dependencies among them (see next). Also, if you do not combine classes, then be sure each class ''include''s the other classes whose resources it references. For instance, class zmfs::service should contain "include ''zmfs::config''" at the beginning of its body. Class zmfs::service should ''include'' whatever class(es) declares the the ''zmfs'' and ''zmfs-init-scripts'' packages. On the practical side, this protects you from catalog compilation failures arising from varying parse order. On the conceptual side, it''s the Right Thing for classes to formally declare their dependencies. John -- 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.
jcbollinger
2011-Dec-15 14:12 UTC
[Puppet Users] Re: restarting "service" when configuration changes
On Dec 14, 7:35 am, Sans <r.santanu....@gmail.com> wrote:> Another question: Can I just do "service { ''autofs'':" or "service > { ''nfs'':" (or any given standard unix/linux service) just like that?As opposed to what? The service name to use is whatever the system''s tools use to refer to the service. For example, if your system provides the ''chkconfig'' and ''service'' commands for managing services, then your Puppet manifests should name Service resources with the names that you would use with those tools.> I''m wondering if that part is being completely ignored.Unlikely. John -- 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.
Felix Frank
2011-Dec-15 14:33 UTC
Re: [Puppet Users] Re: restarting "service" when configuration changes
On 12/15/2011 03:08 PM, jcbollinger wrote:> Right. As far as I know, classes do not forward signals to resources > they contain.Which really is a major pitfall. Any insight on why it''s not done? 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.
Sans
2011-Dec-15 16:16 UTC
[Puppet Users] Re: restarting "service" when configuration changes
On Dec 15, 2:08 pm, jcbollinger <John.Bollin...@stJude.org> wrote:> On Dec 14, 4:37 pm, Jo Rhett <jrh...@netconsonance.com> wrote: > > > Try > > notify => Service[''autofs''] > > Right. As far as I know, classes do not forward signals to resources > they contain. >Are you absolutely sure about that? My understanding was to use something like Class[''zmfs::service''] only to avoid running individual services separately in that class.> Furthermore, you should consider whether it would be appropriate to > combine your two classes. That a resource belonging to one wants to > signal a resource belonging to the other is a hint in that direction > (but no more than that). I''m not seeing what you gain by defining > such fine-grained classes, especially with the implicit dependencies > among them (see next). >Those three code snippets are in three different files, namely definition.pp, config.pp and service.pp respectively. And there is a "config.pp" where The "line_check" definition gets reused for various files in the module. [re]Starting zmfs is not just enough, it''s needs some other services to be restarted, "autofs" being one of the most important ones. So, what I want is to restart "autofs" as soon as the "/zmfs / etc/auto.zmfs" is added to the auto.master file, say for example for the very first time. "zmfs" itself still just works without restarting (even starting) the "autofs" but it won''t be completely usable. So, in fact, this is the actual service.pp file: ******************************************* class zmfs::service { service { ''zmfs'': enable => true, ensure => running, hasstatus => true, hasrestart => true, #status => ''/etc/zmfs/service_zmfs'', require => Package[''zmfs'',''zmfs-init-scripts'']; ''autofs'': enable => true, ensure => running, hasstatus => true, hasrestart => true, status => ''service zmfs probe'', require => Package[''zmfs'',''zmfs-init-scripts'']; } } ******************************************* I wrote (at least trying to) this module to use by the several other sys-admins, where either "autofs" is already running and in some cases the "auto.master" itself is being maintained by another puppet module. So, I had to make sure my module must restart autofs after adding the appropriate line to the file. but that''s not happening. On the other hand, if I take the ''service autofs'' out of the equation and use an external script (service_zmfs) with "status" **************************************** #!/usr/bin/perl # file: service_zmfs use strict; use warnings; my @checks = ( "serviceautofs restart", "service zmfs probe", ); for my $check ( @checks ) { $check .= " 2>&1 > /dev/null"; # suppress output system( $check ) == 0 or exit 1; } ************************************* it works. Still don''t fully get it. Cheers!!> Also, if you do not combine classes, then be sure each class > ''include''s the other classes whose resources it references. For > instance, class zmfs::service should contain "include ''zmfs::config''" > at the beginning of its body. Class zmfs::service should ''include'' > whatever class(es) declares the the ''zmfs'' and ''zmfs-init-scripts'' > packages. On the practical side, this protects you from catalog > compilation failures arising from varying parse order. On the > conceptual side, it''s the Right Thing for classes to formally declare > their dependencies. > > John-- 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.
jcbollinger
2011-Dec-15 22:16 UTC
[Puppet Users] Re: restarting "service" when configuration changes
On Dec 15, 8:33 am, Felix Frank <felix.fr...@alumni.tu-berlin.de> wrote:> On 12/15/2011 03:08 PM, jcbollinger wrote: > > > Right. As far as I know, classes do not forward signals to resources > > they contain. > > Which really is a major pitfall. Any insight on why it''s not done?I suspect some historical inertia, but it''s also not clear to me that the historical behavior is less desirable. It might be reasonable if the effect of refreshing a class were to refresh all of its resources, but I don''t see that as the singular right thing to do. Furthermore, I suspect that making class refreshes work that way is a far more complicated proposal than it might at first appear. John -- 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.
jcbollinger
2011-Dec-15 22:56 UTC
[Puppet Users] Re: restarting "service" when configuration changes
On Dec 15, 10:16 am, Sans <r.santanu....@gmail.com> wrote:> On Dec 15, 2:08 pm, jcbollinger <John.Bollin...@stJude.org> wrote: > > > On Dec 14, 4:37 pm, Jo Rhett <jrh...@netconsonance.com> wrote: > > > > Try > > > notify => Service[''autofs''] > > > Right. As far as I know, classes do not forward signals to resources > > they contain. > > Are you absolutely sure about that?"As far as I know" was meant to convey that no, I am not absolutely sure.> My understanding was to use > something like Class[''zmfs::service''] only to avoid running individual > services separately in that class.That''s understandable, but evidently it doesn''t work with resource signaling. Moreover, it''s not obvious to me that that''s what you really want anyway. For instance, do you care in what order the resources in class zmfs::service get refreshed? If so, then signaling via the class would not be correct anyway.> > Furthermore, you should consider whether it would be appropriate to > > combine your two classes. That a resource belonging to one wants to > > signal a resource belonging to the other is a hint in that direction > > (but no more than that). I''m not seeing what you gain by defining > > such fine-grained classes, especially with the implicit dependencies > > among them (see next). > > Those three code snippets are in three different files, namely > definition.pp, config.pp and service.pp respectively.That''s entirely beside the point, which is that resources that are closely related to each other typically belong in the same class. Consider: would any node ever want to include class zmfs::config but not class zmfs::service? Would it be correct for a node to include zmfs::service but not zmfs::config? If the anwer is no to both questions, then why are these separate classes? Note that as your manifests now stand, any node that includes zmfs::config *must* also include zmfs::service, else its catalog will not compile.> And there is a > "config.pp" where > > The "line_check" definition gets reused for various files in the > module.Very good, no problem with that.> [re]Starting zmfs is not just enough, it''s needs some other > services to be restarted, "autofs" being one of the most important > ones. So, what I want is to restart "autofs" as soon as the "/zmfs / > etc/auto.zmfs" is added to the auto.master file, say for example for > the very first time. "zmfs" itself still just works without restarting > (even starting) the "autofs" but it won''t be completely usable.So what you''re saying is that "notify => Service[''autofs'']" is *exactly* what you want. You don''t need to signal the other resources in class zmfs::service; you only need to signal Service[''autofs''].> So, in > fact, this is the actual service.pp file: > > ******************************************* > class zmfs::service { > service { > ''zmfs'': > enable => true, > ensure => running, > hasstatus => true, > hasrestart => true, > #status => ''/etc/zmfs/service_zmfs'', > require => Package[''zmfs'',''zmfs-init-scripts'']; > > ''autofs'': > enable => true, > ensure => running, > hasstatus => true, > hasrestart => true, > status => ''service zmfs probe'', > require => Package[''zmfs'',''zmfs-init-scripts'']; > }} > > ******************************************* > > I wrote (at least trying to) this module to use by the several other > sys-admins, where either "autofs" is already running and in some cases > the "auto.master" itself is being maintained by another puppet module.So in that case, putting Service[''autofs''] in class zmfs::service is probably harmful, unless you can be certain that every node that wants to use autofs also wants to use zmfs, now and forever. Indeed, it is quite strange that you contemplate managing the autofs service and one of its configuration files in completely separate modules.> So, I had to make sure my module must restart autofs after adding the > appropriate line to the file. but that''s not happening.We understand what you are trying to accomplish, and it''s quite reasonable. Jo suggested a way for you to reach your objective -- notifying the Service instead of the class declaring it -- and the more you explain, the more that suggestion seems exactly the right thing to do.> On the other hand, if I take the ''service autofs'' out of the equation > and use an external script (service_zmfs) with "status" > > **************************************** > #!/usr/bin/perl > # file: service_zmfs > > use strict; > use warnings; > > my @checks = ( > "serviceautofs restart", > "service zmfs probe", > ); > > for my $check ( @checks ) { > $check .= " 2>&1 > /dev/null"; # suppress output > system( $check ) == 0 or exit 1;} > > ************************************* > > it works. Still don''t fully get it.What does one have to do with the other? If you prefer to use an external script then fine, but that has nothing to do with how you must write your Puppet manifests to achieve a similar result via Service resources. John -- 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
2011-Dec-16 02:13 UTC
Re: [Puppet Users] Re: restarting "service" when configuration changes
On Thu, Dec 15, 2011 at 2:56 PM, jcbollinger <John.Bollinger@stjude.org>wrote:> > > On Dec 15, 10:16 am, Sans <r.santanu....@gmail.com> wrote: > > On Dec 15, 2:08 pm, jcbollinger <John.Bollin...@stJude.org> wrote: > > > > > On Dec 14, 4:37 pm, Jo Rhett <jrh...@netconsonance.com> wrote: > > > > > > Try > > > > notify => Service[''autofs''] > > > > > Right. As far as I know, classes do not forward signals to resources > > > they contain. > > > > Are you absolutely sure about that? > > > "As far as I know" was meant to convey that no, I am not absolutely > sure.You can notify a class, and it forwards the signal to resources it contains. -- 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.
jcbollinger
2011-Dec-16 13:57 UTC
[Puppet Users] Re: restarting "service" when configuration changes
On Dec 15, 8:13 pm, Nigel Kersten <ni...@puppetlabs.com> wrote:> You can notify a class, and it forwards the signal to resources it contains.- Hide quoted text -I stand corrected. So, Nigel, do you have any idea why the OP''s manifest is not doing what he expects? John -- 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
2011-Dec-16 18:43 UTC
Re: [Puppet Users] Re: restarting "service" when configuration changes
On Fri, Dec 16, 2011 at 5:57 AM, jcbollinger <John.Bollinger@stjude.org>wrote:> > > On Dec 15, 8:13 pm, Nigel Kersten <ni...@puppetlabs.com> wrote: > > > You can notify a class, and it forwards the signal to resources it > contains.- Hide quoted text - > > > I stand corrected. > > So, Nigel, do you have any idea why the OP''s manifest is not doing > what he expects?Nope :) What version of Puppet is this? Can we see the relevant debug output of this manifest? Does the service have a working "restart" command? If you put a simple test refreshonly Exec into the class, does it get notified? -- Nigel Kersten Product Manager, Puppet Labs -- 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.