Hi all, On 02/17/2012 09:44 PM, jcbollinger wrote: >> ... >> >> service >> { >> "php-fpm": >> require => [ File["/usr/local/etc/php-fpm.conf"], Package["php52"], >> File["/var/log/php-fpm/"], File["/etc/init.d/php-fpm"] ]; >> >> } >> >> and in derived class i want for standalone(linux::php52::standalone) >> configuration restart service when config files changed like this: >> >> Service["php-fpm"] >> { >> ensure => true, >> enable => true, >> hasrestart => true, >> subscribe => [ File["/usr/local/etc/php-fpm.conf"], >> File["/usr/local/etc/php.ini"], File["/etc/init.d/php-fpm"], >> Package["php52"] ]; >> >> } >> >> and in cluster class do nothing(restart of php will be made by cluster >> stack) like this: >> >> Service["php-fpm"] >> { >> enable => false >> >> } >> >> How cant accomplish this be composition? I would be very grateful > > > If no node uses linux::php52 directly (every node uses either > linux::php52::standalone or linux::php52::cluster) then just remove > the service declaration from linux::php52 and put separate ones in > linux::php52::standalone and linux::php52::cluster. > > That makes especial sense in this example because the two erstwhile > subclasses don't need any Service["php-fpm"] property values in > common: the "require" property they both inherit is redundant with the > "subscribe" property that the standalone class provides. > > Class inheritance is a convenience in certain special circumstances, > but only a complication in most. You don't ever need it in any > absolute sense.
not commenting on what would be "best approach" here, I believe everyone has let themselves get distracted from the problem at hand. What should work is this structure: Given class mod::class($param1, $param2) { ... } class mod::class::sub1 inherits mod::class { ... } class mod::class::sub2 inherits mod::class { ... } You will then use these as class { "mod::class": param1 => ..., param2 => ... } include mod::class::sub1 # <- this does the overriding # or #include mod::class::sub2 # ...or even both (not in the presented use case, though) This is a bit confusing, but mixing includes of base classes and subclasses is quite common when using the inheritance paradigm, and this is just an irky notation of the same, seeing as the base class is parameterized. HTH, 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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.