>
> 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.
I understand this better now however the problem we were really struggling
with was how to assign variables based on role or profile. Ie, how do you
incorporate the the role or profile into the hierarchy so a variable only
applies to nodes that have a particular role or profile. Your first
suggestion is good although thats not how we're currently assigning classes.
On Wednesday, May 21, 2014 10:03:33 AM UTC-4, jcbollinger wrote:
>
>
>
> 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 puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/16c20ad4-ada5-43d1-bee3-c11a1f07eb5f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
