You could do global variables, but you couldn't one set the hierarchy to 
the profile level?  Thus you isolate variables in preference to the 
profile, rather than a global mismash.  Stick with parametrization for now 
if this works, refactor later after getting it working, as you'll have a 
functional base state.
 

> We're aware of most of this and agree with most of this. However when you 
> always call include, you lose the ability to say a particular hiera 
> variable is attached to the profile. For example
>
> If you define:
>
> class profile::apache_phpfpm {
>   include ::apache
> }
>
> with the following in hiera:
>
> apache::keepalive = 1
>
> keepalive = 1 applies anywhere apache is included
>
> vs
>
> class profile::apache_phpfpm (
>   $keepalive = 1
> ) {
>   class { ::apache:
>     keepalive => $keepalive
>   }
> }
>
> profile::apache_phpfpm::keepalive = 1
>
>
I am not sure about this... Personally, I get scared of having too many 
sub-classes beyond install.pp, config.pp, service.pp, etc. It might make 
those files verbose, but then it is easier to contain and debug.  
Afterwards, parts into separate pieces, if this helps.

Is cron a separate class?  Personally, I put my bottom level modules into 
their product role, which may require cron functionality.  I avoid crafting 
classes based on their functionality, as this would be the same as having a 
class called package that accepts an array packages to be installed.  It 
gets hard to identify what is involved in installing a product or 
scheduling cleanup tasks for the same product; the code to implement a 
particular product gets scattered across many files, rather than 
self-contained in one module.
 

> So below is an example for Drupal. It could literally be cloned for 
> Wordpress and Joomla. Unfortunately, b/c of the class declarations, it is 
> not composable.
>
> class profile::drupal (
>   $apache_listen = ['80'],
>   $apache_name_virtual_hosts = ['*:80'],
>   $apache_modules = ['fastcgi'],
>   $apache_fastcgi_servers = {
>     'www' => {
>       host => '127.0.0.1:9000',
>       faux_path => '/var/www/php.fcgi',
>       alias => '/php.fcgi',
>       file_type => 'application/x-httpd-php'
>     }
>   },
>   $phpfpm_pools = {
>     'www' => {
>       listen  => '127.0.0.1:9000',
>       user => 'apache',
>       pm_max_requests => 500,
>       catch_workers_output => 'no',
>       php_admin_value => {},
>       php_value => {}
>     }
>   },
>   $php_modules = [],
>   $firewall_rules = {},
>   $backup_jobs = {},
>   $cron_jobs = {}
> ) {
>
>   include ::apache
>   ::apache::listen { $apache_listen: }
>   ::apache::namevirtualhost { $apache_name_virtual_hosts: }
>   ::apache::mod { $apache_modules: }
>   create_resources(::apache::fastcgi::server, $apache_fastcgi_servers)
>
>   include ::php::fpm::daemon
>   create_resources(::php::fpm::conf, $phpfpm_pools)
>   ::php::module { $php_modules: } ~> Service['php-fpm']
>
>   # So the apache user is created before
>   # php-fpm starts
>   Class['::apache'] -> Class['::php::fpm::daemon']
>
>   create_resources(firewall, $firewall_rules)
>   create_resources(::duplicity::job, $backup_jobs)
>   create_resources(::cron::job, $cron_jobs)
> }
>  
>
>>
>> John
>>
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/91d7bbf0-e290-444a-8741-07a1c763d325%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to