On Tuesday, May 20, 2014 12:54:15 PM UTC-5, Jesse Cotton wrote:
>
>
> 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'.
>
>
There is no good way to say that to Puppet. It reflects a non-idiomatic
thought process. Moreover, it's unlikely to be what you really want to say
-- you might in the future want other nodes to have keepalive enabled,
too. You should instead consider how to assign apache::keepalive: 1 to
exactly those nodes that get profile::apache_phpfpm.
There are at least two ways you could approach that problem:
1. If you are using hiera to assign roles and/or profiles to nodes then
it should be entirely straightforward to override apache::keepalive at the
same hierarchy level where you assign profile::apache_phpfpm.
2. You can perform a resource parameter override in
profile::apache_phpfpm.
If it is viable, the former is preferable to the latter. A resource
parameter override is a bit messy because it relies on implementation
details of module 'apache'. (It does not work to override class
parameters; you must instead override one or more parameters of a bona fide
resource, which can be of either defined or native type.)
>
> 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.
>
I don't blame you. A custom back-end should certainly be a last resort.
As you keep that alternative in reserve, however, don't forget that such a
custom component does not necessarily need to replace the YAML back-end;
hiera can use two (or more) at the same time.
>
>>> 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 ...
>
>
>
As I said, a duplicate resource. As I said, factor it (and the others)
out. I think it's excellent practice to avoid resource declarations
directly in profile classes, unless possibly of resources that are
assuredly specific to the profile in which they appear.
> Yes, the class could be broken into separate classes but this only
> exacerbates the issue of assigning variables based on the profile.
>
>
>
But that's just it: you don't *want* to assign data based (strictly) on
profile. Or if you do, then understand that it is inherently inconsistent
with composable profiles. Since the node characteristic that determines
the combination of profiles in use is its role, it is on that basis that
you want to assign data. Indeed, that's what you already said with respect
to apache::keepalive. Note that with hiera, that doesn't mean you must
avoid assigning data based on profile; it just means you must (also) be
able to assign data based on role, with the role-based data having higher
priority.
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/3e64dace-ed21-4fdb-9130-94f443931448%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
