On Tue, May 20, 2014 at 10:54:15AM -0700, Jesse Cotton wrote:
> 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'.
It sounds like there's some generalizable rule where some hosts get certain
settings (ex: keepalive) setting and some don't. Perhaps this could be broken
out into another hiera layer? Cheapest possible example:
:hierarchy:
- 'nodes/%{fqdn}'
- 'roles/%{role}'
- 'common'
There's this workflow:
puppetmaster uses ENC to get the node's role (named "mytype" here)
the role is used to name the class for hiera_include (role::mytype)
mytype.yaml is also a yaml file as part of that hiera level
Then in the yaml for "phpfpm" and "needkeepalive" you have "apache::keepalive:
true" and in common.yaml you have "apache::keepalive: false".
> 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 => '[1]127.0.0.1:9000',
> faux_path => '/var/www/php.fcgi',
> alias => '/php.fcgi',
> file_type => 'application/x-httpd-php'
> }
> },
> $phpfpm_pools = {
> 'www' => {
> listen => '[2]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 [3][email protected].
> To view this discussion on the web visit
>
> [4]https://groups.google.com/d/msgid/puppet-users/b6df42fd-0a33-4b63-ba8c-b56b54986d3e%40googlegroups.com.
> For more options, visit [5]https://groups.google.com/d/optout.
>
> References
>
> Visible links
> 1. http://127.0.0.1:9000/
> 2. http://127.0.0.1:9000/
> 3. mailto:[email protected]
> 4.
> https://groups.google.com/d/msgid/puppet-users/b6df42fd-0a33-4b63-ba8c-b56b54986d3e%40googlegroups.com?utm_medium=email&utm_source=footer
> 5. https://groups.google.com/d/optout
--
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/20140520181551.GA9097%40iniquitous.heresiarch.ca.
For more options, visit https://groups.google.com/d/optout.
