>
>
>>> 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
>>
>> So with the later you can build a somewhat self-contained profile. With
>> the former you have to set variables "globally" or on a node.
>>
>
>
> That is what your data hierarchy is for. Hiera does not limit you to only
> global and per-node data. You can define as many hierarchy levels as you
> need, each grouping your nodes in its own way (though it usually makes the
> most sense for the groups at each level to be subsets of the groups at the
> next lower level).
>
>
Understood. However without creating a custom fact, I am not aware of a way
to say 'apache::keepalive = 1' only applies when a node has the profile
'profile::apache_phpfpm'.
And the foregoing is based on using only the built-in YAML back end. Hiera
> supports pluggable back ends, usable together or separately. A custom back
> end can employ whatever lookup or computation you want to serve whichever
> data you choose.
>
>
We're really trying to avoid this.
>
>
>>
>>
>>
>>> It is thus possible to find and/or write composable classes and modules
>>> for managing the components you want. As David Schmitt observes,
>>> composability is not automatic, but I don't see why your particular case of
>>> an apache-based PHP app server with firewall rules and a specific
>>> collection of PHP and apache modules should present any special problem.
>>>
>>> Thus, the answer to your question is "neither." You build a drupal
>>> profile, and a wordpress profile, etc., and you use them all together.
>>>
>>>
>> 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)
>> }
>>
>>
>
>
> Either you're missing something or I am. I see nothing in that class that
> would inherently preclude it being composed. In particular, the two class
> declarations it contains both use 'include', not the resource-like class
> declaration syntax. If there is a barrier to composition it would be
> related to composition with another class that declares some of the same
> resources. That problem has a solution, however: factor out the
> multiply-declared resources into their own class or classes, which the
> then-composable classes declare instead of declaring the resources directly.
>
>
Duplicate declaration: Apache::Listen[80] is already declared in file ...
Yes, the class could be broken into separate classes but this only exacerbates
the issue of assigning variables based on the profile.
How are others constructing their hierarchies when using the Role & Profile
pattern? Are you assigning variables based on a nodes role or profiles? If
so, how? Custom facts, parameterized classes as we've done in the example
above?
> 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 puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/b6df42fd-0a33-4b63-ba8c-b56b54986d3e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
